Re: [CEDET-devel] EDE CMake status

[Thomas R. <ric...@gm...>]

Hi everyone

Nikolaus Demmel <demmeln <at> in.tum.de> writes:

> 
> Hi Alistair
> 
> Alastair Rankine <arankine <at> gmail.com> writes:
> 
> > My main goal at present is to contribute to EDE, specifically to add CMake
> support. I have a branch which I
> > have been using quite successfully and I know of at least one other who has
> been able to do likewise.
> > 
> > https://code.launchpad.net/~arankine/+junk/ede-cmake
> > 
> > So I guess I'd like to get some further review comments, specifically 
whether
> it is suitable for merging
> > into trunk.
> 
> I'm very interested in this. Can I test it? Where are the 4 files supposed to
> go, and is there some documentation of what features are supported and can be
> tested?

To use the files, add them on a directory listed in load-path, as usual.
An example of configuration is in the comments at the bottom of ede-cmake.el.


> 
> > 
> > There is no support for parsing CMakeList.txt files but I am (slowly) 
working
> towards this.
> > 
> 
> This would be truely awesome, but sounds very complicated to do fully. Maybe 
an
> alternative would be to generate configuration files from cmake, like they do
> for Eclipse.
> 

I had the same idea: it would be a lot easier to get the information from cmake 
directly. So I started to write an external generator for cmake, based on the 
one for codeblocks.

The code is available on github:
https://github.com/Niluge-KiWi/CMake/tree/ede-generator

How to use it:
cmake . -G "EDE - Unix Makefiles"


It will generate the usual makefiles tree on the build directory, but will also 
add elisp files: one per cmake project (<project_name>.ede), and one per 
CMakeLists.txt (ede.local.generator.el)

This represents the cmake internal data structure: Projects have several local 
generators, which are associated with each CMakeLists.txt file in the source.
For each local generator, we have the include paths and targets it handles.

This code is only a prototype: the idea was to see what information is 
available, and how to extract it to make it available from emacs.

The result is: we easily have everything we need.


This still needs quite some work, but this will depend on how exactly we use the 
information in ede.

I'm not familiar with ede, so I don't know how to proceed on the ede side. I'm 
currently trying to understand Alastair's code and look where we could use such 
information.


--
Thomas Riccardi