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

[Tobias Hunger]

Hi Stephen,

On Sat, Mar 21, 2015 at 10:56 AM, Stephen Kelly <steveire at gmail.com> wrote:
> So, the design question I have is:
>
> * Is lots of repetition ok in the metadata file?

If it can not be avoided, then so be it.

> 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.

... or define a group of files, put all the files into that group and
add the other relevant flags.

If there is a file that needs something different, then just add that
as a separate group.

In the normal case where all files have the same flags applied the
overhead should be close to the minimum. And it still allows for
having different settings for different groups of files without the
IDE needing to combine settings. E.g. if main.cpp defined "TEST=1",
while the main-target defined "TEST=2", which one will win?

Please do not require all IDEs to implement logic found in cmake.
There will always be corner cases where this will fail, leading to a
broken code model in the IDE.

> 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.

I am not sure I understand cmake well enough to do that correctly:-/
But I'll give it a try.

>> 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.

Attached you find something that is close to what I want. I moved the
sections in your version of that file around a bit in a text editor,
so this might not be valid json:-) This does not really cover the
conditions though, as those were not in your file either. Note how the
main.cpp is handled differently from your proposal.

i do not see configurations as much of a problem in such a setup: Just
add them as tags to each group of files (and each target). That way
the configurations can be handled just as the other differentiators
(language, type) in the file groups/targets. That should reduce the
duplication, still be pretty readable and should be reasonably simple
to parse.

Best Regards,
Tobias
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cmake-metadata-Linux-GNU-4.9.json
Type: application/json
Size: 22878 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150322/527f85fa/attachment-0001.json>