[CMake] Patch for Eclipse generator

[Miguel A. Figueroa-Villanueva]

On 10/21/07, Pau Garcia i Quiles wrote:
> Quoting Alex Neundorf:
> > On Sunday 21 October 2007 00:48, you wrote:
> >> > Just to make sure I understand:
> >> > with this patch the two eclipse project files are always created in
> >> > the source tree, right ?
> >>
> >> Right.
> >>
> >> > What happens if you try to create two buildtrees for one source tree,
> >> > which problems may appear ?
> >>
> >> With my current patch, it's not possible due to Eclipse limitations.

Exactly, a limitation we should remove in Eclipse.

> >> The only way I can think to fix this is to create soft links to the
> >> files and folders in the source tree, then create the .project and
> >> .cproject in that folder. It'd be something like this:

<snip>

> >> This would probably work fine on Unix platforms and probably Windows
> >> 2000 and 2003 (using linkd for the symlinks). I'd have to test this,
> >> though.
> >
> > I.e. creating a symlink for each source file and each folder ?
> > Hmm, creating potentially thousands of symlinks doesn't sound too good.
>
> Yes. I agree it does not sound too good but we would be on-track again
> to the CMake-ish way of doing 100% pure out-of-tree builds.

Which is the right way, of course.

> I have not considered it seriously but I think we may only need to
> create symlinks to the first level of files and folders, not to every
> file and folder inside every folder:

<snip>

> then we would run CMake as it were an in-tree build where the source
> files reside in mybuildtree.
>
> However, I'd need to test if creating empty .svn/CVS dirs in
> mysourcetree, then symlinks to them from mybuildtree would work when
> the project is added to Subversion or CVS later from Eclipse. Another
> problem with this is CMake needs to be aware of the source versioning
> tools which are available (Subclipse, CVS integration for Eclipse,
> Bazaar integration for Eclipse...).

I think this won't work, and if it does... we are bending over
backwards to fix something that is not a CMake issue. More below.

> > How about that:
> >
> > If you run cmake in-source, everything should just work.
> >
> > If you run cmake out-of-source, cmake creates two eclipse projects: one
> > project in the source tree, where you can't build anything, but which you
> > should import in eclipse to have version control working, and the actual
> > project in the build tree, where you build stuff (but don't have version
> > control). The in-source version control project only would have to be created
> > if it doesn't exist yet.
> > What do you think about this ?
>
> That might work but I don't see the point.

Well, I definitely see the point, and I think it is a much better
route than putting the build projects in the source tree... But I
still disagree that this route to go... last time I checked it was
trivial to create a version control project in Eclipse (very few
clicks). For CMake to generate them it would need to be an option,
since I might not want Eclipse to handle that.  Also, CMake would need
to know what type of version control it is and how to generate the
project for it... All of this isn't too hard, but it isn't harder
creating it manually.

> Once CMake "rapes" the source tree by writing something to it, what's
> the point in having two projects?
>
> Could you please explain what's the benefit of having two projects,
> one for the source version control and another one for generating the
> files out-of-tree?
>
> Please note with my current patch the built files are built
> out-of-source, so the final result is exactly the same with your
> two-projects approach and with my single-project approach: compiled
> files go out of tree, .svn and CVS folders go in-tree. The only
> difference is with my single-project approach the user does not need
> to switch projects to build the binaries, or to svn update/commit/etc,
> which I think is better.

The problem here, Pau, is that CMake exists for a reason that goes
beyond the specific needs of one user. I thought long and hard about
Mike's comments when I was building the generator, but for a CMake
generator to be implemented it has to work in a general way.
Otherwise, it is not much use for people in general. People using
CMake expect to be able to do out-of-source builds without a single
shred of evidence in the source tree. If we were to violate that
principal by putting the .project/.cproject files in the source tree,
which of course I think is wrong, then still people using CMake expect
to be able to have multiple build trees from the same source tree.

If you can work around these issues in the CMake code, then fine. But
if it is going to limit the use of CMake then maybe it is time to
consider submitting a patch to Eclipse... I don't have the time to
consider this at the moment, but it is the way to go.

Just my other 2 cents,
--Miguel