Am 20.04.2011 22:09, schrieb 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 ? > There is some link - but empty. I have exactly one project call (like I usually do).
>>> 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 :-) > Here we go: git://github.com/oliver----/cmake_cdt7.git I have intensively worked with this generator the last days - and am not completely satisfied with it in the moment. But basically, it does what I want. I did not completely base upon your implementation (generating project programmatically) but rather used a template approach. The templates are created manually from within eclipse... I'll try to improve my work a bit the next days... >>> 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 Alright. Frohes Osterfest then ;) Bye, Oliver _______________________________________________ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers