Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Antwort: CMake support in Eclipse CDT

On Friday, October 09, 2015 14:11:48 Doug Schaefer wrote:

> From: <cdt-dev-bounces@xxxxxxxxxxx<mailto:cdt-dev-bounces@xxxxxxxxxxx>> on

> behalf of Alexander Neundorf <neundorf@xxxxxxx<mailto:neundorf@xxxxxxx>>

> Reply-To: "CDT General developers list."

> <cdt-dev@xxxxxxxxxxx<mailto:cdt-dev@xxxxxxxxxxx>> Date: Thursday, October

> 8, 2015 at 5:21 PM

> To: "cdt-dev@xxxxxxxxxxx<mailto:cdt-dev@xxxxxxxxxxx>"

> <cdt-dev@xxxxxxxxxxx<mailto:cdt-dev@xxxxxxxxxxx>> Subject: Re: [cdt-dev]

> Antwort: CMake support in Eclipse CDT


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

> > > Von: Alexander Neundorf <neundorf@xxxxxxx<mailto:neundorf@xxxxxxx>>

> > >

> > > An: cdt-dev@xxxxxxxxxxx<mailto:cdt-dev@xxxxxxxxxxx>

> > >

> > > Kopie:

> > > Martin.Runge@xxxxxxxxxxxxxxxxx<mailto: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.)


That's clear so far.

In the root there will be the .project file, and the CMakeLists.txt, and Eclipse will run cmake in build-subirs to generate makefiles/ninja files.

Sounds good so far.


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


Sorry, I don't understand this sentence.

Both CMake and Eclipse support (let's stay with the major systems) Windows, Linux and OSX. I don't know for which compilers Eclipse supports error parsing, it's at least gcc.


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


I still don't get what you mean.

You can right now use CDT for Windows and Mac projects.


All that cmake does is to process build scripts (CMakeLists.txt) and from that produce build files for the various build tools, which can be e.g. Makefiles or Visual Studio project files, just what the build tool of choice needs.


CMake does not provide an editor, or syntax highlighting, or code navigation, refactoring support, debugging, etc., so there is potential overlap only in driving the actual build.


So, if CDT wants so, cmake could generate just e.g. xml-files containing some information about the targets, and CDT could take care of the dependencies and compiler invocations.

Or, if CDT wants to stay out of the dependency handling business and compiler flags, cmake can generate the complete files which do the build (Makefiles or ninja files) and additionally some xml/json/whatever files which provide the necessary information, e.g. about targets to Eclipse.


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


Hmm, what do you have in mind when saying "introspect those files" ?

Parse and execute cmake commands ?

This is something I would recommend not to do.

What information does CDT need in detail ?

Probably it needs to know what compiler is used.

Does it have to know which targets exist, so they can be listed in the targets tab ?

Does it need to know the type of the targets (library, executable, helper target, ...) ?

I guess it needs to know the location of the produced executables, so it can start debugging ?

Does it e.g. need the list of builtin include dirs ? Or does CDT want to figure to that out by itself ?

The same for the builtin macros/defines...


It is actually IMO exactly cmake's job to generate files for the IDE with exactly the information the IDE 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.


I would like to have that very much.

It would be great if both workflows would work flawlessly.

For that to be possible, the .project file would have to be very simple, so that multiple build trees can write into the same .project file without messing it up.

E.g. cmake could generate a cdt.xml in each build dir, and cdt could just search in all direct subdirs of the project dir for these files and read them.



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


I have to dig into this again, but I can remember that I was not happy with those files for some reason.




Back to the top