CMake improvements #38
Conversation
|
Thanks for your pull request. It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please visit https://cla.developers.google.com/ to sign. Once you've signed, please reply here (e.g.
|
|
I signed it! |
|
CLAs look good, thanks! |
CMakeLists.txt
Outdated
There was a problem hiding this comment.
Why? This is something other packages may have already started relying on, and I really see no advantage of making it uppercase (and therefore inconsistent with -lsnappy).
Even worse, if you change this, then packages that already target_link_libraries(snappy) will silently switch from linking the target to implicit -lsnappy.
There was a problem hiding this comment.
Optiligence@fb66b50#diff-af3b638bc2a3e6c650974192a53c7291L96
The output name stays the same.
CMake target names are usually upper cased.
This will be more robustly supported upstream when google#38 is merged.
|
@pwnall we just had a user report the lack of a static library: Homebrew/homebrew-core#15722 |
change CMake code to contemporary use of lower case and consistency with SnappyConfig.cmake.in
also provide the same INSTALL_DESTINATION to configure_package_config_file
but explicitly specify the output name to be lower case.
the exported targets were already generated but unused CMake exported targets exist for a very long time now and essentially replace a large amount of manual variables (include dir, library dir …) the version also wasn’t set, because corresponding variables got lost between PRs and c813168 a downstream project only needs to use the following – if the install prefix of snappy is in its search path – to add include directories and link the library find_package(Snappy) target_link_libraries(DownstreamTarget PUBLIC Snappy::Snappy) # yes, this also adds includes
…p of each other set BUILD_SHARED_LIBS=FALSE to build the static version shared is the default (as is BUILD_SHARED_LIBS=TRUE)
|
rebased again |
| ${Snappy_BINARY_DIR}/snappy-stubs-public.h | ||
| DESTINATION include) | ||
|
|
||
| if (BUILD_SHARED_LIBS) |
There was a problem hiding this comment.
Wouldn't it be nicer to have both BUILD_SHARED_LIBS and BUILD_STATIC_LIBS, so you can build both a static and a shared library without reconfiguring in between?
There was a problem hiding this comment.
There is no BUILD_STATIC_LIBS, BUILD_SHARED_LIBS is a CMake variable.
You would have to add 2 libraries and create targets with different names for each
combined with custom logic which enables or disables it.
downstream projects can’t use both at the same time anyway
The way it is now downstream gets shared snappy by default and would get static snappy when BUILD_SHARED_LIBS is set (which i consider the build-all-my-stuff-statically-please flag) which has the benefit that downstream doesn’t have to explicitly state anything in their CMake file, it’s only a build option.
One could also add explicit aliases on top of that (in the future?).
Reconfiguring in between has no downside anyway, it’s just a stylistic issue.
I’m quite happy with the way it is now, I also don’t know of any CMake projects which handle building static and shared flavors nicely to compare it with.
There was a problem hiding this comment.
I think most CMake projects end up adding a _static suffix to the library name. Honestly this is actually pretty nice as one can clearly specify they want static linking on Unix by simply using this other library name.
|
Generic advice: If you want your PR to be helpful, please don't bundle a coding style change with an actual change. In general, style choices tend to be intentional, and are (rightfully) optimized for the project maintainers, as they'll have to stare at the code for extended periods of time. In this case, I agree with the style change, as it matches the style in the CMake documentation, but the bundling still makes the diff useless. Edit: I plan to look into the shared library issue today. The style change requires other people to agree, so no timeline there. |
|
When I initially brought this up here I maintained 2 versions, one with the capitalization changed and one without. Thanks for looking into it. |
|
@Optiligence The project's CMake configuration has been revamped. Sorry to ask for more work from you, but can you please check which parts of this PR still apply and rebase? Also, if individual commits are easier to reason about, that's a pretty good sign that the commits should be in separate PRs. |
|
@mgorny Please try to be nice. |
|
I will work on it when i find the time. |
|
@pwnall You want ALLCAPS now or no? |
|
@Optiligence no more CAPS 😄 I hope that'll make diff management easier for you. |
|
@Optiligence Also, please make sure to rebase against master, not the latest release. |
|
Oh, nice, I didn’t have a look at the latest commit yet. |
|
Those 3 commits seem to be implemented: 66bd851 e23726b 26adadf On another note: |
So i tried to get my CMake wishes into the previous PRs, some of it landed, this is the rest.
Since the changed CMake config is pretty important for downstream use, i hope this can be included before the initial CMake release.
ad81778 is my take on one of CMake’s weak points, autotools allowed to do this before.