[cmake-developers] Generating buildsystem metadata from CMake

[Alexander Neundorf]

On Wednesday, March 11, 2015 11:10:30 Stephen Kelly wrote:
> Hi,
> 
> Following from the thread here:
> 
>  http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focu
> s=12394
> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focu
> s=12650
> 
> I'm starting to gather requirements and make sure the feature is
> well designed to satisfy the needs we're already aware of, and fits with
> the features CMake currently has.
> 
> The aim is to generate a structured file containing metadata relating the
> buildsystem.
> 
> To help with completing the design of this feature, I've written
> documentation (documentation driven design), and a unit test
> containing a CMakeLists.txt file which exercises many modern CMake
> features in the "generate-metadata" branch in my clone.
> 
> Mostly the design I propose can be read in the documentation I wrote. I'm
> interested in any feedback.
> 
>  https://gitorious.org/cmake/steveires-cmake/source/generate-metadata:Tests/
> Metadata/CMakeLists.txt
> http://www.steveire.com/cmake-future/manual/cmake-metadata-generation.7.htm
> l
> 
> I expect to require a few iterations to figure out what the metadata files
> should contain in the end.  Note that there are already some differences
> between my design and Aleix's implementation, such as that my design
> proposes one metadata file per config. There are also some things
> missing like location, because it is not yet clear to me whether build
> or install locations are needed etc.
> 
> The content of the metadata file is determined by the build properties, and
> is necessarily similar to the compile-related content created when
> generating the actual buildsystem.  It additionally contains information
> about the output locations of build artifacts and information relating to
> the cmake description itself.
> 
> Goals include:
> 
> * Make it possible for IDEs to access the compile-related information for
>   autocompletion and code navigation etc purposes.
> 
> * Remove the need for IDEs to parse generated Makefiles or Ninja files to
>   access compile-related information.  The structure of those files is not
>   'stable', while the content of the metadata file is stable.
>     http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/48412
> 
> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus
> =11081
> 
> * Remove the need for users to create a new build directory and new build
>   in order to use or switch IDEs.  QtCreator requires that
>   the C::B 'extra generator is used as it parses compile information from
>   that.  Other 'extra generators' such as for eclipse, sublime, kate etc
>   also require fresh/new build directories, although the actual buildsystem
>   they create is identical (assuming using all Makefile based or
>   all Ninja based 'extra generators')

>From my POV, the json metadata is just another "extra generator", but one 
which can be always enabled additionally to other generators.
You say that users don't need new build directories for switching IDEs, but 
this is only under the assumption that the different IDEs will actually start 
to use this new file format.
See, users can use the C::B format and switch between CodeBlocks and 
QtCreator. If KDevelop and Kate would get plugins to read the C::B format 
(which is technically entirely possible) their users also would't have to 
create a new build directory.
So instead of adding generators to cmake which generate what the IDEs expect, 
this is a change, now cmake will generate a file and the IDEs are expected to 
follow.

My 2 cents
Alex