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

[Alexander Neundorf]

On Tuesday 31 July 2007 15:40, you wrote:
> On 7/31/07, Alexander Neundorf <a.neundorf-work at gmx.net> wrote:
...
> > How do you handle the cmake projects ? You iterate over the map, which
> > effect does this have ?
>
> Well, since I want to create the .project/.cproject in the
> CMAKE_BINARY_DIR what I did was that I created a linked resource to
> the source directory in the .project file. That way the paths to the
> project sources are in the "Project Explorer" and "Navigator" windows.
> I also iterate over the map during the .cproject creation to tag these
> linked resources as source directories. I believe this is important
> for indexing, but I'm not sure if it is completely ironed out.

What do you do for 
PROJECT(foo)
sub1/PROJECT(P1)
sub2/PROJECT(P2)

I think each PROJECT() command should be treated as if it would be a 
completely independent project, so that you can load any of the project files 
and have it fully working. One project shouldn't care about the other 
projects I think.
(In the CodeBlocks generator this is currently done differently, but I'll 
change this, so that for every PROJECT() a project group is created).

> I also list all the targets to the "Make" window, so that the user can
> click the target and make it.
>
> > From the header:
> > enum ToolChainType { OTHER, LINUX, CYGWIN, MINGW, SOLARIS, MACOSX };
> > I would prefer more specific names, e.g. prefixing them
> > with "EclipseToolchain", so that you have EclipseToolchainCygwin etc.
>
> Even if it is a private enum? 

Yes, makes it easier to search for stuff in the sources.

> Ok, I guess the following should do, right?
>
> enum EclipseToolchainType {
>   EclipseToolchainOther,
>   EclipseToolchainLinux,
>   EclipseToolchainCygwin,
>   EclipseToolchainMinGW,
>   EclipseToolchainSolaris,
>   EclipseToolchainMacOSX
> };
>
> > One thing which would be nice is if you would also put the include
> > directories in the project files, I think this is required for
> > autocompletion. You can get them via cmMakefile::GetIncludeDirectories().
>
> I thought about that and I'll do it, but the reason I hesitated was
> because I don't know how to add them in a per cmake project basis. I
> can include it in the toplevel (and only) .cproject, but that applies
> to all projects beneath it, which isn't much of a problem since your
> building with "make" anyhow.
>
> As far as I know however, eclipse cdt doesn't support nesting
> .project/.cproject for hierarchichal project structures. Does any one
> know more about this? I'm planning on asking these on the cdt list
> eventually.

So one include path for everything ?
Then probably collect all used include paths in the whole tree and use them 
all.

...
> > For the KDevelop generator I implemented a simple logic which reads the
> > project files it created on a previous cmake run (and which may have been
> > modified in the meantime by kdevelop) and just modifies what it needs to
> > change, so user changes (like which plugins to load, source control
> > config etc.) stay unchanged.
>
> I'll look into this later on. But I have to warn you that eclipse has
> this notion of the workspace. I guess somethings like doing "Full/Fast
> Indexing", editor preferences, projects loaded, etc. stay configured
> in the workspace. And have nothing to do with the project files. I
> guess that is where run/debug profiles are kept also.

Then this is even better and you don't have to actually deal with such issues.

Bye
Alex