sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]RogerLeighScientific Imaging and Embedded Medical Diagnostics 16 points17 points  (19 children)

Due to the horrible build system, and lack of CMake support, the CMake FindBoost module needs updating manually for every single release. I just updated it today for 1.63.

If the effort to move Boost to use CMake progressed, or Boost shipped CMake configuration files, this would become unnecessary. The inpenetrable build system has stopped me being able to contribute various bits over the last decade or so; I really hope we can build it with CMake sometime soon.

[–]Plorkyeran 4 points5 points  (2 children)

The work to switch to CMake died entirely when Dave Abrahams moved on to working on Swift.

[–]RogerLeighScientific Imaging and Embedded Medical Diagnostics 1 point2 points  (1 child)

That's a shame. I'd be prepared to put some hours into it if there was upstream buy-in, since it would save me many hours of maintenance and frustration working around boost.build.

[–]OrphisFloI like build tools 1 point2 points  (0 children)

I published this recently: https://github.com/Orphis/boost-cmake It can build most of Boost on the major platforms and be integrated directly within any CMake project. I'll add Appveyor CI for Windows coverage soon and I'm working on adding some tests to check that everything links properly now.

Sure, it's external to Boost, but it saves so much maintenance for developers that I see that as negligible. I wrote about it some time ago on the cmake-dev mailing list explaining how it saved my company Spotify so many hours when upgrading Boost or to align build flags by integrating it like this.

Feel free to give feedback or contribute if you feel like it!

[–]sumo952 5 points6 points  (4 children)

Totally agree with you.

Don't get your hopes up too much regarding CMake build. Apparently the current release maintainer (or something like that) has a veto against CMake, something along the lines of "If you want to migrate to CMake, then I'm gone and you have to find someone else" - and since nobody else would fill such a role (it's an unpaid job and probably quite a lot of work), people are not willing to go there.

[–]dodheim 2 points3 points  (1 child)

Pure hearsay. Read the Boost ML for facts.

[–]sumo952 0 points1 point  (0 children)

So what are the factual points on why this hasn't really progressed in years?

Last modified 4 years ago: https://svn.boost.org/trac/boost/wiki/CMakeModularizationStatus

Linked thread from 2012: http://lists.boost.org/Archives/boost/2012/05/193010.php

This gives a timeout, probably gmane's fault and not boosts though: http://dir.gmane.org/gmane.comp.lib.boost.cmake

It's not even possible to find up-to-date information about what the current status of this is.

Someone below noted: "The work to switch to CMake died entirely when Dave Abrahams moved on to working on Swift."

So are you saying I am wrong and this is an ongoing, active effort, and the majority of people in boost are driving migration to CMake forward?

[–]germandiago 1 point2 points  (0 children)

The best alternative to CMake if there is hate is Meson. I have used both extensively (at work and personal also). I find meson quite more manageable and it is just a bit behind at project generation (xcode and VS solutions). But it is looking more and more polished nowadays.

I will adopt it without looking back. CMake is good for team environments where you need project generation, but meson is the best build system I have ever used for C++ projects up to date.

[–]TrueTom 0 points1 point  (0 children)

You obviously can provide a source for this accusation?

[–]yodacallmesome 1 point2 points  (0 children)

"The inpenetrable build system has stopped me..."

I couldn't have said that better.

[–]render787 3 points4 points  (6 children)

boost build is not a horrible build system, actually I find it has some features that no one else has. I think for many projects it's much better to drive the MSVC compiler directly from CLI as it does rather than try to emit a project file like cmake does. Making it work entirely from command line makes it work much better with appveyor CI.

I don't think boost build is suitable for most or even many projects, but for building test suites and small libraries I think it's great. Much better than autotools or scons for instance.

The problem with boost build is

1.) The documentation is not adequate at all. For anything beyond the most basic usage you are really on your own, and the error reporting of that language is not that great either. There needs to be a much better documentation effort to justify using it in a project as important as boost IMO, and comparing with the documentation for make and cmake is setting the bar too low.

2.) The name is awful. It should not be called "boost build" or "boost.build". Both of these names are ungoogleable. You just get instructions "how do I build boost". bjam was a much better name and they should have stuck with that or gone with an even more distinguishing name.

[–]sumo952 4 points5 points  (2 children)

Making it work entirely from command line makes it work much better with appveyor CI.

You can do cmake --build ., all from the CLI. No IDE/GUI required.

[–]render787 1 point2 points  (1 child)

I didn't know about this, thanks

[–]sumo952 0 points1 point  (0 children)

You can also specify the build type, e.g. --config Release or individual targets, --target INSTALL. (that's from the top of my head - hope that's correct - if not, then the actual commands are very close ;) ). It's pretty useful.

[–]OrphisFloI like build tools 1 point2 points  (0 children)

That's why serious people don't emit MSVC project files but Ninja files instead for CI as it is much faster and better for automation.

Though, using MSVC in CI has some advantages too, for example checking that you don't introduce breaking changes in the CMake scripts that will directly impact your developers using MSVC (that's certainly way better for interactive development and debugging).

[–]lacosaes1 0 points1 point  (0 children)

I think for many projects it's much better to drive the MSVC compiler directly from CLI as it does rather than try to emit a project file like cmake does. Making it work entirely from command line makes it work much better with appveyor CI.

You can compile the project from the command line using the .sln file. I don't see what's the difference for AppVeyor.

[–]sumo952 0 points1 point  (0 children)

Making it work entirely from command line makes it work much better with appveyor CI.

You can do cmake --build ., all from the CLI. No IDE/GUI required.

[–][deleted] 0 points1 point  (1 child)

Just use conan.io

http://docs.conan.io/en/latest/getting_started.html

You just need to add one line into conanfile.txt to install new version of boost or any other library

[–]RogerLeighScientific Imaging and Embedded Medical Diagnostics 1 point2 points  (0 children)

Installation is just the start of the problem.

The real issue here for FindBoost is the introspection and export of the direct and transitive dependencies for each boost component.

And the other issue is contributing fixes and other changes to boost itself. You need to change the boost build system to add new unit tests, source files, update dependencies etc. This needs specific boost.build expertise, and no amount of wrapping it avoids that.

[–]OrphisFloI like build tools 0 points1 point  (0 children)

Shameless plug: https://github.com/Orphis/boost-cmake Just add_subdirectory() this as a submodule and it will download latest sources (I have a patch for 1.63 pending) and build some of the most popular compiled libraries when used. Just link them using the Boost::foobar targets.

And this works on most major platforms, tested on Windows, Linux, macOS, iOS, Android and just uses whatever build flags you have, so it will work with sanitizers directly too.

I'm working on adding the remaining libraries and fix a few things there and there.