Re: [cdt-dev] Antwort: CMake support in Eclipse CDT

[Martin.Runge@xxxxxxxxxxxxxxxxx]

> Von: Alexander Neundorf <neundorf@xxxxxxx>
> An: cdt-dev@xxxxxxxxxxx
> Kopie: Martin.Runge@xxxxxxxxxxxxxxxxx
> Datum: 2015-10-07 21:07
> Betreff: Re: [cdt-dev] Antwort: CMake support
in Eclipse CDT
> 
> On Tuesday, October 06, 2015 18:04:41 Martin.Runge@xxxxxxxxxxxxxxxxx
wrote:
> > Hi Alex,
> > 
> > I adopted
> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=350206
> > and expanded it silently to full cmake support, not just scanner
> > discovery. The current state of the implementation is hosted
here:
> > https://github.com/rungemar/cmake4cdt
> > 
> > I agree with what you said about the "one thing causing
lot of issues".
> 
> Is there a chance this could be "fixed" ?
> I know CDT is a separate subproject of Eclipse, but I have no idea
how strong 
> the separation/the ties are.

I am not sure, afaik this comes from Eclipse itself
or even Java: everything that belongs to a project must be located in subdirectories
of the project root. And this make sense to me as it is a simple rule that
all tools can easily follow to do something with a project.
Although this simple rule has been weakened a little
by linked ressources/virtual folders, the project root still is a folder
marked by a hidden file (confuses VisualStudio users here). 

I also ran into this issue. It is possible to arrange
everything in the project explorer with virtual folder, but me and my collegues
fond it very confusing to have all this additional information presented
in that treeview where you expect just your own work.

Maybe someone else can give a better answer to this.

> > My approach is like this:
> > - .project and .cproject stay at the projects root and can be
checked in
> > (new project type: CMake project)
> 
> if I understand correctly, the directory layout is something like
this:
> 
> yproject/
> myproject/.project
> myproject/.cproject
> myproject/src/
> myproject/build-debug/ 
> myproject/build-release/ 
> myproject/build-whatever/ 
> 
> In which directory is the top-level CMakeLists.txt located ?

myproject/CMakeLists.txt

next to .project and .cproject and all three can be
shared between users.

the the plugin calls 
cmake -DCMAKE_BUILD_TYPE=debug ..   (from within
myproject/build-debug)
cmake -DCMAKE_BUILD_TYPE=release ..   (from within
myproject/build-release)
cmake -DCMAKE_BUILD_TYPE=debug -DCMAKE_TOOLCHAIN_FILE=raspitc.cmake
..   (from within myproject/build-whatever)

> 
> > -->  as a result, Eclipse's integration of version control
systems works
> > like expected
> > - CMake's out of source build is used, one build output subdir
per build
> > configuration
> > --> Eclipse will find the build output and can automatically
create a
> > launch configuration, for example,
> >      or use its binary parsers, etc... The output
stays related to the
> > project.
> > - per build configuration, different cmake invocations are supported
> > (CMAKE_BUILD_TYPE, CMAKE_TOOLCHAIN_FILE, -D, -G ...)
> > --- its is simply possible to send a project through a cross
compiler by
> > chaning the build configuration
> > --- I am not sure yet if it is neccessary to have one configuration
build
> > with make and the other one with ninja, but what do I know?
> 
> Not quite sure I understand:
> switching between make and ninja in one build tree is not possible,
so 
> separate build trees are required if somebody wants to have a build
with make 
> and another one with ninja.
> Or are you just wondering whether supporting ninja is actually necessary
in 
> Eclipse ?

cmake is called in different build folders per configuration
and produces single configuration Makefiles. So actually it is possible
to use different generators in different (CDT) build configurations. Changing
the generator requires a complete clean (e.g. delete and recreate the build
folder).

I don't know myself if this is neccessary or if someone
needs it, but by now, I don't see any restrictions that prohibits it. If
using different generators in different CDT build configurations, the error
parsers must be per configuration, too. The new build model (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=321443)
should support this. Actually it does not differ much from the case that
one build configuration uses a different compile than the other, they might
need different error parsers, too. 

> > - the cmake plugin will parse the compile_commands.json file
> > --- from that information, it can guess the compiler and set
the
> > corresponding error parser
> > --- scanner discovery: include paths, defines
> > --- detect source files outside of the eclipse project that get
compiled
> > (cmake set( SRC ../file.cpp) ) and place them into a virtual
folder inside
> > the eclipse project
> > 
> > so actually, new CDT project nature and then read all the neccessary
> > information out of the compile_commands.json file.
> 
> There is "currently" work going on to extend cmake in that
> direction, i.e. not 
> only generated the compile_commands.json file, but much more ("currently"
> because the discussions on the cmake-devel list are a few months ago,
but 
> Steven is working on it). Maybe that's interesting for you.

Yes, very intresting, indeed. Thank you.I'll hav a
look at it.

Martin