[cmake-developers] COMPILE_FEATURES, Mac and non-Apple clang versions

[Craig Scott]

On Fri, Jan 6, 2017 at 11:57 AM, Stephen Kelly <steveire at gmail.com> wrote:

> Craig Scott wrote:
>
> >> if you use add_subdirectory with top-level projects which don't
> >> explicitly do something like that, you're getting undefined , and
> >> generally unexpected behavior in many ways.
> >
> > This seems at odds with the CMake documentation for
> > cmake_minimum_required(). That documentation talks about calling
> > cmake_minimum_required() within a function as a valid case
>
> I don't know why using that command inside a function would be a good idea.
>
> What would you be trying to achieve with putting it in a function not near
> the top? Can you give an example?
>


That wasn't my point, I was only indicating that the documentation seems to
indicate it's a valid thing to do. I wouldn't argue that's it's a *useful*
thing to do. ;)



> > We have many projects which do exactly the scenario you mention above
> > where a project can be built standalone or added to another project via
> > add_subdirectory(). We have not found it necessary to test if a project
> is
> > top level or not before calling cmake_minimum_required().
>
> My comment should have been more-general in that the contained project
> should be designed to be 'inlined as a subdirectory' like that and it
> otherwise shouldn't be done.
>
> There are many pitfalls. I have encountered at least one pitfall resulting
> from cmake_minimum_required being unconditional which I don't remember now
> unfortunately. Perhaps the problem was my inexperience to understand
> messages I was seeing and what I expected from the code.
>
> Others include
>
> * conflicting target names
> * conflicting option()s, or option()s which shouldn't be exposed
> * modification of global or cache variables affecting the container project
> in unexpected ways such as modifying compile flags
> * possibly odd behavior if you have multiple include(CTest) or
> include(CPack) in different directories
> * projects which assume CMAKE_SOURCE_DIR is their top-level and use
> something like include($CMAKE_SOURCE_DIR}/cmake/MyPrivateMacros.cmake)
> * deliberate checks for top-level in a file include()d in multiple
> locations
> in the project.
>
> Sure, you can test things out when you add a new
>
>  add_subdirectory(random_github_clone)
>
> but just because it works (enough! - do any of them use CMAKE_SOURCE_DIR
> and
> it doesn't cause *visible* problems?) with all of the external projects
> you've tried so far doesn't mean you can expect it to work with any
> external
> project.
>
> For me, that's as close as you get to 'undefined behavior' in CMake code.
>
>
We use the approach mostly with projects under our control, so we can
address the various issues you mentioned such that projects are safe to use
in this way. Even for the 3rd party projects we use, we set the git tag to
a known sha and can work through any issues to get the behaviour we want
for that specific snapshot of their code in most cases. There are a few
tricks you can use to inject things into such projects without having to
edit them (e.g. fixing missing INTERFACE dependencies with the various
target_xxx commands and using the CMAKE_PROJECT_<PROJECT-NAME_INCLUDE
variable to inject addition CMake code). But your point that you are at the
mercy of such projects assuming they are the top level project is one of
the more annoying aspects of using this approach.


-- 
Craig Scott
Melbourne, Australia
https://crascit.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170115/a12bb413/attachment.html>