Re: [boost] Request for a "Policy Review" regarding 'CMakeLists.txt'

Subject: Re: [boost] Request for a "Policy Review" regarding 'CMakeLists.txt'
From: Louis Dionne (ldionne.2_at_[hidden])
Date: 2016-05-16 16:09:41

Mikhail Strelnikov <mikhail.strelnikov <at> gmail.com> writes:

> 
> >
> >
> >     * 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