As a complete neutral here, I think that Michal is very much on-point.
I've been a C++ programmer for 20+ years, and have used boost on-and-off
for much of that time.
For much of my professional career I have been working with build systems
and configuration management, and I know much more about C++ build systems
than a person who wishes to remain sane should know :-)
I've used make, autotools, MSBuild, CMake, jam, scons, Premake, and more.
CMake has "won". It isn't perfect, but it's the utterly dominant defacto
standard. Unless there is an amazingly compelling reason not to migrate,
putting together a CMake migration plan makes good sense.
And the same kind of thinking should be applied to issue tracking, version
control, automation, etc, IMHO.
It is only through my involvement with Ethereum that I am now more closely
looking at Boost as a DEVELOPER rather than as a USER, and it looks awfully
old-fashioned and stick-in-mud to me, I have to say, sadly.
Anyway - enough from me ... best wishes to you all. You have a gem with
your codebase. Please don't let it wither on the vine ...
On Mon, May 16, 2016 at 9:32 AM, Michał Dominiak
Hi,
The thing is, despite whether you believe bjam is better than CMake or not (please tell me how I can easily build Boost.MPI with Bjam without an additional config file that allows me to *just* do that?), there's another very important aspect of the problem, and it's whether Boost will survive in the current C++ world, where everyone uses CMake. People writing code to build independent parts of Boost for static linking in their libraries or tools that are supposed to be portable, regardless of the target or build OS, are already building it with CMake... probably because everything else in the world is built with CMake (or with autofo-- autotools, but that's easy enough to wrap with ExternalProject - for the record, I'm not saying that it's good). An example from the top of my head: YCM.
This isn't really a discussion that needs to go deeply technical, but if you want to do that, by all means, please do point out what bjam does better than CMake - as in, please make a list of stuff that is so great in bjam, so that we can actually discuss this technically (just mentioning usage-requirements doesn't do this for me, because if I understand the docs correctly, it's trivial to do this in CMake). For the record: I work with CMake on a daily basis at work, and I feel deep hatred for some of its idiosyncrasies, but I like it far better than working with bjam (and trust me, I've build my fair share of different Boost configurations over the past few years).
Now; we could make a poll to see whether the distribution of people for CMake among all Boost members is the same as it was at the panel at C++Now (where the vast majority of people raised their hands after the SC asked who wants Boost to be converted to CMake - or thinks it *needs* to be converted), but I don't know if going there is productive; what Dave and David said about the future and the deep need to actually make a move there and not get eaten by everybody who does that is probably the primary argument for actually doing the switch here.
I realize I am kinda derailing this thread, and there's a chance this should be made into a separate one; that might actually be a good idea. Just let me say one more thing.
I spoke with a few (as in: not so many of them; I wish I thought about this earlier than Saturday) at C++Now, including Dave, and asked them whether they think that the glue between different Boost libraries, that is: the build system used for the entire thing - should be considered a part of each individual library, or as something that is outside of the scope for each individual library, and rather a part of Boost itself, which would 1) make the authors of each library not actually own their build systems, just the code (which I believe is a good thing) and 2) make the Steering Committee the de facto owner of the build system *across Boost*, which, in turn, would allow them to make a decision saying "we are going to switch to CMake over the next X years/releases/whatever, and here's how we are doing it".
I believe that (2) should be done; if we just *encourage* library authors to also support CMake in their libraries, it will result with a lot of build systems that are separate entities, when I believe that they should be standardized across Boost - and this is the part when I don't believe that without the SC's definitive and authoritative voice saying "this is how it's done", it won't be done in a way that could potentially be made official, because of the differences different people have about build systems.
In the end, this is about moving forward, instead of staying in the same place forever, because as in many different industries, in this one not moving actually means moving backwards, and moving backwards is the kind of a thing that can murder Boost.
I expect people to raise opinions of "this is too radical" and "why should we listen to somebody posting on these mailing lists for the first time with a message like this one?"; that is fine. But the primary goal I have here is to remind you again (or tell you, if you weren't there) what Dave said on Saturday: the Steering Committee's role is to protect Boost. I believe that not moving forwards with an actual, active (as opposed to passive "yeah, you can do this; whatever") switch to CMake (*even despite any actual technical argument proving Bjam's superiority!*) is actively harmful in the era where almost all relevant (this includes proprietary!), big C++ projects that are not GNU are using CMake to build themselves.
A final note, again kind of repeating what Dave said (because I think it's extremely important and we tend to forget it these days): Boost is supposed to serve *the entire C++ community; it isn't Boost's goal to serve Boost's community*.
Thanks in advance for no open hostility in replies to this, hopefully we can make some progress thanks to Saturday's discussion that basically sparked this email.
On Mon, May 16, 2016 at 5:48 PM Mikhail Strelnikov < mikhail.strelnikov@gmail.com> wrote:
* 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?
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?
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.
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?
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.
What BOOST_HANA_HAS_WEXTRA does?
What is boost/libs/hana/LICENSE.md doing? Is this legal?
* Several companies have revealed that they are building Boost with
their own custom CMake scripts. The suggested policy change would enable authors to relieve the infrastructure cost of their CMake users and unify how their library is built.
I have opposite experience by replacing dozens of CMake scripts with one tiny Jamfile.
* CMake is, by far, the most popular build system for C++. Allowing authors to support CMake users in addition to BJam will help the Boost ecosystem to grow and thrive by lowering the barriers to access.
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.
I don't care too much about popularity, but Bjam/BB does support C++ much better than CMake. It has, for example, "usage-requirements".
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- bob@summerwill.net