On 8/29/18 08:12, Edward Diener via Boost wrote:

On 8/29/2018 10:53 AM, Robert Ramey via Boost wrote:

...

The fact is that users of boost use compilers with differing levels of C++ standard conformance.  This creates a number of problems including (but probably not limited to)

<snip>

...

This would make everyone's life easier.

Forcing end-users to build Boost themselves is not user friendly.

The users of Boost are developers. They should be building Boost for their target needs. -- Michael Caisse Ciere Consulting ciere.com

On 8/29/18 9:14 AM, Cem Bassoy via Boost wrote:

I like Edwards proposal. However, not all Boost users are C++ experts, especially those who want to use 'higher-level' boost libraries such as GIL. Comparing Boost's installation processes with Qt's one, many users do not want to be concerned with cloning/compiling/linking issues.

Any boost library should be straight forward to build if it's not header only. And - users should also be running the tests which come with a library that they are going to use as well. If we're distributing something that is problematic to build & test, we have a problem. Let's fix that! Robert Ramey

On 8/29/18 2:16 PM, Richard via Boost wrote:

In article <0499fe61-4113-95f1-c56c-d5778b0b0fa2@rrsd.com>, Robert Ramey via Boost writes:

...

On 8/29/18 9:14 AM, Cem Bassoy via Boost wrote:

...

I like Edwards proposal. However, not all Boost users are C++ experts, especially those who want to use 'higher-level' boost libraries such as GIL. Comparing Boost's installation processes with Qt's one, many users do not want to be concerned with cloning/compiling/linking issues.

Any boost library should be straight forward to build if it's not header only.

Agreed, but bjam/jam/whatever is an impediment here. Boost is the only thing I've ever encountered that used this. CMake is the most widely used build environment now for C/C++ and the sooner we move to replacing bjam/jam/whatever with CMake, the sooner all this build suffering ends.

...

If we're distributing something that is problematic to build & test, we have a problem. Let's fix that!

It's been that way for... what, a decade? I have only seen signs of hope more recently that the boost organizing committee decided to bless CMake as the direction to go.

Right - there is a consensus that Boost should support CMake. The BOD has passed some sort of resolution meant to make this happen. The only real requirement is that the proposed solution be available for review. But ... Nothing has happened. Turns out, it's a big job that requires a lot of effort which no one has been prepared to take this on. We need ideas, persons with initiative and insight, and who knows what else. Robert Ramey

On Wed, Aug 29, 2018 at 6:47 PM Peter Dimov via Boost wrote:

Richard wrote:

...

the sooner we move to replacing bjam/jam/whatever with CMake, the sooner all this build suffering ends.

Right. CMake can't even build for the static runtime. Plus it won't help at all with the problems we're discussing here.

CMake can be taught to link against the static MSVC runtime. It isn't built-in, but there is a well known and accepted solution to the issue. I'm not suggesting that it is an awesome solution but I have used it more than once and it is sufficient: https://stackoverflow.com/questions/14172856/cmake-compile-with-mt-instead-o... - Jim

James E. King III wrote:

CMake can be taught to link against the static MSVC runtime. It isn't built-in, but there is a well known and accepted solution to the issue. I'm not suggesting that it is an awesome solution but I have used it more than once and it is sufficient:

https://stackoverflow.com/questions/14172856/cmake-compile-with-mt-instead-o...

Didn't quite work for me. I needed to compile an existing library using CMake (which incorporated dependencies also using CMake), not write my own CMakeLists. It's a hack.

On 8/29/18 8:12 AM, Edward Diener via Boost wrote:

...

This would make everyone's life easier.

Forcing end-users to build Boost themselves is not user friendly.

Right. So let's fix THAT!

...

Robert Ramey

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On Wed, Aug 29, 2018 at 10:43 AM Mike Dev via Boost wrote:

Sorry, but I can resists: It would be so nice, if boost would just use cmake ;)

Sorry I can't resist either.. Just use conan, vcpkg, etc with your cmake project ;-) -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

On Wed, Aug 29, 2018 at 11:11 PM, Richard via Boost wrote:

Last time I tried to use conan, it was a fail on Windows.

https://github.com/conan-io/conan/issues/1341

It's supposed to be "easy out of the box" but it is nowhere near that point yet.

Try https://github.com/Microsoft/vcpkg -- Olaf

-----Original Message----- From: Boost On Behalf Of Jeffrey Graham via Boost Sent: Wednesday, August 29, 2018 11:52 PM

Or get completely off the circus and just go header-only

Boost already has a - well earned - rep for exploding your compile times. I'm not sure if going all header only is really the answer here. Although actual benchmarks would be interesting.

On 8/29/18 9:07 AM, Olaf van der Spek via Boost wrote:

On Wed, Aug 29, 2018 at 4:53 PM, Robert Ramey via Boost wrote:

...

The fact is that users of boost use compilers with differing levels of C++ standard conformance. This creates a number of problems including (but probably not limited to)

a) Using libraries built with different levels of C++ conformance may create ABI issues.

b) it creates a discussion about "dropping C++03 support". Actually it creates a discussion about that the above actually means.

c) It's motivated a suggestion that all libraries move to header only. This is not great idea - but I won't address that here.

I believe all these issues - and more - would disappear if we just stopped distributing binaries.

Why do you think so? It doesn't solve A, B or C.

a) since the user would be compiling everything with his own favorite compiler with the -std setting he desires, There would be no ABI issues. b) LOL - It's been stated numerous times that the the Boost policy is that a library must only be compatible with the currently release C++ standard. This makes the discussion of "dropping C++03" support non-sensical an pointless. But the question keeps arising. So I'll have to conceded you're right here. Nothing will likely resolve this issue. c) I'm presuming the suggestion of Header only libraries is at least in part due to the fact that it would address a) above. That is, any issues related to ABI would go away. That's why I think so. Robert Ramey

On 8/29/18 9:45 AM, Peter Dimov via Boost wrote:

Robert Ramey wrote:

...

a) since the user would be compiling everything with his own favorite compiler with the -std setting he desires, There would be no ABI issues.

Yes there are. Users compile with the default C++03 and then use it from C++14/C++17. This is not speculation, it actually happens.

Right they do do that. They shouldn't but they do. We can't control what users do. We can tell them what not to do. But they do it anyway. There are some problems Boost can't solve. Robert Ramey

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On 8/29/18 10:02 AM, Olaf van der Spek via Boost wrote:

On Wed, Aug 29, 2018 at 6:35 PM, Robert Ramey via Boost wrote:

...

a) since the user would be compiling everything with his own favorite compiler

Not if he's using package management (Linux, vcpkg @ Windows).

Hmmm - I don't really know what vcpkg actually does. Basically if we distribute only source and no binary then we're not responsible for all the stupid stuff that people do with it.

...

with the -std setting he desires,

Are you sure about that? Even if he has projects with different -std settings?

LOL - if he has projects with different -std settings - e.g. a dll and an application which calls the dll, he has problems that we can't solve. By not distributing binaries, we avoid burdening people who do know what they're doing with silent ABI inconsistencies which can cause almost impossible to find bugs.

...

There would be no ABI issues.

b) LOL - It's been stated numerous times that the the Boost policy is that a library must only be compatible with the currently release C++ standard.

Apparently that's not documented properly. Where is it documented anyway?

I don't know. I'm sure it's documented somewhere. There are several well known library which illustrate its veracity. And it's stated on this list about every 6 months or so. It's been stated several times in this thread. Regardless of where it's documented, or even if its not, it happens to be true.

And where's the list of supported compilers listed?

That would depend on the particular library. All boost library are supposed to work with the current standard (at least when approved). So any compiler which implements the current standard should be guaranteed to be able to build and use the library. Of course this is complicated by the fact that there is no C++ compiler and standard library which actually correctly implements the standard. This in turn is complicated by the fact that there is no universal agreement on what the standard actually means in many places. This in turn is complicated by the fact it is very popular to add features (initialization) that no one can really figure them out. Alas - I'm off topic.

Are you sure 'we' are not expecting libs to work with non-C++17 compilers?

Hmmm I don't know that I can speak for "we". But I expect that a Boost library will work with any compiler conforming the the standard existing at the time the library was approved. Since C++ strives to maintain backward compatibility, I expect that that library will be compatible with all subsequent C++ compilers. Of course this is not strictly true. Any boost library using std::auto had to be tweaked when auto was dropped. But in practice it's true enough for government work. Robert Ramey

On 8/29/18 1:50 PM, Nevin Liber via Boost wrote:

On Wed, Aug 29, 2018 at 3:38 PM Robert Ramey via Boost < boost@lists.boost.org> wrote:

...

Hmmm - I don't really know what vcpkg actually does. Basically if we distribute only source and no binary then we're not responsible for all the stupid stuff that people do with it.

We aren't responsible anyway.

By shipping binaries we're encouraging people to use them. This seems like we're helping them - but I maintain that we are not actually helping anyone with this policy. Not shipping binaries means we will be

making things harder for some users, especially newcomers to Boost.

maybe, maybe not. Now,

the outcome of this discussion may be that we will no longer ship binaries because we cannot do it correctly for most use cases, but let's not pretend not doing so is a benefit to the end user.

I think not shipping stuff that won't work benefits the user. I also thing that not shipping the binaries would save a lot of work on our part. If some third party wants to take this they are free to do so.

...

By not distributing binaries, we avoid burdening people who do know what they're doing with silent ABI inconsistencies which can cause almost impossible to find bugs.

I thought that the people "who do know what they're doing" are building the binaries themselves anyway, so I fail to see how we are burdening them.

Right - typo should be: avoid burdening people who DON'T know what they're doing Robert Ramey

On 8/29/18 3:43 PM, Peter Dimov via Boost wrote:

Nevin Liber wrote:

...

We aren't responsible anyway.  Not shipping binaries means we will be making things harder for some users, especially newcomers to Boost. Now, the outcome of this discussion may be that we will no longer ship binaries because we cannot do it correctly for most use cases, but let's not pretend not doing so is a benefit to the end user.

This is all irrelevant anyway because we don't ship binaries except on Windows where we don't have a problem with them.

Hmmm - we ship binaries I presume in the form of DLLS and *.lib files. Which -std version are these compiled with? What if that is different then the -std version that the user compiles his ap with? Doesn't that create a number of problems? Weren't you the one who pointed this out?

Linux binaries are shipped by the distros, not us.

Hmmm - same question as above? if the binaries are compiled with one -std version but the user links in via static or dynamic link with a different -std version won't that create problems? Robert Ramey

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On 8/29/2018 6:03 PM, Peter Dimov via Boost wrote:

Robert Ramey wrote:

...

...

This is all irrelevant anyway because we don't ship binaries except on > Windows where we don't have a problem with them.

Hmmm - we ship binaries I presume in the form of DLLS and *.lib files. Which -std version are these compiled with?

The compiler default. MSVC versions before 2015 didn't have -std at all, for 2015/2017 the default is C++14.

This is the command from a new Console project in VS 2017, 15.8.1: /JMC /permissive- /Yu"pch.h" /GS /W3 /Zc:wchar_t /ZI /Gm- /Od /sdl /Fd"x64\Debug\vc141.pdb" /Zc:inline /fp:precise /D "_DEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE" /errorReport:prompt /WX- /Zc:forScope /RTC1 /Gd /MDd /FC /Fa"x64\Debug\" /EHsc /nologo /Fo"x64\Debug\" /Fp"x64\Debug\DefaultConsPjBoostTest.pch" /diagnostics:classic Command from a new Static Library project in VS 2017, 15.8.1: /JMC /permissive- /Yu"stdafx.h" /GS /W3 /Zc:wchar_t /ZI /Gm- /Od /sdl /Fd"x64\Debug\StaticLibMSForPjBoost.pdb" /Zc:inline /fp:precise /D "_DEBUG" /D "_LIB" /D "_UNICODE" /D "UNICODE" /errorReport:prompt /WX- /Zc:forScope /RTC1 /Gd /MDd /FC /Fa"x64\Debug\" /EHsc /nologo /Fo"x64\Debug\" /Fp"x64\Debug\StaticLibMSForPjBoost.pch" /diagnostics:classic The "default" does not set the /std option. Where does the Visual Studio Team document the default C++ standard used within each Visual Studio revision? --Robert

...

Doesn't that create a number of problems?  Weren't you the one who pointed this out?

Most MSVC users don't change the default, and for those who use C++17, there aren't (yet) any problems because very few libraries (yet) change their ABI for C++17. The main dividing line is between 03 and 11, a secondary one exists between 11 and 14.

C++14 is a very good ABI default. >

...

...

Linux binaries are shipped by the distros, not us.

...

Hmmm - same question as above?  if the binaries are compiled with one -std version but the user links in via static or dynamic link with a different -std version won't that create problems?

It very well might, but we can do nothing about it. Most new distros ought to use the default C++14, which is the most compatible one.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On 8/30/2018 4:31 PM, Stephan T. Lavavej via Boost wrote:

[Robert]

...

Where does the Visual Studio Team document the default C++ standard used within each Visual Studio revision?

https://docs.microsoft.com/en-us/cpp/build/reference/std-specify-language-st...

STL

Thanks. However, I do not see where a new project has it on the command line to the compiler. Using the _MSVC_LANG macro, the number sent to cout says: 201402 Although this means C++14, how many of us believe it will correctly compile against the C++14 standard without the /std:c++14 option present? One anecdote with recent VS updates, if not set, the compiler has not always compiled as expected. Plus, soon the default will be C++17. Expect the VS 15.9.x release to have that value, assuming past language compliance modifications, indicate future unexpected compiler messages, warnings, errors, etc. --Robert

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On 8/31/2018 12:38 AM, degski via Boost wrote:

On Fri, 31 Aug 2018 at 00:49, Robert via Boost wrote:

...

Although this means C++14, how many of us believe it will correctly compile against the C++14 standard without the /std:c++14 option present?

Are you implying the std used, when not set, is randomized? That would indeed be entertaining. Oh, based on how things change between dot releases (e.g. 15.5, 15.6, 15.7, ...), it certainly feels like that... ;)

More importantly though, the VS 15.8.x standard headers use more C++17 features than 15.7.x. The way the VS team writes about upcoming 15.9.x, you can easily interpret the dot nine release will be the "crowning achievement." Please see my other response for details.

degski

On 8/31/2018 1:10 AM, Olaf van der Spek via Boost wrote:

On Thu, Aug 30, 2018 at 11:49 PM, Robert via Boost wrote:

...

compiled as expected. Plus, soon the default will be C++17. Expect the VS 15.9.x release to have that value, assuming past language compliance modifications, indicate future unexpected compiler messages, warnings, errors, etc.

Source? Daily professional use of the current release VS tool set.

Details: Microsoft anticipates the 15.9.x release(s) will resolve bugs complying with C++17. Plus, the standard headers will likely change again. Between 15.7.x and 15.8.x, the VS standard headers use more compile time if and other C++17 features. The header modifications are quickly found using the Intel 18.0, update 3, C++ compiler. The Intel C++ compiler team has been informed and issues filed. How exactly will the changing VS standard header files compile without C++17 being the 15.9.x default? Additional Reference: https://blogs.msdn.microsoft.com/vcblog/2018/05/07/announcing-msvc-conforms-... Remember, the VS preprocessor is expected to be fully compliant too: The updated preprocessor is currently under the switch /experimental:preprocessor until it is fully implemented and production-ready, at which point it will be moved to a /Zc: switch which is enabled by default under /permissive- mode. From: https://blogs.msdn.microsoft.com/vcblog/2018/07/06/msvc-preprocessor-progres... --Robert

[Robert]

How exactly will the changing VS standard header files compile without C++17 being the 15.9.x default?

VS 2017 15.9 will *not* change the Standard mode default to C++17. It will remain at C++14 for that update. MSVC's STL supports being compiled in both C++14 and C++17 mode; we sense the Standard mode and adapt our code accordingly. We use "if constexpr" internally to improve throughput because MSVC and Clang support it in C++14 mode with a disable-able warning. (We have an escape hatch, which we reserve the right to remove at any time without notice.) Stephan T. Lavavej Principal Software Engineer, Visual C++ Libraries

On 30/08/2018 10:43, Peter Dimov wrote:

This is all irrelevant anyway because we don't ship binaries except on Windows where we don't have a problem with them.

Linux binaries are shipped by the distros, not us.

+1 Although I do think that the Getting Started advice, especially for Linux, should be more up-front about reminding users to ensure that the C++ std levels of Boost and the application match each other. And possibly should be included in the default library name as a reminder / ABI separator. (Or encourage distros to ship multiple builds with --buildid, or a simple way to create a composite build that will work correctly with any user-selected -std.)

On 8/29/18 4:32 PM, Richard via Boost wrote:

In article , Gavin Lambert via Boost writes:

...

On 30/08/2018 10:43, Peter Dimov wrote:

...

This is all irrelevant anyway because we don't ship binaries except on Windows where we don't have a problem with them.

Linux binaries are shipped by the distros, not us.

+1

...except where they don't.

Linux distros can significantly lag the boost releases, particularly for "enterprise" distributions.

another reason for skipping the whole process. Under my method, everyone gets the latest release - along with and easy way to update it on demand. Robert Ramey

On Thu, 30 Aug 2018 at 05:41, Tom Kent via Boost wrote:

TL;DR - We need to provide an easier way to get windows/visual studio users up and running with boost than building with b2. I love boost and want to make it as easy as possible for others to use.

Microsoft did that for you, vcpkg, 1 week after the release of Boost-1.68 it was made available (upgrading from 1.67).

vcpkg upgrade --no-dry-run

Two cups of coffee and some fakebook surfing later, done. I'm not saying or implying that there are or will be no teething problems, but it's much simpler to solve them there (in vcpkg) then to come up with yet another homebrew solution. A move by Boost to CMake is 100% in line with how ms/vcpkg sees its future, but the current situation (b2) doesn't seem to be an issue either. degski PS: just for fun, and to show how well vcpkg actually already works, there was a bug in the icu build (and some other minor thiings), so when I just now issued the above command (while writing this), 8 boost modules needed rebuilding, because of that/those, and so they were (it works, cannot say it any other way). -- *“If something cannot go on forever, it will stop" - Herbert Stein* *“No, it isn’t truth. Truth isn’t truth" - Rudolph W. L. Giuliani*

On Thu, Aug 30, 2018 at 4:40 AM, Tom Kent via Boost wrote:

TL;DR - We need to provide an easier way to get windows/visual studio users up and running with boost than building with b2. I love boost and want to make it as easy as possible for others to use.

vcpkg install boost?

it....that didn't go well. Eventually I found the horrible "Getting started with windows" page [1]. It tries to lead a user to the command `b2 --toolset=msvc-14.0 --build-type=complete stage`, but fails miserably to identify the arguments that are actually needed and most users would never figure out from the page that that is the command they need.

I agree the docs aren't ideal. Stage is the default, complete isn't (unfortunately) and b2 has become quite good at auto-detecting the toolset, assuming you've only got one. Was b2 that bad 10 years ago? :p

3) I'd like to (when I can find the time) start pushing the binaries for each release into some of the new package management systems (conan, vcpkg, etc). While keeping the existing ones available as well, as the windows package management systems are only used by a tiny minority.

vcpkg doesn't do binaries. ;)

I have great respect for where this request comes from. I wish every developer (especially the ten years ago me) could easily understand how to build their own copy of boost. However, I think we as a community need to spend a lot more time thinking about the end-users who want to use boost but aren't already familiar with it.

True -- Olaf

-----Original Message----- From: Boost On Behalf Of Richard via Boost Sent: Friday, August 31, 2018 12:35 AM

While vcpkg is a reasonable MS-specific system for VS-only users.

Not sure about that. I happen to use it on windows and linux with msvc, clang and g++. I don't use mingw or clang/llwm on windows though. Best Mike

-----Original Message----- From: Boost On Behalf Of Richard via Boost Sent: Friday, August 31, 2018 1:36 AM

In article <001301d44082$d88b4900$89a1db00$@gmx.de>, Mike Dev via Boost writes:

...

...

-----Original Message----- From: Boost On Behalf Of Richard via Boost Sent: Friday, August 31, 2018 12:35 AM

While vcpkg is a reasonable MS-specific system for VS-only users.

Not sure about that. I happen to use it on windows and linux with msvc, clang and g++. I don't use mingw or clang/llwm on windows though.

What? How are you using msvc on linux?

I'm using it with msvc on windows and clang and gcc on linux. Sorry for the confusion. Best Mike

On Thu, 30 Aug 2018 at 20:37, Rene Rivera via Boost wrote:

Top posting intentionally...

There are almost certainly better places to discuss the particulars of certain package managers than this email thread.

There probably are, but I would like to fight against misinformation (based on quick glances at a readme and such) being established as truth for the next 10 years. The only thing I am trying to convey is that vcpkg does not do binaries and it's not vc/windows only. What it is though is OSS and anyone can contribute and make things work on nix/osx as they please and that CMake is the preferred solution. There is a requirement that it works with vc/windows, though, which seems rather reasonable as people power is not free. degski

On Thu, 30 Aug 2018 at 19:35, Richard via Boost wrote:

While vcpkg is a reasonable MS-specific system for VS-only users.

Something I did not notice up till just now is that the (con-incidentally?) sub-title (the short description) of vcpkg https://github.com/Microsoft/vcpkg has been changed to "C++ Library Manager for Windows, Linux, and MacOS", it's official, vcpkg works (or intends) to work on win/nix/osx. @Rene Yes, I'll shut up now, job done. degski -- *“If something cannot go on forever, it will stop" - Herbert Stein* *“No, it isn’t truth. Truth isn’t truth" - Rudolph W. L. Giuliani*

On 8/29/2018 10:40 PM, Tom Kent via Boost wrote:

On Wed, Aug 29, 2018 at 9:53 AM Robert Ramey via Boost < boost@lists.boost.org> wrote:

...

The fact is that users of boost use compilers with differing levels of C++ standard conformance. This creates a number of problems including (but probably not limited to)

a) Using libraries built with different levels of C++ conformance may create ABI issues.

b) it creates a discussion about "dropping C++03 support". Actually it creates a discussion about that the above actually means.

c) It's motivated a suggestion that all libraries move to header only. This is not great idea - but I won't address that here.

I believe all these issues - and more - would disappear if we just stopped distributing binaries. Each user would be building his own boost version with (presumably) the same compiler. Since C++03 compatible libraries are C++?? compatible, each library author can maintain the level of backward compatibility that he wishes.

But if we're not going to distribute binaries, then users might as well just clone the latest "certified - good - tagged" version in the master branch from the github repo. That is, let's just stop or truncate the whole release circus. Replace with an occasional "certification/versioning procedure" which would make available a "squashed" master suitable for efficient cloning.

This would make everyone's life easier.

Robert Ramey

I've never heard of any binaries for linux/unix/mac distributed by us, so I guess this is reference to the Windows/Visual Studio binaries? As the person who builds them, I suppose I should weigh in on this.

TL;DR - We need to provide an easier way to get windows/visual studio users up and running with boost than building with b2. I love boost and want to make it as easy as possible for others to use.

History of the binaries ----------------------------- When I first got started with the boost project about a decade ago, I was a decent C++ developer at a large company (Boeing). We use C++ to develop simulators for our aircraft.

I had worked extensively with Visual Studio and our large code base. Our primary product (our simulation) is hundreds of thousands of lines of code and uses dozes of external dependencies. Most of the "external" dependencies were internally (other groups within the company) produced products. We would get dumps of .h and .lib files from other groups and add the directories to our visual studio solution include/lib paths. We would occasionally encounter ABI errors, but were very good at managing the configuration of libraries coming in to keep these from affecting us. We basically had a system similar to Conan...but fifteen years ago.

I got the task of adding Boost to one of our projects in our solution, so we could use a couple very nice libraies: asio, date time, interprocess, program options, thread, and test. Several of these are not header only, so I knew I needed static libs for them. I fought for weeks trying to get binaries. I wasn't familiar with bjam (and didn't know it was included with the source!) so I tried to load the source into visual studio and compile it....that didn't go well. Eventually I found the horrible "Getting started with windows" page [1]. It tries to lead a user to the command `b2 --toolset=msvc-14.0 --build-type=complete stage`, but fails miserably to identify the arguments that are actually needed and most users would never figure out from the page that that is the command they need.

After many *dozen* hours fighting with b2, digging through terrible b2 documentation, and googling for people who had successfully built boost on windows, I finally got my static libs out! It was a nightmare that still motivates the work that I do to make binaries available.

After getting them built, I packaged them up for use by my team. After doing this for a few releases, and seeing lots of other people with the same horror stories on Stack Overflow ("build boost on windows" has 877 results [2]), I decided to make the binaries that I was now good at building public. For years I had them on my website...but they were getting big and my hosting provider was getting more annoying so I requested, and the mailing list agreed, that I could release the binaries along side the source release through the boost channels. Which is basically the state to this day.

Current Usage -------------------

The windows binaries are currently downloaded ~14,000 times per month from BinTray and ~2000 times per week from sourceforge.

They are generally built with the default compiler options, which is ABI compatible for most users with the correct version of visual studio. In recent months, I have started seeing some issues from users who are changing the /std flag (new to VS2015). Which I acknowledge was one of the main issues mentioned above. There may also be more issues now that VS2017 is rolling new point releases very frequently. However, to remove the binaries for this reason is throwing out the baby with the bath water.

Going Forward --------------------

1) I plan to continue building the binaries and making them available the day of release. If the community would prefer that I get a separate bintray account and have them available there, I would be amenable to that, but I don't see that as being a net gain for anyone. I'd like to keep them as easily-discoverable as possible for new users.

2) If we can make a full cmake transition, where visual studio solutions can easily be created to make the needed libraries, that would be a good time to revisit this. I think there are still a lot of hurdles that need to be cleared on the road to this though.

3) I'd like to (when I can find the time) start pushing the binaries for each release into some of the new package management systems (conan, vcpkg, etc). While keeping the existing ones available as well, as the windows package management systems are only used by a tiny minority.

4) If boost widely drops C++03 support, I would likewise trim the toolsets that we build binaries for. (Currently supported are VS2005/msvc-8.0 through VS2017/msvc-14.1)

5) Something needs to be done to seriously overhaul the getting started for windows page. If I can find time I'll take a crack at that.

I have great respect for where this request comes from. I wish every developer (especially the ten years ago me) could easily understand how to build their own copy of boost. However, I think we as a community need to spend a lot more time thinking about the end-users who want to use boost but aren't already familiar with it.

You have reflected my thinking exactly. This whole business of "developers are so smart they will have no problem building Boost for whatever toolchains and for whatever libraries and for whatever C++ standard build levels they desire using b2" is such nonsense that I do not even know where to begin. I am not putting down Boost Build in any way but if Boost developers themselves have a hard time figuring out how to build individual libraries with particular toolchains at particular C++ standard levels and having the resultant output go where they want it to go, just imagine what this is like for the particular end-user who might want to build Boost as a whole for different toolchains at different levels while including/excluding some shared/static library building. I am for Robert Ramey's suggestion that if we decide not to distribute Boost binaries in any way anymore we need to write a much better explanation of how to build Boost as a whole for a particular toolchain and a particular standard level and for the various combinations of shared/static libraries and for the various choices of what shared/static libraries can or cannot be built than what we currently have. In fact we need that now in the "Getting Started" page, no matter what direction we go, but I know if I press for that I will be accused of making more work those people knowledgeable about Boost Build who could write a much better explanation than what currently exists, so I will not do so. But thank you Tom, if only you have brought to attention that it is the end-users of Boost we should be serving and not just ourselves.

Tom

[1] https://www.boost.org/doc/libs/1_68_0/more/getting_started/windows.html [2] https://stackoverflow.com/search?q=build+boost+on+windows

Some ideas and questions. --------- Let us assume we do not provide any binaries and let's say all library are using cmake (or possibly boost.build) with their own C++ standard conformance. End users would compile/include some boost libraries with a compiler that uses a certain ABI and libstdc++ version. Do we have ABI conflicts then? Say one library is built and tested with C++03 conformance while the second library is built and tested with C++17 conformance using e.g. 'if constexpr'. Do we have potential conflicts when compiling both libraries with say 'gcc -std=c++17' (e.g. value initialization gone wrong with the first library)? Do all boost libraries guarantee that they are compiling with newer C++ versions? Do we have rules somewhere? What about http://blincubator.com/? --------- Let us assume we want to provide binaries (for windows) similar to Qt. Would it be possible to provide different types boost versions, e.g. boost1 contains libraries requiring full C++03 conformance with a given ABI version(s), boost2 contains libraries requiring full C++11 conformance with a given ABI version(s), etc.? Maybe too much work. ---------- Could we separate boost to header-only boost and standard boost? Would that help? ---------- If we assume that cmake could be more of a help than boost.build, could cmake with very good description and introduction, tutorial be ever convenient enough for an end-user to build his/her own boost? ---------- Best Cem Am Do., 30. Aug. 2018 um 17:18 Uhr schrieb Edward Diener via Boost < boost@lists.boost.org>:

...

On Wed, Aug 29, 2018 at 9:53 AM Robert Ramey via Boost < boost@lists.boost.org> wrote:

...

The fact is that users of boost use compilers with differing levels of C++ standard conformance. This creates a number of problems including (but probably not limited to)

a) Using libraries built with different levels of C++ conformance may create ABI issues.

b) it creates a discussion about "dropping C++03 support". Actually it creates a discussion about that the above actually means.

c) It's motivated a suggestion that all libraries move to header only. This is not great idea - but I won't address that here.

I believe all these issues - and more - would disappear if we just stopped distributing binaries. Each user would be building his own boost version with (presumably) the same compiler. Since C++03 compatible libraries are C++?? compatible, each library author can maintain the level of backward compatibility that he wishes.

But if we're not going to distribute binaries, then users might as well just clone the latest "certified - good - tagged" version in the master branch from the github repo. That is, let's just stop or truncate the whole release circus. Replace with an occasional "certification/versioning procedure" which would make available a "squashed" master suitable for efficient cloning.

This would make everyone's life easier.

Robert Ramey

I've never heard of any binaries for linux/unix/mac distributed by us, so I guess this is reference to the Windows/Visual Studio binaries? As the person who builds them, I suppose I should weigh in on this.

TL;DR - We need to provide an easier way to get windows/visual studio users up and running with boost than building with b2. I love boost and want to make it as easy as possible for others to use.

History of the binaries ----------------------------- When I first got started with the boost project about a decade ago, I was a decent C++ developer at a large company (Boeing). We use C++ to develop simulators for our aircraft.

I had worked extensively with Visual Studio and our large code base. Our primary product (our simulation) is hundreds of thousands of lines of code and uses dozes of external dependencies. Most of the "external" dependencies were internally (other groups within the company) produced products. We would get dumps of .h and .lib files from other groups and add the directories to our visual studio solution include/lib paths. We would occasionally encounter ABI errors, but were very good at managing the configuration of libraries coming in to keep these from affecting us. We basically had a system similar to Conan...but fifteen years ago.

I got the task of adding Boost to one of our projects in our solution, so we could use a couple very nice libraies: asio, date time, interprocess, program options, thread, and test. Several of these are not header only, so I knew I needed static libs for them. I fought for weeks trying to get binaries. I wasn't familiar with bjam (and didn't know it was included with the source!) so I tried to load the source into visual studio and compile it....that didn't go well. Eventually I found the horrible "Getting started with windows" page [1]. It tries to lead a user to the command `b2 --toolset=msvc-14.0 --build-type=complete stage`, but fails miserably to identify the arguments that are actually needed and most users would never figure out from the page that that is the command they need.

After many *dozen* hours fighting with b2, digging through terrible b2 documentation, and googling for people who had successfully built boost on windows, I finally got my static libs out! It was a nightmare that still motivates the work that I do to make binaries available.

After getting them built, I packaged them up for use by my team. After doing this for a few releases, and seeing lots of other people with the same horror stories on Stack Overflow ("build boost on windows" has 877 results [2]), I decided to make the binaries that I was now good at building public. For years I had them on my website...but they were getting big and my hosting provider was getting more annoying so I requested, and the mailing list agreed, that I could release the binaries along side the source release through the boost channels. Which is basically the state to this day.

Current Usage -------------------

The windows binaries are currently downloaded ~14,000 times per month from BinTray and ~2000 times per week from sourceforge.

They are generally built with the default compiler options, which is ABI compatible for most users with the correct version of visual studio. In recent months, I have started seeing some issues from users who are changing the /std flag (new to VS2015). Which I acknowledge was one of

On 8/29/2018 10:40 PM, Tom Kent via Boost wrote: the

...

main issues mentioned above. There may also be more issues now that VS2017 is rolling new point releases very frequently. However, to remove the binaries for this reason is throwing out the baby with the bath water.

Going Forward --------------------

1) I plan to continue building the binaries and making them available the day of release. If the community would prefer that I get a separate bintray account and have them available there, I would be amenable to that, but I don't see that as being a net gain for anyone. I'd like to keep them as easily-discoverable as possible for new users.

2) If we can make a full cmake transition, where visual studio solutions can easily be created to make the needed libraries, that would be a good time to revisit this. I think there are still a lot of hurdles that need to be cleared on the road to this though.

3) I'd like to (when I can find the time) start pushing the binaries for each release into some of the new package management systems (conan, vcpkg, etc). While keeping the existing ones available as well, as the windows package management systems are only used by a tiny minority.

4) If boost widely drops C++03 support, I would likewise trim the toolsets that we build binaries for. (Currently supported are VS2005/msvc-8.0 through VS2017/msvc-14.1)

5) Something needs to be done to seriously overhaul the getting started for windows page. If I can find time I'll take a crack at that.

I have great respect for where this request comes from. I wish every developer (especially the ten years ago me) could easily understand how to build their own copy of boost. However, I think we as a community need to spend a lot more time thinking about the end-users who want to use boost but aren't already familiar with it.

You have reflected my thinking exactly. This whole business of "developers are so smart they will have no problem building Boost for whatever toolchains and for whatever libraries and for whatever C++ standard build levels they desire using b2" is such nonsense that I do not even know where to begin. I am not putting down Boost Build in any way but if Boost developers themselves have a hard time figuring out how to build individual libraries with particular toolchains at particular C++ standard levels and having the resultant output go where they want it to go, just imagine what this is like for the particular end-user who might want to build Boost as a whole for different toolchains at different levels while including/excluding some shared/static library building.

I am for Robert Ramey's suggestion that if we decide not to distribute Boost binaries in any way anymore we need to write a much better explanation of how to build Boost as a whole for a particular toolchain and a particular standard level and for the various combinations of shared/static libraries and for the various choices of what shared/static libraries can or cannot be built than what we currently have. In fact we need that now in the "Getting Started" page, no matter what direction we go, but I know if I press for that I will be accused of making more work those people knowledgeable about Boost Build who could write a much better explanation than what currently exists, so I will not do so. But thank you Tom, if only you have brought to attention that it is the end-users of Boost we should be serving and not just ourselves.

...

Tom

[1]

https://www.boost.org/doc/libs/1_68_0/more/getting_started/windows.html

...

[2] https://stackoverflow.com/search?q=build+boost+on+windows

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Am Do., 30. Aug. 2018 um 21:22 Uhr schrieb Robert Ramey via Boost < boost@lists.boost.org>:

On 8/30/18 9:32 AM, Cem Bassoy via Boost wrote:

...

Do we have rules somewhere? What abouthttp://blincubator.com/?

FWIW - the incubator entry for every library includes a field which specifies which C++ standard versions it is intended to work with. Also it includes a field which specifies which compilers the author has tested it with.

I've always felt that all libraries should have some similar page. Actually, I always hoped that the incubator would evolve into a better boost website with better support for the idea of "modular boost.

I totally aggree with you. I think it would be so good if we would define somehow a standard where library maintainers are required to put status badges on github (like appveyor, circleci, travis, regression, license, documention) with indication what the minimum supported C++ standard is.

Robert Ramey

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost