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

CMake 3.11 will stop supporting multiline cache strings #2664

Closed
osrf-migration opened this issue Oct 10, 2019 · 2 comments
Closed

CMake 3.11 will stop supporting multiline cache strings #2664

osrf-migration opened this issue Oct 10, 2019 · 2 comments
Labels
all bug Something isn't working build minor

Comments

@osrf-migration
Copy link

Original report (archived issue) by Martin Pecka (Bitbucket: peci1).


Gazebo uses multiline CMake cache strings in files like https://github.com/osrf/gazebo/blob/45fb70f6a44696739ba853823980fe0a006056a2/gazebo/common/CMakeLists.txt#L219 .

CMake 3.11 will stop supporting this: https://cmake.org/cmake/help/v3.15/release/3.11.html#other-changes .

Practically, it doesn’t seem to be a big problem, because if I understand it correctly, this cache string is actually never loaded from the cache as its only usage is being directly handed off to configure_file. I verified it and the generated file config.hh looks correct and contains many include lines.

This is what CMakeCache.txt looks like when built with CMake 3.15:

//Common Headers
common_headers:INTERNAL= #include "gazebo/common/Animation.hh"
# WARNING: Value of common_headers contained a newline and was
#  truncated. Original value:
#  #include "gazebo/common/Animation.hh"
# \n #include "gazebo/common/Assert.hh"
# \n #include "gazebo/common/AudioDecoder.hh"
# \n #include "gazebo/common/Battery.hh"
# \n #include "gazebo/common/Base64.hh"
# \n #include "gazebo/common/BVHLoader.hh"
...

And these warnings are written to the console:

CMake Warning:                                                                                      
  Value of common_headers contained a newline; truncating   

So, the question is: is it still needed to save these variables to cache?

@osrf-migration
Copy link
Author

Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).


good call, these shouldn't need to be in the cache

see pr #3138

@osrf-migration
Copy link
Author

Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).


  • changed state from "new" to "resolved"

pr #3138

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
all bug Something isn't working build minor
Projects
None yet
Development

No branches or pull requests

1 participant