Re: [cdt-dev] Introduction

[Doug Schaefer <dschaefer@xxxxxxxxxxxxxx>]

On 2016-07-18, 4:03 PM, "cdt-dev-bounces@xxxxxxxxxxx on behalf of
c.sell@xxxxxxxxxxxxxxx" <cdt-dev-bounces@xxxxxxxxxxx on behalf of
c.sell@xxxxxxxxxxxxxxx> wrote:

>Hello Doug,
>
>> The CMake support we have is very early. I don¹t think it¹s even in the
>> build artifacts yet. But I am looking to CMake as a great way to support
>> multi-platform builds just as qmake does,
>
>currently, I cannot make out of what use the CMake support in eclipse
>is. When creating a new CMake project and trying to build it, all I
>get is an error message "Build not configured correctly".

My suggestion was to look at the code. I’m not surprised it doesn’t work
right now, that’s why it’s not included in our release yet.

Our CMake support is based on CDT’s new, much simplified and more flexible
build model. It hasn’t been adapted to the most recent changes as I was
focused on qmake with the CDT 9.0 release. I will be getting this running
in the next few days.

>
>> We might have a difference of strategy though. My thoughts were to have
>> CMake projects as single projects rooted at the directory you point
>>cmake
>> at meaning it could contain many executables and libraries in a single
>> project. Combined with EGit¹s newer support for submodules, it just
>>feels
>> like a more natural way to work. And it¹s something we¹ve been doing at
>> QNX for a while with BSP projects which contain multiple drivers (which
>> are executables with QNX¹s microkernel architecture) and libraries and
>> such.
>
>my "strategy" would be to support anything you can do with CMake.
>Otherwise, its not CMake support IMO. My ideal would be to somehow
>adapt the CMake object model to the eclipse-internal object model, as
>CLion seems to be doing it. QtCreator also handles CMake seamlessly. I
>wouldn't want to go through some json file that is output by CMake,
>but rather directly access their classes.

That would be interesting. Though CMake is written in C++ which would make
it pretty hard to use their classes directly. That’s why we propose using
the current json, with any future enhancements, as an interchange format.
But if you think you can put something together, that would be interesting.

>
>I also think that the apporach both take in terms of UI is fair: let
>the user edit the CMake file, monitor changes and reload it once (s)he
>is done.

That is our plan as well. We just need a nice editor for syntax
highlighting and to offer content assist, and things like that. One thing
we do with qmake project files is automatically adjust the list of source
files as they’re added/removed from the project. That might be trickier
with CMake files as there could be multiple source lists, but we could
support a best effort.

Our current strategy is to just call CMake to generate Makefiles (or Ninja
files more likely) and somehow extract the scanner info settings we need
from that, and provide a nice editor for the CMakeLists.txt files. That’s
the minimal feature set to claim “support”.

But those that do the work have the most influence so feel free to forge
ahead. And there is plenty of work to go around.


Doug.

>
>Chris
>
>_______________________________________________
>cdt-dev mailing list
>cdt-dev@xxxxxxxxxxx
>To change your delivery options, retrieve your password, or unsubscribe
>from this list, visit
>https://dev.eclipse.org/mailman/listinfo/cdt-dev