[cmake-developers] Better Eclipse CDT support

[Oliver Buchtala]

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
>
typo: 2.8.4
>>> 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?
Ehmm, I mean this:
<?fileVersion 4.0.0?>
<storageModule moduleId="cdtBuildSystem" version="4.0.0">


Bye,
 Oliver