You have some good goals outlined below. Right now some of that stuff
will not work out of the box without some development in the CEDET/EDE
area. Due to the vast variance in build system types, EDE was designed
so that it is easy to add new EDE project types, but that means special
development on the part of the user.
I'll try to specify more below.
On 05/07/2011 01:35 PM, kristof.ralovich@... wrote:
> Dear CEDET devs,
> I'd like to ask for your advice.
> Let's assume I have a large c++ project that uses existing libraries
> (e.g. Qt, VTK). In such a situation code completion, reference
> finding, different builds, etc. are very helpful during development.
> Usual setup (i guess usual not only for me) involves having a source
> folder, and separate folders for different builds (e.g. Release,
> Debug). Each build folder contains the proper make files for that
> particular build. The make files specify include folders and
> With the above said, here's what I'd like to achieve in Emacs/CEDET:
> - CEDET parsing my Makefiles and finding out what are the actual
> include paths and what is #define-d for this build
> - be able to find the #includes based on the paths from the make files
Parsing Makefiles is already possible with the Semantic parser. EDE,
however, doesn't take advantage of this for looking up things such as
#defines or #include paths.
If there is a particular and common pattern, it can make sense to create
said parsers, and make that particular project type available
generically. I focused on Automake based builds, or systems where EDE
creates the Makefiles.
Are you interested in attempting to create or augment an EDE project
type? It took me an afternoon to put together a new EDE project for the
code I have at work, which is highly specialized. I can help identify
things you may need to do. If it is generic, you will need to send in
release papers to the FSF to contribute your code back to CEDET.
> - provide code completion for the build
Once EDE is set up, this just happens.
> - be able to rune make for project targets in different build folders
> (e.g. Debug, Release) with their respective settings
This also is mostly free once your project is setup. Switching between
build configurations is currently a challenge, but I have a patch for
that I need to merge back into the trunk.
> - I wouldn't like to put project specific bits into my .emacs
If your project type is reading data directly from Makefiles, you
probably don't need to add anything new to your .emacs file. If you
instead mean you want something like ede-cpp-root, which is only
configured from a .emacs file, then perhaps you only need to edit and
add features to ede-cpp-root.
> I had created a simple project
> (https://gitorious.org/cedet-misc/cedet-test) that is meant to
> illustrate my problems. I'd like to implement your suggestions in this
> project to achieve my goals.
This is a great example project. Thanks for assembling it. If you
would like this project type to be auto-detected, the one thing EDE
would need is some key file at the topmost level that will tag that
directory, and sub directory as being unique to your project style. For
example, Android projects have an AndroidMantifest.xml that made it easy
for me to create an EDE project for Android.
> Thanks in advance,
> PS: On the longer term, I'd like to move into the direction of
> generating my makefiles by cmake and still preserve all the above
> functionality. I went through the EDE info pages but couldn't really
If you are creating your own EDE project type, distinguishing between
the two build systems would be a matter of just tweaking your detection
> find the answers. Maybe most of these is already possible in CEDET,
> this is not clear to me. I think if this test-bunny project works out,
> it could be an example for more developers to enjoy the great services
> of CEDET with a lower barrier for entrance.
The original doc for EDE was focused almost entirely on extending the
Automake/code gen versions of the 'ede-proj' project type. I have since
found that light-weight custom project detecting mini-projects seem to
be what most people want, and also appears to be what you are asking
for. Some good examples for you might be ede-linux.el, and ede-emacs.el.
> PS 2: I had read Alex Ott's great article
> (http://alexott.net/en/writings/emacs-devenv/EmacsCedet.html) and
> other hints for cmake
> but I'd like to reach a more straight forward solution. Also I have a
> working setup of the above using hardcoded ede-cpp-root-project.
I think you will need to specify in more detail what "straight forward"
means. ede-cpp-root is often sufficient to bring in some project with
odd build systems.