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

[Stephen Kelly]

Tobias Hunger wrote:

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

It can be avoided at the cost of computation. I thought that was more clear 
in my mail.

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

This still just pushes a computation requirement to you the consumer of the 
file. 

The reason I'm asking about duplication versus computation is because of 
what you wrote:

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/12658/focus=12750

Tobias Hunger wrote:
> Can't we go for a syntax where the files and everything that applies
> to them are grouped so that there is no need to reimplement the logic
> found in cmake (with added bugs:-)?

If the concern that computation means bugs is the primary concern then we 
should duplicate a lot of information. Also, the outcome of how we should 
generate compile flags could have an influence on what we duplicate. Anton 
will hopefully respond. 

I don't believe we'll have a huge problem with bugs processing the json. It 
will have a schema and documentation telling you how to consume it. If it is 
consumed in multiple steps (eg with processing of your 'source group' idea 
etc), then I think that's fine. We simply document how it's done. It's no 
different to any other data format in that sense. A spec is needed to 
implement the logic of parsing json too, and there are many json parsers out 
there. I'm sure some have hard-to-reach bugs, but all software has hard-to-
reach bugs.

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

I guess this relates to why Anton wants the actual command line.

That's undefined behavior. I guess it could be made defined.

I filed

 http://public.kitware.com/Bug/view.php?id=15472


> 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 agree we don't want to require implementing logic found in CMake. I do 
think we should be allowed to require 'implementing well defined and 
specified logic', as you do too judging by your source groups idea.

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

Thanks for this. Actually I guess the generated file for that test is too 
big to do sensible comparisons.

I basically want to see a proposal which is more complete than many 
different ideas of snippets and lots of '...', and I want to see how a 
consumer would process the file. Maybe we should start with a simpler CMake 
file.

> This does not really cover the
> conditions though, as those were not in your file either. 

The conditions are handled in my file. Files which do not match the 
condition all go into the 'excluded files' group. I implemented it that way 
because of this quote from you:

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=11323

> > I wonder how those kinds of conditions would need to be represented in
> > the ProjectTargets.json file.
> 
> This is actually a bit too detailed for my needs:-)
> 
> I want to know which files are part of the project and which are part
> of the current build.
> 
> At least Qt Creator does not need information on which conditions to
> be met for a file to become part of the current build.

The 'object sources' are files which will be compiled. The 'excluded' 
sources will not be compiled, but they are 'part of the project' as you 
seemed to describe above before.

Also, note that in my json file, there is not a generic 'files' property 
because cmake has more information than just 'files' - it has information 
about which compiler is used for the files to compile objects, which files 
are not going to be compiled at all etc. My design gives you that 
information, but a 'files' array discards it.

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

The configuration is not like other differentiators. That's the topic of 
other mails.

Thanks,

Steve.