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

[Miguel A. Figueroa-Villanueva]

On 8/2/07, Mike Jackson wrote:
> On Aug 2, 2007, at 10:39 AM, Eric Noulard wrote:
> > Yes this a working solution but using this solution is not as
> > natural as it is for CMake CDT Generator since it still
> > needs to generate .project/.cproject in source dir and
> > the other generated stuff in "Build" dir.
> >
> > When using out-of-source build with CMake
> > (including Visual Studio) the project file is generated in the
> > Build Tree
> > not the Source Tree.
>
> LIke I said, Eclipse is NOT like other IDEs and therefor should NOT
> be treated the same. I think trying to have a Build tree outside of
> the Eclipse "project" directory is going to get klunky for the CDT
> user. I assume that I will end having a CDT project that is really my
> Build tree, then another generic project that is my Source tree. The
> Build Tree project will have references/links to the Source Tree? I
> guess that works. Kinda clutters up my project view a bit, but
> everyone works differently, so to each his own.

This is actually what I just suggested in another posting. I think it
is the best and most flexible solution. Refer to it for details.

> >> As to #3, I can always "Share" a project from the Team menu after I
> >> import my project.
> >
> > How can you do that without effectively importing your build tree
> > in the CVS repo?
> >
> > Using the current CDT CMake generator if I try to "Share"
> > the project he will ask me for a CVS repo and a module name
> > for my Project whereas there is none with this name in the refered
> > CVS repo.
> > which ONLY contains a module whose name correspond to the source tree.
> >
>
> I kinda boot strap the process a bit. My project was _already_ in cvs
> start off, so all the CVS Directories are in the source tree and NONE
> will ever be in the build tree. Eclipse will pick this up when you
> "share" the project from within eclipse. CDT will recognize the fact
> that there are CVS directories and try to use that information when
> you "share" the project.
>    When you are ready to commit changes back to cvs, if you right-
> click on directories that have changes instead of clicking on the
> project, then eclipse will effectively ignore the Build Tree all
> together. I have been doing it this way for about a year now. Seems
> to work just fine but it is not obvious to do it this way for a first
> time CDT user. It took some experimentation to figure this out.
>
> The pros of putting a sub-rooted build tree in the source dir when
> using Eclipse is the following:
>    Eclipse seems to have an easier time indexing your project
>    CDT seems to have an easier time finding compiled products.
>    Setup of debugging seemed more straight forward. Right click the
> executable and "Debug local Application"

All of this should work just as well with the current generator. If it
doesn't it is a bug and then something has to be done on the
development side of the generator to support it.

Note that we don't want to make life easier for Eclipse, but for the
users. We want to figure out the way to do things correctly and work
around the limitations available so that the user doesn't see them.
The idea is to have stable, *easily reproducible* sessions with
Eclipse.

> Just some observations on how I personally use eclipse and cmake. YMMV.

I certainly appreciate these and they have helped me understand some
of the limitations. However, I don't think that it is reasonable for a
cmake user (it might for an eclipse user, but not a cmake user) to
have to have a restricted structure in the setup of their project.
That is I can't force the user to have a Build subdir and not even a
parallel subdir (../Build) for that matter.

Just my thougts on the matter.

> --
> Mike Jackson   Senior Research Engineer
> Innovative Management & Technology Services

--Miguel