Hello Mike, My comments below.
On 7/31/07, Mike Jackson <[EMAIL PROTECTED]> wrote: > You dont. That is what I tried to explain in one of my other posts. > Eclipse has the notion of One project PER top level directory. If you > had a project setup like the above then you would have to actually > take the folder sub1 and place it at the same level as foo. Yes, that's what I thought and I really dislike!, but I'll live with of course ;) > Let's get straight what _Should_ be going on. The eclipse > generator is basically going to generate a single eclipse project > file that has the following properties: Agreed, one .project/.cproject is what I'm doing. > Project Type: Makefile Yes, that's the whole idea of implementing the Eclipse generator on top of the "Unix Makefiles", etc. > Build Command: /usr/bin/make -C ${project_loc}/[path to build dir] Don't agree completely. I very much appreciate the wipe-out build directory and start over methodology that CMake enables. I also would not force an out-of-source build to be in a specific struture relative to the source dir. I also appreciate that I can generate different out-of-source builds from the same source code. This would potentially be helpful for testing "Eclipse CDT4 - Unix Makefiles" and "Eclipse CDT4 - MinGW Makefiles". Therefore, I really want to have the toplevel (and only) .project/.cproject file in the top-level binary dir. So, to work my way around this CDT limitation what I did was that, for each project, I create a linked resource in the .project file. So, that the following CMake structure: PROJECT(foo) sub1/PROJECT(P1) sub2/PROJECT(P2) produces the following in the .project: ... <linkedResources> <link> <name>P1</name> <type>2</type> <location>D:/path/to/P1</location> <name>P2</name> <type>2</type> <location>D:/path/to/P2</location> </link> </linkedResources> ... and I also put the following in the .cproject: ... <pathentry kind="src" path="P1"/> <pathentry kind="src" path="P2"/> ... It's not as good as encapsulating each cmake project in an eclipse project, but that is just not supported right now in eclipse cdt as you stated. > Include Dirs: Loop through them and add them all, regardless of > where they are defined. Eclipse needs them all to index you project > correctly. Yes, I guess this is the thing to do given the problems stated above. > Source Dirs: Don't need these I do, since I'm putting the .project/.cproject in the binary dir as explained above. Of course, these are the linked resources above. > Unless all your sources are loose in the top level you need to > add each source directory to the "Include" paths That is what I believe to be doing with the pathentry's above. > What is happening is that Eclipse is going to use the generated > Makefile as its build system. The project files that are created are > actually pretty small because most everything is going to be defined > in the makefile and eclipse is going to run "/usr/bin/make ....." and > then parse the output for warnings and errors. > > Does this help explain things better? Yes, it actually confirmed my google search and I think we're in principle, pretty much on the same page. Except for implementation details regarding where to put the top-level generated files I agree with all. BTW, do you have complex hierarchichal and nested projects which you have worked on that your simple top-level .project handles well. Could I take a look at these .project/.cproject ?? Thanks for the info. --Miguel _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake