Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New CMake setup fails on cmake 3.12 #457

Closed
axxel opened this issue Jul 18, 2019 · 5 comments
Closed

New CMake setup fails on cmake 3.12 #457

axxel opened this issue Jul 18, 2019 · 5 comments

Comments

@axxel
Copy link
Contributor

axxel commented Jul 18, 2019

CMake Error at IlmBase/CMakeLists.txt:5 (cmake_policy):
  Policy "CMP0076" is not known to this version of CMake.

cmake_minimum_required(VERSION 3.12) but this policy is only introduced in 3.13. Unfortunately 3.12 is the best I get on a stock Ubuntu 18.10.

If I comment out the policy line, it configures and compiles just fine.

@axxel
Copy link
Contributor Author

axxel commented Jul 18, 2019

Maybe this would be a viable option without outright requiring 3.13:

if(POLICY CMP0076)
  cmake_policy(SET CMP0076 NEW)
endif()

@axxel
Copy link
Contributor Author

axxel commented Jul 19, 2019

As an afterthought: maybe supporting the stock cmake of the most recent Ubuntu LTS (18.04) which would be 3.10, would be worth the hassle. No idea what features would be missing compared to 3.12, though.

@meshula
Copy link
Contributor

meshula commented Jul 19, 2019

This policy converts relative paths to absolute in target_sources - @kdt3rd, I'm curious where this comes up? https://cmake.org/cmake/help/git-stage/policy/CMP0076.html

@kdt3rd
Copy link
Contributor

kdt3rd commented Jul 19, 2019

oh, I wanted to use cmake 3.12 because of the improved FindPython logic to handle both python 2 and 3 at the same time. Additionally, I use object libraries such that when you have the make both shared and static libraries turned on, it doesn't have to re-compile everything twice. In 3.12, these object libraries can be used in the target link calls, and it injects the .o into the resulting library, and carries the compile flags, etc. along with it, so I don't have to replicate that.

Both pretty nice features, and while I could do the object libraries a different way, as we head to VFX Platform 2020, with it's python 3 requirement, I don't want to make that any more complex than it is already with the boost python stuff, I'd rather spend the time switching to pybind11 :)

Back to the policy, I was originally using target_sources, as that is recommended in a bunch of the 'More Modern CMake' stuff, however, when I added the macros I've added to centralize the library creation, the need for them has largely gone away, so I believe we can just remove that policy entirely.

I need to touch all the cmake files today, will remove that policy set.

@axxel
Copy link
Contributor Author

axxel commented Jul 19, 2019

So there seems to be plenty of good reason to require 3.12. I'm personally all in on making progress and getting rid of cruft. Thanks for the background info.

kdt3rd added a commit to kdt3rd/openexr that referenced this issue Jul 20, 2019
kdt3rd added a commit to kdt3rd/openexr that referenced this issue Jul 20, 2019
…of cmake, no longer needed

Signed-off-by: Kimball Thurston <kdt3rd@gmail.com>
@kdt3rd kdt3rd closed this as completed in e69dc21 Jul 20, 2019
DominicJacksonBFX pushed a commit to boris-fx/mocha-openexr that referenced this issue Jun 22, 2022
…of cmake, no longer needed

Signed-off-by: Kimball Thurston <kdt3rd@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants