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 _______________________________________________ cmake-developers mailing list [email protected] http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
