CMake prints a spammy warning about "policy CMP0000"

[ulfalizer]

I'm a CMake noob, so I have no idea what the proper fix is here, but having 12 lines of spam about CMP0000 whenever you run CMake is pretty bad:

CMake Deprecation Warning at /home/ulf/zephyr/cmake/app/boilerplate.cmake:38 (cmake_policy):
  The OLD behavior for policy CMP0000 will be removed from a future version
  of CMake.

  The cmake-policies(7) manual explains that the OLD behaviors of all
  policies are deprecated and that a policy should be set to OLD only under
  specific short-term circumstances.  Projects should be ported to the NEW
  behavior and not rely on setting a policy to OLD.
Call Stack (most recent call first):
  CMakeLists.txt:2 (include)

[SebastianBoe]

This affects CMake version >= 3.9.0 so the simplest solution is to use CMake 3.8.x.

Last I looked into this I concluded that longterm we need to either fork CMake or convince upstream to allow projects to suppress this warning, as they were allowed to before 3.9.x.

Any other solution suggestions are welcome.

[ulfalizer]

What about not using "the OLD behavior for policy CMP0000", whatever that means?

[SebastianBoe]

IIRC that creates bigger problems than this warning, can't remember the details though.

[ulfalizer]

Probably worth looking into.

[ulfalizer]

@tejlmand
Do you know anything about this btw? :)

[tejlmand]

What CMake requires is the line:
cmake_minimum_required(VERSION a.b), e.g.
cmake_minimum_required(VERSION 3.8.2) as it is written in
cmake/app/boilerplate.cmake
to be placed in the top-level CMakeLists.txt file.
(CMake doesn't allow this line to be in an included file)

Setting the CMP0000 allows this line to be placed in another file
but as CMake warns, this will be removed in future.

So CMake tells us we should write:
cmake_minimum_required(VERSION 3.8.2)
include($ENV{ZEPHYR_BASE}/cmake/app/boilerplate.cmake NO_POLICY_SCOPE)
in all sample apps.

I'm unaware why it was chosen to not write this line in all CMakeLists.txt app files, but I could imagine that it makes life harder if bumping the CMake version in future as all files would need to be updated.

Although a search and replace should be easy in this case.
https://cmake.org/cmake/help/v3.11/policy/CMP0000.html

Out of curiosity I would like to hear more about what problems placing this line in sample apps is causing.

[SebastianBoe]

but I could imagine that it makes life harder if bumping the CMake version in future as all files would need to be updated

Yep. And more importantly, backwards-compatibility with customer applications.

[SebastianBoe]

I wonder, does CMake support multiple invocations of minimum required?

Then we would not have a compatibility issue when bumping the version ...

[SebastianBoe]

I imagine they don't, the whole point is for them to be able to determine how CMake should behave as early as possible ...

[ulfalizer]

Guess it might need to be changed anyway eventually, since the warning says that the behavior will be removed.

[tejlmand]

Multiple invocations of cmake_minimum_required is allowed.
This is very useful when you include other projects, which might have different requirements.

Imagine if you have project A, e.g. Zephyr, which requires version 3.8, and you then include mbedTLS, which requires, let's say version 3.10 in its CMakeLists.txt file.
Then CMake will complain if you're running version 3.9.

But versions 3.10 and above are fine, as it satisfies the versions specified for both Zephyr and mbedTLS :)

[tejlmand]

@SebastianBoe Do you know why version 3.8.2 is chosen ?
Is zephyr using any 3.8 specific features or was it just the version most people were running at that time, so it's not verified to work with older versions. (which is a very good reason)

For fun, I just tried run CMake version 3.5.1 without any apparent problems (except I had to specify a lower required version)

https://cmake.org/cmake/help/v3.8/release/3.8.html

[SebastianBoe]

Multiple invocations of cmake_minimum_required is allowed.

Great!

Then it is safe to duplicate the version information in every application AFAICT.

I can't recall how we landed on 3.8.2, you would have to check the git history, there has been a back-and-forth. If the version is too high it won't be packaged by distrubutions. If the version is too low you will lose out on features and bugfixes.

It might have been that we wanted to support 3.8.2 so that users could avoid the issue reported here. But since multiple invocations of cmake_minimum_required is permitted we might not need to work around it any more.

[henrikbrixandersen]

Still, git ls-files '**/CMakeLists.txt' | xargs sed -i '1s/^/cmake_minimum_required(VERSION 3.8.2)\n/' gives us approximately 780 added lines of boiler plate code...

[tejlmand]

you should disregard files under subsys/ ext/ kernel/, etc.
Only the entry point for the applications, i.e. all CMakeLists.txt files under samples/ and tests/.
which still amounts to roughly ~150 under samples and ~200 under tests.

Basically all the files which contains the line project(none) would most likely also need the line cmake_minimum_required()

[SebastianBoe]

@henrikbrixandersen : Yes, not great, but for those that use CMake version > 3.8.x I believe this is the best solution (apart from convincing upstream to re-introduce support for having cmake_minimum_required outside of the toplevel CMakeLists.txt).