Re: [CEDET-devel] EDE-compdb

[Alastair R. <ala...@gi...>]

Firstly thanks Eric and David for the great feedback and encouragement. It's very gratifying.

I've been doing a lot of work on this project lately, and have got it to the point where it works well enough for daily use at $WORK. This is quite a stress test, with something like 5K of source files, and a correspondingly large number of header files and targets. After a few performance tweaks, it works pretty well for my needs, although there is a bit of room for further improvement, which I'll hope to get to soon.

Some features I've added recently:

- New project type for Ninja projects (ede-ninja-project). Ninja is a build tool which can generate the compilation database dynamically, and ede-ninja-project uses this instead of reading a file.
- Support for loading "phony" targets for Ninja projects. Again these are discovered dynamically.
- Better progress reporting
- Preliminary support for parsing header files (ie for a given .h file, locating the corresponding .c file in the compilation database). This currently uses the built-in ff-other-file-name function, which allows customization by the user in a standard way.

As a reminder this is all available on github: https://github.com/randomphrase/ede-compdb. Also if you're interested, my CEDET init: https://github.com/randomphrase/dotfiles/blob/master/emacs.d/init/cedet.el

I have some outstanding questions below, but first I'll respond to the specific feedback:

On Jan 27, 2014, at 9:40 PM, Eric M. Ludlam <er...@si...> wrote:

> Detecting and loading projects is tricky since it is easy to make loading a file into a buffer slow, and I have a hard time remembering how all the pieces and optimizations work.  I might have obsoleted the need for self-tracking at some point.  It may be ok as it is and maybe I can clean up the other project types.

OK - I've left the TODO in there for now. It seems to work OK, but there is an outstanding issue, see below.

> While looking into this, I realized that the ede function that calls the "load-type" slot will call 'ede-add-project-to-global-list' for you. The core EDE projects such as arduino and Emacs appears to be doing this twice too and should probably be cleaned up.

Fixed.

> Your autoload is declared as 'unique.  I assume this is because you want the config file to trump some other more general project type.  It may be that if this project type is better than some other EDE project, then we should teach that project how to call the right functions to create the compdb thing to generate the config file.  I think that is a later task though.

Fixed - removed 'unique.

> David mentioned that every file goes into its own target.  Since you only have per-file data, that seems like a reasonable strategy in the short term.  If some higher-level data is available in compdb, additional grouping could be handled.  To merge multiple files into one target, you would end up with one target per configuration combination.  ie - All files with the same include path, compile flags, etc could just be grouped together.  That pattern match might be slow though.

Yes unfortunately there are no higher-level constructs provided by the compilation database. I did consider coalescing of source files into a single target but I think there's not much point.

The ede-compdb-target class is pretty small, and really just a placeholder for the source file's corresponding entry in the compilation database. So the overhead of having many of these objects in memory shouldn't be an issue.

> From a legal standpoint, your file needs proper heading and copyright.

Fixed.

> From an Emacs Style standpoint, your file is missing some standard content/doc.  You could use 'checkdoc' and let it point out the missing header / footer / commentary sections.

Fixed.

> From and EDE standpoint, all project files follow a common organizatin where the 'load' setup is done first in the file (ie - the ede-add-project-autoload call and needed functions) with the content following.

Fixed.

> Lastly, you have some tests!  Yay!

Yes, I don't think I would have got to this point without them.

From David:

> The only thing you'd have to change is the usage of 'mapcar*', since we
> cannot use functions from the 'cl' library.

Can you elaborate more on this? I'm under the impression that mapcar is an emacs built-in. Also I'm no longer using any functions from the cl library, so I *think* it's all conformant to emacs standards.


I have a couple of outstanding issues:

Firstly, Is it possible to register an additional root directory (or directories) for a given EDE project? I'm asking because in my $WORK projects it is pretty common to use a build directory which is on a separate filesystem to the source tree. This is done to improve performance - typically such a filesystem can be tweaked for temporary build artifacts such as object files. In addition, it is common in my experience to generate source files inside this build directory. As an example, consider the common case of a "config.h" file which is usually generated based on the result of build environment detection.

So while EDE-compdb can locate these generated files, there doesn't seem to be an obvious way to register this build directory against the current project. This means that when loading the generated files, it is currently not recognized as part of an existing project. Maybe I'm missing something obvious though!

Secondly, I have a question about EIEIO is around :accessor slot options. Does this allow for the lazy compilation model? So for example, I've changed the current implementation so that parsing of the command line is done as required, but in order to support this I've had to create an explicit get- method which I call instead of just accessing the slot directly. Is it possible to attach this method as an :accessor option so that it will be invoked automatically to calculate the slot value as needed? Or is there another way to do this?


Thanks again for the feedback.