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.
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
