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

[Doug Schaefer <dschaefer@xxxxxxx>]

Once I get through a couple of things with Arduino and Qt, I’m going to
start CMake plug-ins for CDT 9/Neon so we can get that ball rolling.

I like the steps you describe and that’s similar to how the Qt builder
works. We’ll try and do the same for CMake.

There will be some interesting things to figure out, the main one being
how to map launch targets that you build for to the toolchain and to a
toolchain definition file to use with CMake. Then how to get the compile
options from CMake to feed scanner discovery. Hopefully it’s similar to
qmake which I can dump pretty much every variable that feeds into the
Makefile generation.

I am still looking for people to help once I get the start. I am
stretching myself pretty thin these days.

Doug.

On 2015-12-01, 5:13 PM, "cdt-dev-bounces@xxxxxxxxxxx on behalf of Martin
Weber" <cdt-dev-bounces@xxxxxxxxxxx on behalf of
fifteenknots505@xxxxxxxxx> wrote:

>Am Freitag, 27. November 2015, 19:56:35 schrieb Doug Schaefer:
>...
>> In the end though, I want to build CMake support on top of the new build
>> system which should eliminate the problems you mention, and possibly
>> introduce new ones. I¹m well into the Qt qmake support and it¹s turning
>> out really well.
>
>I found a post by one of the project leads of cmake [1] who apparently
>took the 'ownership' of the `Generate buildsystem metadata` [2] feature
>proposed by the
>kdevelop guys.
>Sounds promising. 
>
>From my point of view, building a project meta-driven by CMake, CDT needs
>to do the following:
>
>1) Generate the output dir, if not present.
>2) Generate the build scripts in output dir, if not present by invoking
>cmake.
>There is no need to re-generate these when a user changed the meta build
>script
>(CMakelists.txt), cmake handles that by itself.
>3) Run the actual build tool (which can be ninja, make, mingw32-make,
> and others). This might be tricky, cmske4eclipse [3] parses the cache
>file to determine the actual tool. Depending on the
>buildscript-generator, that information may be missing.
>Fortunately, newer versions of cmake (3.x) have a command-line option for
>that: `cmake --build <target>`.
>4) Tell the indexer about include paths and pre-processor macros.
>A file with buildsystem metadata as proposed in [2] would be of great
>help.
>My plugin parses the output of the actual build-tool, but that fails if
>compiler
>invocations do not show up in the build output:
>
>- `make` runs with -s option or .SILENT is in the makeflie.
>
>- On windows, cc gets its commandline options from a response file, e.g.:
>`gcc @options_file`; no chance to grab include paths in this case.
>
>- 'ninja` suppresses commandline output on its own behalf, it uses an
>environment var to specify the output format. (Newer versions have a
>-verbose option)
>
>To summarize:
>It would be of great help to integrate CMake support in CDT, if cmake
>would be able to spit out `buildsystem metadata`.
>But I could not find any bugs mentioning `buildsystem metadata` in the
>cmake traccker.  Time for a project-L2L talk?
>
>
>For users stuck to CDT < 9.0/cmake < 3.5, there is a workaround [3].
>
>Cheers,
>	Martin
>
>
>[1] https://cmake.org/pipermail/cmake-developers/2015-March/024666.html
>[2] 
>http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/foc
>us=12650
>[3] https://marketplace.eclipse.org/content/cmake4eclipse
>
>-- 
>Cd wrttn wtht vwls s mch trsr.
>
>
>_______________________________________________
>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