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