[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdt-dev] Cmake support
|
Am Fr., 24. Jan. 2020 um 17:16 Uhr schrieb Jonah Graham
<jonah@xxxxxxxxxxxxxxxx>:
>
>
> On Fri, 24 Jan 2020 at 10:56, Aleksandar Kurtakov <akurtako@xxxxxxxxxx> wrote:
>>
>> It can be done but it has to be for exact cmake4eclipse version and after CQ is approved - but if you do that cmake4eclipse can be included in the CDT repo even.
>
>
> If it can be done I think we should do it if the community sees value. The direction is towards cmake (and other tools) and away from Eclipse making makefiles. If we can just include (with CQs) cmake4eclipse in CDT and/or Eclipse for C/C++ Developers we should provide one solution for the community.
>
> My question then is does anyone rely on core build version of cmake? Is there anyone planning on doing any development work in that area. CDT ecosystem, to have a successful future, needs proper cmake support and needs to have a system that users aren't provided with confusing or incomplete solutions.
I'm with Doug here: Abandon MBS. cmake4eclipse may be the best
solution for MBS, but being based on MBS it inherits project settings
tabs that are of no use for building with cmake and just confuse
users. *Any solution based on MBS for building with cmake will suffer
from this.*
These tabs are:
Tool Settings
Build steps
Build Artifact
Tool Chain Editor: Used tools [1]
Language Mapping? (I newer figured out whats that for)
Path and Symbols : Includes
Path and Symbols : References
Oh, and I saw saw that CoreModel has some documentation now!
So Core build is the way to go.
Martin
[1] Actually it is required to have at least a compiler in the used
tools list, otherwise the Settings Entries on the Preprocessor
Includes tab will not show any paths not macros. Not sure whether that
affects the indexer.
And CUDA coders need a way to add the CUDA compiler to see their include paths.