[cmake-developers] Better Eclipse CDT support

[Alexander Neundorf]

On Wednesday 20 April 2011, Oliver Buchtala wrote:
> Hi Alex,
...
> > What would you expect there ?
>
> Some structure that gives me acces to the sources of the targets.
> I suppose, you try to achieve this with sub-projects, but it does not
> work properly in my case.

How does it work not properly ?
Don't you have project() calls or are they not created ?

> > Is your build dir a subdir of the source dir ?
>
> Yes.
>
> > In this case the link to CMAKE_SOURCE_DIR is not generated, otherwise
> > there should be a link [Source directory].
> > It's a pity that Eclipse has such problems with out-of-source builds.
>
> Ok - that is the problem with my setting then.
>
> > It's really Eclipse which would need some fixing here.
> > It would just have to accept that the base source directory is not always
> > the directory where the project file is located, but can be a directory
> > specified in the project file.
> > This would help a lot.
> >
> >> 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.
> >
> > Hmm.
> > So this would be one build tree (i.e. one CMakeCache.txt with a global
> > Makefile-structure), and Eclipse-projects for each target, and a "working
> > set" which groups these projects together ?
>
> Yep. One Make tree. And 'light-weight' eclipse projects as views on
> targets.
>
> > Don't know. Maybe.
> > Can you provide a screenshot of how this looks like ?
> > Or maybe create a clone of the cmake git tree on gitorious or github and
> > try to implement it there ?
>
> I have a working impl ....  will push it on github tommorrow :)

Cool :-)

> > Or, how about instead of creating one project per target one project per
> > project() call ?
>
> Hmm. Is it typical to have many project calls?

I don't know whether it's typical. It also depends what you 
consider "many" ;-)
I usually use project() for a somehow self-contained part of the build tree.

> I'll ping you tomorrow (after work).

I won't be back before Monday.

Alex