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.
On Thu, Oct 6, 2016 at 9:38 AM, Stephen Kelly <steve...@gmail.com> wrote:
> Brad King wrote:
>
> > The scoping doesn't
> > match the generator semantics exactly, but it is easy to use and
> > hasn't been a big problem.
>
> My mail is suggesting that it is a problem and is undesirable to maintain.
>
> Big is subjective, and there are not many complaints, because generally
> people don't try to set things like this per-directory (and if they did it
> would probably mostly do what they expect).
>
> The problems are
>
> 1) It is a behavior which is often not intended by the programmer.
> 2) It makes refactoring harder if such unintended behavior must be
> preserved.
> 3) It is unintuitive, because code such as
>
> set(FOO ON)
> project(p)
> add_library(bar ...)
> set(FOO OFF)
>
> looks like FOO is ON when defining the project and the target, but in
> reality it is only the value at the end of the directory that is consumed.
>
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. Given that it
is not unusual (but not necessarily wise) for projects to fiddle with
variables like CMAKE_CXX_FLAGS in subdirectories which could be brought in
via include() rather than add_subdirectory(), 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?
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. They serve
as defaults for target-specific properties at the point of the target being
defined. Not sure if that helps with the original topic of discussion here
though.
>
> 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.
--
Craig Scott
Melbourne, Australia
https://crascit.com
--
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
