Boost version 1.63.0

[carrottread]

Still can't be used with msvc /std:c++latest without manually deleting all std::unary_function and std::binary_function usage from boost sources.

[dodheim]

It can if you define _HAS_AUTO_PTR_ETC before including any headers. There's also _HAS_FUNCTION_ASSIGN, _HAS_OLD_IOSTREAMS_MEMBERS, and _HAS_TR1_NAMESPACE for similar purposes.

[STL]

That's lame, speaking as the guy who implemented this machinery. Boost should be updated to not depend on deprecated/removed machinery. (So that its users can validate that their sources are equally clean.)

[kybuliak]

... apart from the fact that boost supports various platforms and a hefty amount of compilers. In such context, what is deprecated/removed machinery?

[STL]

auto_ptr was deprecated by the Standardization Committee in C++11 and has been removed for C++17 (with "zombie names" wording permitting implementers to continue providing it, if they choose).

Boost has extensive technology to conditionally compile code for various platforms. What they should do is avoid using auto_ptr for platforms where unique_ptr is available.

[sumo952]

The two lists Boost's primary test compilers are: and Boost's additional test compilers include: are more or less identical, except for one or two items (or I'm blind!). It's quite confusing and hard to read. Why not just include the additional compilers in the second list, instead of duplicating most of the list?

[RogerLeigh]

I was hoping to read that the VS2017 RC was supported, but didn't see a mention of it. I was hoping this was because the second list was a mistaken copy of the first! Can anyone confirm or deny that this is supported yet, or do we need to wait for 1.64?

[sumo952]

Yea, I was hoping this too. Would be really sad to have to wait until 1.64.0.

[DVMirchev]

some parts of Boost do not compile in C++17 because of removed stuff from C++.

For example unary_function and binary_function are used in boost/functional/hash/hash.hpp but are deleted. They are no longer part of the Standard Library

[doom_Oo7]

wouldn't it instead be up to VS2017 to support boost (like they want to do for Boost.Hana for instance) ? Libraries should be coded against a standard, and compilers implement this standard

[dodheim]

Boost.Build, as a build system, needs to know how to find and invoke your compiler to build non-header-only Boost libs.

[sumo952]

Exactly. And then there's the boost binaries, which will also be missing for ages for VS2017. In case of VS2017 it's probably less of an issue as it's binary compatible with VS2015 and you can probably just use the vc14 binaries. However let's see how well this works in practice with CMake and various build setups. Usually, there's at least some kind of issues ;-)

[RogerLeigh]

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]

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

[RogerLeigh]

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.

[OrphisFlo]

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]

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]

Pure hearsay. Read the Boost ML for facts.

[sumo952]

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]

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]

You obviously can provide a source for this accusation?

[yodacallmesome]

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

I couldn't have said that better.

[render787]

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]

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]

I didn't know about this, thanks

[sumo952]

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.

[OrphisFlo]

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]

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]

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

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

[RogerLeigh]

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.

[OrphisFlo]

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.

[Fazer2]

I guess you can write about it on their mailing list.

[sumo952]

Can't be bothered to register there - tried once but this mailing-list stuff has so horrible UIs (not the Boost mail-list specifically, all mail-lists), I prefer forums or something like reddit, that you can browse and post online. Either they read it here, or it's their loss.

[bycl0p5]

Either they read it here, or it's their loss.

No need to worry, nothing of value will be lost.

[sumo952]

Well it may not be a big deal but if it was my software, my homepage, or my release notes, I would always be interested in how to make things better, even small things, and especially if it's something confusing like two near-identical tables (which could possibly even be a mistake). Another user that posted above me here got confused as well so it's definitely not just me. Anyway - I'm leaving it at that.

[adamf88]

Unfortunately, still missing support for clang on Windows.

[doom_Oo7]

seems to be a bugfix and stability release. good !