Differential D61956
[CMake] Add first CMake cache files Authored by sgraenitz on May 15 2019, 11:03 AM.
Details
CMake cache scripts pre-populate the CMakeCache in a build directory with commonly used settings. cmake -G Ninja -C /path/to/llvm-project/lldb/cmake/caches/Apple-lldb-osx.cmake -DLLVM_ENABLE_PROJECTS="clang;libcxx;libcxxabi;lldb" ../llvm-project/llvm Options specified on the command line will override options in the cache files (as long as caches don't use FORCE).
Diff Detail
Event Timeline
Comment Actions I wouldn't want to over-proliferate these, but in general I think this is a good idea. What I would find particularly useful is if we checked in the configurations used by all the bots in here, as that would make it easier to figure out what's going on if one of them breaks and the reason is not obvious...
Comment Actions Rename macOS specific cache file. Comment Actions Thanks for your input. Agreed, caches for most common configurations only. Also we may not over-proliferate includes across caches.
Interesting idea. This would go in the direction of CI systems with checked-in build/test configurations (like .travis.yml or .gitlab-ci.yml)? In my experience this works great with docker containers, because they provide a stable environment, but I remember well that debugging Travis CI builds was a big time sink before containerization. Hence, I wonder whether it comes with drawbacks in our case. We don't use containers exclusively. We do have local differences between machines and bot configurations smooth them out explicitly. I am not fond of putting thing like this in a cache file: -DPYTHON_EXECUTABLE=/usr/bin/python2.7 -DPYTHON_LIBRARY=/System/Library/Frameworks/Python.framework/Versions/2.7/lib/libpython2.7.dylib Furthermore, fixing bot configurations can be painful and often enough experimental changes are committed (e.g. https://github.com/llvm/llvm-zorg/commits/master/zorg/jenkins/jobs/jobs/lldb-cmake-standalone). Not sure if we want this in the LLDB history? I guess there's a reason why zorg is not part of the monorepo? :-) Also, I think fixing bot configurations typically goes hand in hand with changes on build bot scripts (which we don't have in the repo either) more than with changes on the codebase itself. I don't see it getting easier by moving the configurations to the codebase.. With all this considered, I wouldn't prefer to check in concrete caches for build bots in lldb. We could have them in zorg right? Might that be a way forward? We may brainstorm a list of candidates or just handle them as they come up.
Comment Actions Yeah, that's more or less what I had in mind. I didn't mean to include paths to various things, which are only valid on the single machine that the bot is running on, but more like if a bot is using some specific combo of LLVM_ENABLE_ASSERTS/LLVM_ENABLE_MODULES/LLVM_LINK_LLVM_DYLIB/... settings then these things might be helpful in figuring out why something is only failing there. Though I suppose these things are accessible through the buildbot UIs already, so it's already accessible in other ways. I think it still might be useful to have these configs accessible in a the repo for to make it easier to use them, but it's not a big deal either. The other llvm projects don't do that afaik, so it may be better to follow that example.. Having the buildbot config changes in the history is also an interesting question. On one hand, they do clutter the history, but on the other, they make it more obvious that something has changed -- if a bot mysteriously starts failing after one of my changes, i'd like to know that this could be due to a configuration change that happened at the same time -- this assumes that the configuration changes take effect instantly, and not after a bot reboot as is the case with buildbot (I'm not sure how greendragon stands on this front).
Comment Actions I noticed you have lots of comments that say "Release has different values for these variables". I think that you could instead guard the Release configuration behind a check. For example: if (CMAKE_BUILD_TYPE MATCHES Release) # Do the release configuration stuff here else() # Do the development configuration stuff here endif()
Comment Actions Yes, I was arguing: In a previous sketch I had extra variants for development and release builds. I preferred to keep only one variant for now and make notes for release builds instead, because actual release configurations are likely more complex anyway.
This would require setting CMAKE_BUILD_TYPE before loading the cache and it's not obvious when looking at the cache file. Thanks for all the input and discussions. I think this is something we have to iterate on. The current state looks like a good starting point to me. If there are no major concerns, I would land this some time soon.
Comment Actions Btw, options on the command line always override what's in the cache. Has nothing to do with FORCE. All FORCE does is make sure the set command actually changes an existing cache value. So it's an ordering issue. If the -D comes before the -C then using FORCE would override, but if the -C comes before the -D, the -D always overrides. I always use FORCE and put my overrides after the cache file. Comment Actions BTW, given that we recommend using ninja pretty much everywhere, you might want to include set(CMAKE_GENERATOR Ninja) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||