[cmake-developers] How to handle configurations (Was: Generating buildsystem metadata from CMake)

[Stephen Kelly]

This seems to be to be a design point which we are blocked on. There are 
many different ideas floating around. 

I think we need to talk about what would be generated for actual CMakeLists 
files, and how tools would parse the result. I suggest starting with the 
Tests/Metadata/CMakeLists.txt file in my clone. 

I think we need to see both json files and prototype parsers in some 
mainstream language or framework (Qt5,Python etc) in order to see whether a 
particular proposal is viable. 

For my proposal there is already a generated json file checked in as an 
example, and a python class for extracting the information. 

The requirements for the metadata file include

1) Make it easy to get relevant information without extra computation/logic.
2) Be as DRY as possible.
3) Design something that is possible for cmake to generate.

The first two requirements are obviously in direct conflict. 

The third will I'm sure be a limitation compared to what you desire. If some 
part of what you propose is impossible, we'll either have to design a way to 
make it possible, or accept that it is impossible and update the proposal. 
Hopefully this will converge on a design which provides both what is needed 
and what is possible.

Implementing it will be easy then.

Tobias Hunger wrote:
>Anton Makeev wrote:
>> 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: {...}
>>  }
>>  ...
>> }

If we do this, then we have N repetitions of exactly the same data, or 
almost exactly the same data. It could be a lot of data. Is that a problem?

For machine reading it is probably not a problem. All the repetition does 
make it harder for human reading though of course. I also don't know at what 
point does it become slower for the IDE to have to parse ~4-6N times the 
amount of data. If the configuration is a 'mode' and only one configuration 
is active at a time, you're not using the other stuff anyway. 

If you want all the data for all configurations (even inactive ones) for 
some reason, then the repetition probably doesn't matter at all. Even with 
my proposal of separate files, you would want to load all the files anyway. 
Is that the case?

So, the design question I have is:

* Is lots of repetition ok in the metadata file?

The answer will be re-used in many other places. For example, if I have a 
CMakeLists like

 add_executable(main
   file1.cpp
   ...
   fileM.cpp
 )
 target_include_directories(main ...)
 target_compile_definitions(main ...)

then we could either write the definitions and includes once (associated 
with the target), or we could repeat them all M times (once for each file). 
That could be lots and lots of repetition, repeated N times, once for each 
configuration.

I personally prefer minimising the repetition, as I did in the unit test I 
pushed to my clone. I have the feeling you guys have not looked at the unit 
test I pushed to my clone. Please go ahead and do that if not. Also, when 
proposing json formats, please imagine how your proposal would represent the 
data in Tests/Metadata/CMakeLists.txt.

Anton, in your proposal, given that realistically Makefile and Ninja 
generators are not going to become aware of multiple configurations before 
this feature reaches master, what should they generate?

  project: ProjectName
  configurations: {
  {
    name: WHAT_WAS_IN_CMAKE_BUILD_TYPE
    targets: {...}
  }
 
or

  project: ProjectName
  targets: {...}
 
or

  project: ProjectName
  configuration: WHAT_WAS_IN_CMAKE_BUILD_TYPE
  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:

Could you post what would be generated by your proposed structure for the 
unit test file in my branch?

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

How does the design goal of 'avoid duplication' weigh against the design 
goal of 'don't make me combine multiple properties together to get relevant 
information (eg target defines and additional source defines)', in general?

We can either go for one extreme or the other, but I don't think it makes 
sense to go for something in between. That would be the worst of both 
worlds.

So, for the proposals which are on the table, please either use the 
Metadata/CMakeLists.txt file in my clone, or post an alternative together 
with the json which you propose we should generate for it, and a prototype 
or pseudo-implementation of a parser for that json.

Thanks,

Steve.