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

[Doug Schaefer <dschaefer@xxxxxxx>]

From: <cdt-dev-bounces@xxxxxxxxxxx> on behalf of Alexander Neundorf <neundorf@xxxxxxx>
Reply-To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Date: Thursday, October 8, 2015 at 5:21 PM
To: "cdt-dev@xxxxxxxxxxx" <cdt-dev@xxxxxxxxxxx>
Subject: Re: [cdt-dev] Antwort: CMake support in Eclipse CDT

On Thursday, October 08, 2015 11:36:49 Martin.Runge@xxxxxxxxxxxxxxxxx wrote:

> > 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

> >

> > > 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.

 

Ah, hmm.

For cmake it wouldn't be Ok to generate a file in the source tree (i.e. the .project and .cproject file next to the CMakeLists.txt), but for Eclipse this is different.

So, currently the .project and .cproject files cannot be shared between users or between different builds. They currently contain e.g. the build targets, the include dirs and more.

For us, we do not use CMake to generate the .project and .cproject. The user uses the CDT’s new project wizard to create those and create a project that calls CMake to generate the Makefiles (or Ninja files, etc.)

The CDT generator for CMake does something quite different. CDT is meant to be cross platform and if we had infinite resources would support all the platforms that CMake has IDE generators for. We almost compete that way because if we did our job right, you wouldn’t need those generators since you’d be using CDT for Windows and Mac projects. But that’s still a dream :).

 

This will all be removed and everything will be parsed from the compile_commands.json file ?

The idea is that the CMakeLists.txt files is the place where you store everything and we introspect those files using tools CMake provides where possible to find out the information the CDT needs. We’d add a slim layer to describe build configs but that should be kept small and probably only the arguments to CMake for each config.

 

So the user will then be able to choose e.g. "Import cmake-based project", and this will create the .project and .cproject files next to the CMakeLists.txt ?

Yes, we should do that too.

BTW, when we get CMake support in CDT there won’t be a .cproject file (or it’ll be empty). It would use the new build system which stores it’s information in Project Scoped Properties which end up as property files in the .settings directory.

 

...

> > > 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.

 

it's these two threads:

http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711

http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/12658

 

Alex