| Re: [cdt-dev] CMake support in Eclipse CDT |
|
On Tuesday, December 01, 2015 23:13:58 Martin Weber 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`.
I fully agree. Using "buildsystem metadata" would IMO be so much better than trying to parse (and execute) cmake language in CDT.
Alex
|