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

[Miguel A. Figueroa-Villanueva]

On 8/2/07, Eric Noulard <eric.noulard at gmail.com> wrote:
> 2007/8/2, Alexander Neundorf <a.neundorf-work at gmx.net>:
> > On Thursday 02 August 2007 05:34, Eric Noulard wrote:
> > > Moreover I think in-source built should be supported by the CDT Generator
> > > in order to be consistent with other generator.
> >
> > Yes, in-source builds should work and having Eclipse support that only part of

This was an oversight due to the fact that I think it is an *evil*
practice to do in-source builds ;)

I'll put code around the linked resource creation code and the
pathentry to detect if SOURCE_DIR == BINARY_DIR and handle it
approapriately.

> > Somebody feels like looking into the Eclipse/CDT sources ?
>
> I may have a look at this.

At some point I might look into the source deeper... What I really
have been thinking about is to send the cdt-dev list a message trying
to sell them cmake. Then with their help/guidance I wouldn't mind
contributing to the Eclipse/CDT to enhance the cdt/cmake integration.
The reason I think they might be interested is that I've been reading
in the docs and archives that they are interested in supporting a
copule of things that cmake does already. Among them,

1. integration with the Microsoft tools.

Bill mentioned that we can compile with the VS Express (or any VS
version) compiler and debug with cygwin gdb, right? Can somebody point
me in the direction on how to do this? I seem to recall that it wasn't
with the NMake generator, but setting the compiler to VS's cl and
using "Unix Makefiles". If that is the case are there more settings
needed to provide the correct environment for cl?

If I can do this then they would have a shortcut way to provide MS
Toolchain support in the cdt, which they allegedly are working on but
haven't had the time and resources to complete.

2. cppunit testing support.

I'd venture to sell them on ctest and while I'm at it try to promote
cpack, the dashboard concept, etc. However, does anyone use cppunit
set up with cmake/ctest. What is the basic setup?

> Nevertheless I think the issue may not be "only" in Eclipse/CDT
> but more in the Eclipse Platform Team,
> "http://www.eclipse.org/eclipse/platform-team/".
>
> Doc says (http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.platform.doc.isv/guide/team.htm)
>
> "A repository provider (RepositoryProvider) is the central class in
> the implementation of your repository.  This class is responsible for
> configuring a project for repository management and providing the
> necessary hooks for resource modification. "
>
> It seems that repository provider is really "project-oriented"
> we may be able to write an "aggregate repository provider" which may
> implements the feature we (may) need which is having a project
> refering to different folders (at least 1 in the current test case)
> under possibly different source management system.
>
> I will have a look and ask questions on eclipse.org concerned
> subpart and tell you what I can do.

<start rambling>
I'm not sure where the problem is, but I'm certainly developing a
love/hate relationship with eclipse ;) On the one hand it is a great
tool, although a memory hog, that has quite a nice interface and great
flexibility. I even used the refactoring "rename" tool to change the
enum EclipseToolchainType naming!! I wish C++ was more refactoring
friendly, just this one refactoring... On the other hand it seems that
the most commonly used things are not supported yet... for example,
nested projects and hierarchichal design to allow the source root to
be placed anywhere.
</start rambling>

My current work around to this problem (and this should make it into
the wiki page) is to have a CVS project created to check out the
source. The location of this project seems to be required to be in the
workspace. Then create an out-of-source build using the "Eclipse CDT4"
generator, which will have the links to the source as usual. Use the
CVS project to manage cvs/team interaction and the out-of-source
project for development. You would have:

workspace - ~/eclipse
|
-- CMake - cvs source checkout, ~/eclipse/CMake
|
-- cmake_bin - out-of-source build in ~/eclipse/cmake_bin
                      that links to ~/eclipse/CMake sources
|
-- cmake_bin2 - another out-of-source build (debug or other tool set maybe)
                        in ~/eclipse/cmake_bin2 with links to the same source

so changes during development will make it to the CMake source dir and
the regular commit, update, etc interactions are supported through the
CVS project.

Note that if you are not interested in using Eclipse CVS to manage the
team interaction (e.g., you use the command line cvs or the sources
are local) then there is no need for the cvs project above and the
sources can be installed anywhere. You'd have the following layout
instead:

workspace - ~/eclipse
|
-- cmake_bin - out-of-source build in ~/eclipse/cmake_bin
                      that links to sources
|
-- cmake_bin2 - another out-of-source build (debug or other tool set maybe)
                        in ~/eclipse/cmake_bin2 with links to the same source

Hope this helps,

--Miguel