[cmake-developers] Better Eclipse CDT support

Oliver Buchtala oliver.buchtala at jku.at
Sun Apr 17 17:00:52 EDT 2011


Hi Alex,

Am 17.04.2011 20:46, schrieb Alexander Neundorf:
> Hi,
>
> On Sunday 17 April 2011, Oliver Buchtala wrote:
>> Hi,
>>
>> I like to get involved offering work on the Eclipse CDT generator.
>>
>> Currently, the generated project setting is not very Eclipse'ish.
> There have been some changes in the 2.8.x versions. You have 2.8.4 ?
>
Yes. Actually current 'next' of stage.

>>  - one large project
>>  - linear build, i.e., build failure in early sub projects stops the
>> whole chain
> You can change this e.g. by adding "-k" as CMAKE_ECLIPSE_MAKE_ARGUMENTS in the 
> cmake cache.
>
What does '-k' do?

>>  - project overview looks like navigator on  cmake binary directory
>>  - source files can be found in 'includes'
> Can you please explain the two points above in more detail ?
>
When I generate a CDT project, sources are in 'includes' (CDT built-in
folder). The rest is the content of CMAKE_BINARY_DIR.
See attachment: 2.4.8 CDT4 MinGW generator on CMake/Example, Eclipse
Helios, CDT 7.0.2

>> All in all, this is not what a developer used to CDT wants to see ;)
>>
>> What I want to do:
>>  - generate projects for each target (like in VC generators)
> Can you please explain ?
> Do you want a separate build tree for each project ?
> Or just separate Eclipse project files for each target ?
For each target. Like in MSVC.

> Are you sure people will want to import that many projects or can they be 
> grouped in some way in a "superproject" ?
>
Eclipse users are used to a flat multi-project layout. They use working
sets to group projects.
Actually, I am personally not the greatest friend of complete flat
hierarchies - but this is actually the eclipse way.
You may have a look at large Eclipse java projects, e.g. Eclipse itself.
Importing all projects in a directory is a one-clicker. Though, they
should not be nested for that feature to work.
Another typical way to separate things is to have multiple workspaces.
E.g. one for each large project.
So IMO there are enough ways to structure views on very large projects.

Another feedback story:
At work, I suggested my coworkers to give eclipse+cmake a try (without
trying it myself) as we have now a CMake setup and I am a fan of CDT.
They stopped disappointed beeing confused by the project layout. They
are used to MSVC and a bit to Codeblocks.
And, trying it the first time (yesterday) I really felt similar.
Perhaps, you can understand on the basis of my screenshot.

>>  - based upon makefile generator
>>
>>      > eclipse cdt projects can be based upon existing makefiles (e.g.
>>
>> in sub-dirs)
>>  - add folders:
>>     * src: using eclipse linked folder pointing to source location
>> (CMAKE_CURRENT_SOURCE_DIR)
>>     * cmake: eclipse linked folder pointing to CMAKE_CURRENT_BINARY_DIR
> We have something like this in 2.8.4. I.e. there are linked folders for each 
> project(), and one linked folder for CMAKE_SOURCE_DIR.
>
I thought have seen this beeing deactivated in source code due to some
issue filed on bugtracker?

>>  - add project dependencies for correct build order
>>
>> Having this would make the CDT generator beeing a serious citizen on the
>> cmake generators list.
>>
>> Q's:
>> - What is your opinion?
> A not-Makefile based "native" Eclipse project generator might also be an 
> alternative, but requires more work. 
>
I think the Makefile based approach is very reasonable as it is really
tightly integrated.

Actually, there is not too much missing IMO.
Per target project would bring a more intuitive relation between targets
and projects.
This is really what I want from the IDE setting. Otherwise I will use
make on the shell.

I would add a project per target based on make. Per project add only the
one make target.
And maybe add a global ALL project. Maybe also a ZERO_CHECK project all
others depend on ... for checking on CMakeLists.txt changes.


Another question: you call the generator CDT4. Current CDT is 7.0.2.
Though, I find 'cdtBuilder version' in current .cproject.
Is CDT4 'out-of-date' or are you referring to the version in xml?

Bye,
Oliver

-------------- next part --------------
A non-text attachment was scrubbed...
Name: CMake-CDT-example-project.PNG
Type: image/png
Size: 21052 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20110417/a3cd12ef/attachment-0002.png>


More information about the cmake-developers mailing list