Re: [CEDET-devel] EDE CMake project type

[Alastair R. <ar...@in...>]

Thanks for the feedback.

On 14/08/2011, at 11:15 PM, Eric M. Ludlam wrote:

> I think it is great that you are taking on a new EDE project type.  Will you be able to sign a release with the Free Software foundation for contributions to Emacs and CEDET?  If you write to cop...@fs... for more details.

I will do so.

> There are several ways to tackle a new EDE project.  One is the style you have specified using ede-cpp-root, though I haven't tried making any subclasses of that.  The other is a "from scratch" implementation that detects the CMakeLists file, sort of like project-am (which is probably overkill) or the emacs / linux / android projects. Lastly, you could use the ede-generic.el mechanism, which already supports CMake, but only at the most primitive level.

Yes I admit I did a cursory look at the existing project types, but mainly just to get an idea about how they work. I just chose the ede-cpp-root-project as a base simply because that's what I had been using up until now, and wanted everything to just work with a minimal additional learning curve on my part.

I'll have a closer look at the other project types, but there are some features of ede-cpp-root which I would need to duplicate (or refactor) to use elsewhere. By this I mean the include path management and SPP tables, etc. Anything c/c++ specific, basically.

I notice that the generic project type already has code for dealing with c/c++ include paths and preprocessor definitions. However it also seems to assume a persistent EDE project file, but maybe I could just subclass and add my own CMakeLists.txt file parser. In either case it would probably help to make the generic project type even more generic by deferring to some other class to do the configuration save/load.

Perhaps the generic project type is too generic. Certainly there doesn't seem to be the need to distinguish multiple target types. With the use of cmake, all we need to care about are the target names, and the association of files with those targets. Cmake and the underlying build tool should take care of the details of building.

> You can specify menus by specifying the 'menu' slot in your project or target.  If you can look at ede-android.el in CEDET bzr on trunk, you will see examples of that and the keybinding slot.

Yep, I think I've figured it out now - I was trying to call a method rather than a function.

> The baseclass will handling instance caching as long as you do not override the initialize-instance method, or call (call-next-method) in your initialize-instance method.

OK. I do kind of want that stuff though. Might have to duplicate the instance caching, then.

> If the compile method you added to ede-cpp-root-target is useful, it should just be moved / added to ede-cpp-root.

Well I guess - it redirects to the project object to do the build, passing the name of the target to build. Perhaps this is suboptimal. I guess I makes sense for the targets to be doing their own building - but for cmake projects I can't see this happening.

> There are many build systems that only have one configuration identifier at the top directory, so this is a feature EDE will need to grow into in order to adopt a wider range of build systems.  That means you could create your project to just identify the top level file, which EDE can do now.  The android project does this, and when I use it, I just open the Android manifest first, then continue on, much the way in Visual Studio you have to "open" a project before you can work in it.

Hmm, not sure I understand this, or at least the relevance.

CMake has CMakeLists.txt files at all levels of the project hierarchy. My plan was to read the CMakeLists.txt file to verfify/get the target information for the directory, and that's about it.

> This is something I've been looking into this morning because I've been examining ant for google's app-engine support.  At first I started a stand alone project type, but after looking into it, I may switch to using a generic project type.  Generic projects need a little TLC as they haven't been actively "used" to create a real project.

Yeah any cleanup or simplification you can do here would certainly help.

By the way I think there is a minor bug in ede-project-configurations-set. On line 330 of the current bzr code, I think the let should be a let*. Without it, I get an error when the function is called interactively.

Thanks again.