[cmake-developers] Generator options per-directory v. global

[Stephen Kelly]

Craig Scott wrote:

> I'm coming in half way to this discussion, so apologies if my comments
> interspersed below are not so well related to the core topic of
> discussion.

Hi Craig,

Thanks for your input.

> Consider the following example which perhaps better shows that this
> problem may not be as uncommon as first thought:
> 
>     set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -someOption")
>     add_library(foo ...)
>     set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -somethingElse")
> 
> I think most developers probably expect foo to not have the -somethingElse
> option when it is compiled, but I believe it would have it. 

The difference occurs depending on when the value is read. See my 
CMAKE_CXX_STANDARD example below.

> If I understand things correctly, directory *properties* don't typically
> have this unexpected behaviour as their value at the time of defining the
> targets is used, not at the end of that directory's processing. 

It all depends on when the value is read. Something that is read at 
configure-time appears to have immediate effect, regardless of whether it is 
a 'directory property' or a set() 'definition'. 

When something that is read at generate-time (such as CMAKE_CXX_FLAGS) it 
takes on the value at the end of the directory.

You might be referring to things like this, which are still 'definitions' 
not 'directory properties':

 set(CMAKE_CXX_STANDARD 11)

 # Reads CMAKE_CXX_STANDARD 'now' at configure time
 add_executable(foo ...)

 set(CMAKE_CXX_STANDARD 14)

 # Reads CMAKE_CXX_STANDARD 'now' again!
 add_executable(bar ...)


The important distinction is where in the CMake C++ code the 
cmMakefile::GetDefinition call occurs - generate-time code or configure-time 
code.

This is a sideline just for your information. What this thread is really 
about is whether things should be read 'only once' or 'once per directory', 
and whether the CMake C++ code chooses one or the other deliberately or 
accidentally, and what impact that has on maintainability and refactoring.

> this behaviour of using the
> variable's value at the end of the directory processing is likely a
> surprise to many and probably already causes some head-scratching until
> devs figure it out. Is the problem being discussed here relating to
> CMAKE_CODELITE_USE_TARGETS
> much different?

It seems like a related example to me. The CMAKE_CODELITE_USE_TARGETS 
feature is trying to be related to a project() command, but it is read at 
the end of the directory. Usually, I would think that is not a problem the 
way most people write project() commands and set these kinds of settings.

However, in the general sense of how 'global' settings should work, I think 
things could be better.

>> Those are not problems users or contributors adding features encounter,
>> so that might affect a perception of 'big'ness. These problems only
>> bubble up during refactoring or under longer-term maintenance when the
>> true semantics of the code become known.
>>
> 
> Perhaps a bit more common than that, as the above example suggests.

Yes, those kinds of examples are the things that I would expect to arise 
during maintenance, perhaps several releases after a feature hits master.

Thanks,

Steve.