[cmake-developers] Generating buildsystem metadata from CMake

Tobias Hunger tobias.hunger at gmail.com
Thu Mar 19 10:54:33 EDT 2015


Hi Anton,

you raised some good points, all of which I agree with:-)

On Thu, Mar 19, 2015 at 10:18 AM, Anton Makeev
<Anton.Makeev at jetbrains.com> wrote:
> * If it is useful to preprocess/compile/assemble individual files from
>  IDEs, as made possible by the Makefiles and Ninja generators, we'll need
>  to design that.
> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12429
>
>
> This is definitely useful, but I’m not sure what kind of information needed
> here,
> as I see it, since we already know the files in the project, we can tell
> make/ninja to simply compile it.

You asked me to use "cmake --build", so ideally that would be "cmake
--build . /full/file/path" and ideally it would work with all
generators without magic in the IDE:-)

Since I assume that not all build systems will allow to build
individual files, you might want to add a flag
"can_build_individual_files" or similar to the metadata that a
generator can use to flag the IDE on whether the generated build
system can build individual files or not. Then the IDE can hide that
option if it is not applicable.

> * Some more information from project() may be relevant, but it's not clear
>  yet. We will likely know more when we have decided the file format and
>  generated some 'interesting' metadata files.
>
>
> Project name, list of the configurations are most needed ones.
> We also use CMAKE_<lang>_SOURCEFILE_EXTENSIONS to determine if a given file
> is potentially source file or not.

I would also love to see subprojects:-) CMake allows for them, doesn't it?

Will you still need CMAKE_<lang>_SOURCEFILE_EXTENSIONS when you can
get access to the list of sources as above where each group of files
is flagged with the language, etc.?

<snip>

> As a side note, it seems more natural to me to have one json file with one
> or several configurations listed, providing that there is also shared
> project info that should be in that files.
> something like that:
>
> project: ProjectName
> configurations: {
>  {
>    name: Debug
>    targets: {...}
>  },
>  {
>   name: Release
>    targets: {...}
>  }
>  ...
> }

I'd actually prefer having a "configurations" key with the list of the
configurations an object applies to.

That can be optional if the object is relevant to all configurations
(default in single-configuration generators;-).

This key would then need to be applicable to targets as well as the
group of source files.

So that would be something like this:

{
  project: "TestProject",
  targets: [ {
    name: "Debug only",
    configurations: [ "Debug" ],
    type: "EXECUTABLE",
    sources: [ ... ]
  },
  {
    name: "Release only",
    configurations: [ "Release" ],
    type: "EXECUTABLE",
    sources: [ ... ]
  },
  {
    name: "Run Tests",
    sources: sources: {
    language: "C++",
    defines: "FOO=1",

    sources: [ {
      type: "sources",
      name: "Critical source files",
      configurations: [ "Debug" ],
      include_paths: "/some/path",
      files: [ "/full/path/a.cpp", "/full/path/b.cpp" ]
    },
    {
      type: headers,
      files: [ "/full/path/a.h" ]
    },
    {
      type: generated,
      files: [ "/full/path/config.h" ]
    },
    {
      type: "sources",
      name: "Tests",
      include_paths: "/some/path",
      files: [ "/full/path/a.cpp", "/full/path/b.cpp", "/full/path/test.cpp" ]
    } ]
  }
}

That would most likely avoid quite a bit of duplication in the file(s).

>  This also means that conditions don't need to be added inside the metadata
>  file for configurations in order to show files 'excluded' by being part of
>  a non-active configuration.  The code implementing discovery of excluded
>  files is in the generate-metadata branch in my clone.

Yeap, that would be a convenient property for me, too.

<snip>

> * Generating metadata only (without generating buildsystem files) is not
>  currently in scope.  This was requested several times, but it is not
>  clear why.
>
>
> It’s simply to be able to get this the information as quickly as possible.
> I’m not sure which part is most slow, but, say, InsightToolKit 4.5
> (http://www.itk.org/Wiki/ITK/Source), generates in couple of minutes. The
> regeneration, even when nothing was changes, a few dozens of seconds.
>
> Plus, we’d prefer being able to open the project without any questions to
> user, e.g. not asking, which generator he/she prefers. If we generate using
> ‘wrong’ default generator we’ll need to regenerate everything again when
> user decides to change it.
>
> Another benefit of skipping actual generation is possibly better error
> recoverability.
> That is, some generators may fail here and there if the project is
> incorrectly configured (e.g. source files are missing). Skipping the
> generation phase will (probably) help getting the project metadata even in
> that case.
>
> But anyway, it seems a little outside of the scope of the discussion.

Very good points that I fully agree with.

> * How much information does tooling need about installation?  Targets
>  can use different include directories and compile definitions in their
>  install locations compared to their build locations.  If IDEs want to
>  provide some user interface related to the project files in their
>  install location, perhaps a separate solution based on cmExportFile*
>  is needed.  For future investigation.
>
>
>
> An additional though: here only the 'project information' aspect is
> discussed; though, to be fully machine-frienly, cmake should be able to also
> generate parseable output (error reports etc), provide the progress, etc.
> So, just to mull over, probably the discussed design should consider such
> future direction.

Yes, that would be great, but I do not see how cmake can do that: It
delegates the actual build to external tools.

So in the end during a build we will always have to deal with whatever
output the generated buildsystem throws at us:-/ This again somewhat
limits the usefulness of allowing the user to pick whichever generator
they want: Some will just loose some or all the build issues.

Best Regards,
Tobias


More information about the cmake-developers mailing list