[CMake] Eclipse CDT4 CMake Generator - Pre-Alpha version

[Miguel A. Figueroa-Villanueva]

Hello Mike,

My comments below.

On 7/31/07, Mike Jackson <imikejackson at gmail.com> 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