Mikhail Strelnikov
* Several libraries, such as Boost.Hana and Boost.Spirit, have two distribution mechanisms: one as distributed with Boost and the other as an independent package.
What if header-only library A is using Hana from Boost 1.61 and header-only library B is using independent Hana released in 2017? Will this violate ODR (if compile at all) if both A and B are used in the same application?
Don't do that, just as you probably shouldn't use any library alongside a copy of itself at a different version. Also, FWIW, I'll use an inline namespace including the version of the library so that code using a different version won't link. I thought this was already the case, but it appears that Hana 1.0.0 ships without an inline namespace, which is an oversight.
The requirement that these libraries not include a 'CMakeLists.txt' as part of their Boost distribution creates a maintenance burden for authors or otherwise hurts usability of the independent distribution.
Hana does already include CMakeLists.txt in 1.61, why is that?
Because we had not had the discussion we're having right now at the time of freezing Hana for the 1.61.0 release, and the presence of the CMakeLists.txt file effectively does not hinder the release process, so it just stayed there.
Why header-only library such as Hana needs a build script that is 5 pages long (plus walls of text in cmake directory)? Bjam does support header-only libraries and does not require much from library author.
Technically, it doesn't need all of that. But Hana has - unit tests that are only enabled on some compilers - optional unit tests when built with the rest of Boost - header inclusion tests for every single header - support for running the tests under Valgrind - a complete suite of compile-time benchmarks and many more things that do require more than the minimal CMake setup for header-only libraries. But even that being said, the potential verbosity of CMake is completely beside the point, and the quality of Hana's CMake setup (which you imply to be poor) is even more so.
If you have 1.61 extracted, navigate to boost/libs/hana/CMakeLists.txt line 105 and please tell me why library included in Boost 1.61 is trying to search for Boost 1.59? Do you want every Boost library to search their own version of Boost?
No, not at all. Hana searches for Boost 1.59 _or above_, because it supports these versions. Obviously, the CMakeLists.txt file included with Hana is not the CMakeLists.txt file that would be included with Hana if the Boost community decided to make a move to CMake, which is not the case right now. In the current context, Hana has to search for all its dependencies manually.
It requires CMake 3.0 released in 2014 and searches for Boost 1.59 released in 2015 - this is not going to work. Best FindBoost.cmake has to offer is 1.56.
Well, that's a bug. It hadn't come up because we download the latest CMake in the CI anyway, but I'll fix it [1]. Thanks for the heads up.
What BOOST_HANA_HAS_WEXTRA does?
It determines whether the compiler supports the -Wextra flag. If supported, this flag is then added when building the tests and examples.
What is boost/libs/hana/LICENSE.md doing? Is this legal?
It documents Hana's license, which is the usual Boost license. I don't see why that wouldn't be legal, since it's the same license as the rest of Boost. It's not like I'm sneaking GPL code into the Boost tree without telling anyone.
[...] I have opposite experience by replacing dozens of CMake scripts with one tiny Jamfile.
This is beside the point.
[...] IMHO, CMakeLists.txt looks ugly as everything in camel starting with C. There are lots of Boost libraries having only "index.html" in their top-level directory, look, there is a pattern here and I'm not sure this should be uglified.
This is beside the point.
I don't care too much about popularity, but Bjam/BB does support C++ much better than CMake. It has, for example, "usage-requirements".
This is beside the point. If you have any other comments that are specific to Hana's CMake setup, please feel free to raise them by opening issues on Hana's GitHub page [2], which is the proper place for most comments you've made here. I'm glad to receive constructive feedback, as long as it's done in the right place. Regards, Louis Dionne [1]: https://github.com/boostorg/hana/issues/272 [2]: https://github.com/boostorg/hana/issues