On Tue, Jul 18, 2017 at 8:15 AM, Rene Rivera wrote:

As a consequence.. I herby resign from all my duties in the Boost community effectively immediately. This means that I will no longer be in the Release Team.

Since none of the current Boost Steering Committee members are owners in the Github Boost.ORG organization.. Could one of the github owners please change my role from "owner" to "member"? (github doesn't allow you to do that to yourself). -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

Den 18-07-2017 kl. 16:44 skrev Edward Diener via Boost:

On 7/18/2017 9:12 AM, Jon Kalb via Boost wrote:

...

Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike.

Where are you soliciting comments and proposals from the community to guide the process and the goals ? On this mailing list ? In the Boost Steering Committee Google group ?

Good question! I find the message from a long time member like Rene quite disturbing, to say the least. We evaluated CMake in my company, but decided against it because it doesn't have support for precompiled headers. kind regards Thorsten

Den 18-07-2017 kl. 17:14 skrev Thorsten Ottosen via Boost:

Den 18-07-2017 kl. 16:44 skrev Edward Diener via Boost:

...

On 7/18/2017 9:12 AM, Jon Kalb via Boost wrote:

...

...

Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike.

Where are you soliciting comments and proposals from the community to guide the process and the goals ? On this mailing list ? In the Boost Steering Committee Google group ?

Good question!

I find the message from a long time member like Rene quite disturbing, to say the least.

In case it wasn't clear, it's not what Rene says that is disturbing, but that it has come so far that he has to say it. Where is all the discussion that led to this decision? The pros and cons? The feedback from the community and members? kind regards Thorsten

On 7/18/2017 2:08 PM, Louis Dionne via Boost wrote:

Boost - Dev mailing list wrote

...

Den 18-07-2017 kl. 17:14 skrev Thorsten Ottosen via Boost:

...

Den 18-07-2017 kl. 16:44 skrev Edward Diener via Boost:

...

On 7/18/2017 9:12 AM, Jon Kalb via Boost wrote:

...

...

Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike.

Where are you soliciting comments and proposals from the community to guide the process and the goals ? On this mailing list ? In the Boost Steering Committee Google group ?

Good question!

I find the message from a long time member like Rene quite disturbing, to say the least.

In case it wasn't clear, it's not what Rene says that is disturbing, but that it has come so far that he has to say it.

Where is all the discussion that led to this decision? The pros and cons? The feedback from the community and members?

kind regards

There was a lot of discussion on the list recently about various levels of integrations between Boost and CMake. A lot of interest was generated and we thought it was very positive. The intent of the message we sent was to make it clear that there was an intent to actually make something out of these proposals, not to just let them die like some previous CMake efforts have.

Please notice that the message does not impose any "way of getting there", nor does it talk about technical superiority of one solution over the other. The problems we believe Boost needs to solve are

(1) Users have a hard time integrating Boost into their build system, which is CMake more often than not (but not always, and we're trying to please the majority here) (2) Prospective Boost developpers are sometimes driven away from submitting because they would have to use Boost's build system, which they don't know.

I can't speak for the Steering Committee as a whole, but I believe that basically any solution that solves the above two problems would satisfy the intent of the message that was posted.

In that case why not have said that Boost libraries and tools will be supporting CMake, which I think is fair enough given the wish to form a consensus, but that Boost Build will continue to be developed/supported for those libraries and tools that still want to rely on it as an alternative. Given that we have people like Rene, Steven, and Thorsten, among others, who still work to improve Boost Build, I see such a decision to give up Boost Build entirely for CMake, before we even know if we can actually duplicate all the functionality which Boost Build provides in CMake, as a bad decision. I am not against providing CMake for the user community at large, but I just don't think we should be throwing Boost Build away.

Louis

-- View this message in context: http://boost.2283326.n4.nabble.com/CMake-Announcement-from-Boost-Steering-Co... Sent from the Boost - Dev mailing list archive at Nabble.com.

On 7/18/2017 3:27 PM, Louis Dionne via Boost wrote:

...

On 7/18/2017 2:08 PM, Louis Dionne via Boost wrote:

...

I can't speak for the Steering Committee as a whole, but I believe that basically any solution that solves the above two problems would satisfy the intent of the message that was posted.

In that case why not have said that Boost libraries and tools will be supporting CMake, which I think is fair enough given the wish to form a consensus, but that Boost Build will continue to be developed/supported for those libraries and tools that still want to rely on it as an alternative.

Because it's not the SC's job to decide whether Boost.Build should be dropped or not, and the details of how CMake should be supported. If folks still want to work on Boost.Build, nothing prevents them from doing so. Boost.Build may or may not be mandatory for being considered a Boost library going forward, but that's one thing that needs to be determined by the community.

When you originally write: "Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike." it is interpreted by me that the plan for adopting CMake for Boost is that Boost Build is being dropped. I would like to point out that Boost Build has advanced facilities which CMake does not presently have and that these facilities form some part of how some libraries get used ( built, tested, documented ). Unless CMake can be made to duplicate some of this functionality Boost will be offering end-users less functionality than they presently have. I think the goal is always to offer equal or better functionality. I do understand that C++ developers find it easier to understand and use CMake than Boost Build so I think that any proposed move to CMake as the required build environment must take these things into account, and equivalent CMake functionality should be developed to ease the transition. That is why it is important to me that Boost Build be offered as an immediate alternative in Boost's future plans.

Louis

-- View this message in context: http://boost.2283326.n4.nabble.com/CMake-Announcement-from-Boost-Steering-Co... Sent from the Boost - Dev mailing list archive at Nabble.com.

On 7/19/2017 10:29 AM, paul via Boost wrote:

On Tue, 2017-07-18 at 22:03 -0400, Edward Diener via Boost wrote:

...

On 7/18/2017 3:27 PM, Louis Dionne via Boost wrote:

...

...

On 7/18/2017 2:08 PM, Louis Dionne via Boost wrote:

...

I can't speak for the Steering Committee as a whole, but I believe that basically any solution that solves the above two problems would satisfy the intent of the message that was posted.

In that case why not have said that Boost libraries and tools will be supporting CMake, which I think is fair enough given the wish to form a consensus, but that Boost Build will continue to be developed/supported for those libraries and tools that still want to rely on it as an alternative.

Because it's not the SC's job to decide whether Boost.Build should be dropped or not, and the details of how CMake should be supported. If folks still want to work on Boost.Build, nothing prevents them from doing so. Boost.Build may or may not be mandatory for being considered a Boost library going forward, but that's one thing that needs to be determined by the community.

When you originally write:

"Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike."

it is interpreted by me that the plan for adopting CMake for Boost is that Boost Build is being dropped.

I would like to point out that Boost Build has advanced facilities which CMake does not presently have and that these facilities form some part of how some libraries get used ( built, tested, documented ).

CMake can handle mutlitple variants, it just requires seperate build trees. However, there are things which cmake can handle that boost build cannot. Boost.Build cannot get find prebuilt libraries or get usage requirements for prebuilt libraries directly, and thus has no mechanism to tell it where the depedencies are.

Please look at the 'lib' rule in Boost Build at http://www.boost.org/build/doc/html/bbv2/tasks/libraries.html and tell me why you think Boost Build does not support prebuilt libraries.

Actually, trying to support multiple variants and prebuilt libraries complicates things. Which is why cmake doesn't support mutliple variants in the same build tree well, and boost build doesn't support prebuilt libraries that well. Of course, there is always workarounds. In bjam, you just create a custom variable to where the prebuilt binary is, and the user needs to pass that in for every dependency. In cmake, you just create multiple build directories for each variant you have. However, the workaround for cmake can be automated across many different libraries, but the workaround for boost.build cannot, as the custom variables could always be different.

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

Den 19-07-2017 kl. 18:58 skrev paul via Boost:

On Wed, 2017-07-19 at 12:39 -0400, Edward Diener via Boost wrote:

...

Please look at the 'lib' rule in Boost Build at http://www.boost.org/build/doc/html/bbv2/tasks/libraries.html and tell me why you think Boost Build does not support prebuilt libraries.

But it only searches along the default compiler paths and additional paths added in the build script. There is no way for me to inform bjam that I installed my dependencies in another directory.

That is, I installed my dependencies in /deps. So how do I tell boost to look for zlib and bzip2 there? I can't say `--prefix-path /deps` and it will find them. Instead I need to say `-s ZLIB_LIBPATH=/deps -s BZIP2_LIBPATH=/deps`. A custom variable for each one.

For example, you may say lib SqlApi : : <name>sqlapi <search>$(DEPENDENCY_ROOT)/lib/Debug <variant>debug ; lib SqlApi : : <name>sqlapi <search>$(DEPENDENCY_ROOT)/lib/Release <variant>release ; -Thorsten

On Wed, 2017-07-19 at 11:23 -0600, Steven Watanabe via Boost wrote:

AMDG

On 07/19/2017 10:58 AM, paul via Boost wrote:

...

On Wed, 2017-07-19 at 12:39 -0400, Edward Diener via Boost wrote:

...

Please look at the 'lib' rule in Boost Build at  http://www.boost.org/build/doc/html/bbv2/tasks/libraries.html and tell  me why you think Boost Build does not support prebuilt libraries.

But it only searches along the default compiler paths and additional paths added in the build script. There is no way for me to inform bjam that I installed my dependencies in another directory. 

b2 library-path=/deps

I was unaware of this, and Rene was as well. We were discussing adding flags such as --library-<variant>-path.

...

That is, I installed my dependencies in /deps. So how do I tell boost to look for zlib and bzip2 there? I can't say `--prefix-path /deps` and it will find them. Instead I need to say `-s ZLIB_LIBPATH=/deps -s BZIP2_LIBPATH=/deps`. A custom variable for each one.

That is just one issue, the other issue is that it doesn't provide usage requirements for prebuilt libraries. I install a library with Boost.Build, but even even if downstream libraries are using Boost.Build, there is no information available about the its usage requirements.

I'm afraid I don't understand.  pre-built library targets can have usage requirements just like any other target.

But where does it get those usage requirements from? It should come from the original install. When I install boost(with b2 install or apt-get install), I see no files with bjam targets I can use.

On 18/07/2017 21:28, Edward Diener via Boost wrote:

In that case why not have said that Boost libraries and tools will be supporting CMake, which I think is fair enough given the wish to form a consensus, but that Boost Build will continue to be developed/supported for those libraries and tools that still want to rely on it as an alternative. Given that we have people like Rene, Steven, and Thorsten, among others, who still work to improve Boost Build, I see such a decision to give up Boost Build entirely for CMake, before we even know if we can actually duplicate all the functionality which Boost Build provides in CMake, as a bad decision.

+1. I think the first step is to make Boost buildable with CMake while maintaining Boost.Build. After we have enough experience, we can decide to maintain both or drop one of them. Ion

On 7/19/2017 5:08 AM, Thorsten Ottosen via Boost wrote:

Den 18-07-2017 kl. 23:23 skrev Ion Gaztañaga via Boost:

...

On 18/07/2017 21:28, Edward Diener via Boost wrote:

...

In that case why not have said that Boost libraries and tools will be supporting CMake, which I think is fair enough given the wish to form a consensus, but that Boost Build will continue to be developed/supported for those libraries and tools that still want to rely on it as an alternative. Given that we have people like Rene, Steven, and Thorsten, among others, who still work to improve Boost Build,

I can take no credit for developing or maintaining Boost.Build. I'm just a user of it.

I meant Vladimir Prus and mentioned your name instead. My mistake.

-T

On 7/18/17 2:18 PM, Ion Gaztañaga via Boost wrote:

On 18/07/2017 20:08, Louis Dionne via Boost wrote:

...

(2) Prospective Boost developpers are sometimes driven away from submitting because they would have to use Boost's build system, which they don't know.

I don't think a C++ programmer with a programming level to write a Boost library would have any problem to write a Jamfile copy-pasting from any library.

LOL - as such a programmer I can tell you you're wrong! I don't think you can make a working Jamfile by cutting and pasting. I have to go back to the bjam documentation and then almost always post a question on the list. Bjam may have it's advantages - but simplicity, transparency and ease of use are not among them.

Ion

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

On 7/18/17 3:52 PM, Tom Westerhout via Boost wrote:

On Jul 19, 2017 12:00 AM, "Robert Ramey via Boost" wrote:

...

On 7/18/17 2:18 PM, Ion Gaztañaga via Boost wrote:

...

On 18/07/2017 20:08, Louis Dionne via Boost wrote:

...

(2) Prospective Boost developpers are sometimes driven away from submitting because they would have to use Boost's build system, which they don't know.

I don't think a C++ programmer with a programming level to write a Boost library would have any problem to write a Jamfile copy-pasting from any library.

LOL - as such a programmer I can tell you you're wrong! I don't think you can make a working Jamfile by cutting and pasting. I have to go back to the bjam documentation and then almost always post a question on the list. Bjam may have it's advantages - but simplicity, transparency and ease of use are not among them.

I'm just a GSoC student, so I don't really fit the "Boost library developer" profile... Anyway, I had to use either CMake or Boost.Build to build and run some tests, and because I had no experience with either, and Boost.Build seemed more boost'y, I went for it. So I've just had an experience learning to write Jamfiles, and I'd argue that it's not that difficult, for a _basic_ case. I.e. as long as you don't need to your own target types and generators, you're fine.

It all goes wrong when you need more "advanced" stuff. I think it's cost me approximately 30 hours in total of browsing through docs and source code before I've begun to understand how things work. I still don't understand the pro topics though.

It seems to me like there's just not enough documentation/examples. And I understand that it's terribly boring for advanced users to write the docs because this stuff is obvious for them, and impossible for newcomers because they don't understand it themselves. But, I guess, it's a quite common situation. And, as usually, the efforts should be combined, i.e. someone tries to learn Boost.Build, writes down all his questions while gurus help him find and write down the answers. And we obtain nice docs in the end. I'd even be willing to volunteer for the padawan's position (after GSoC though).

The point I'm trying to make here is that some non-radical changes might be enough to solve the problems Louis has outlined (second one at the very least, and as some people have indicated CMake might not help with the first one either). And trying them out will probably take much less time than the transition to CMake, so why not try the fast & easy path first?

I pretty much agree with this assessment. It starts out simple, but then you need to make something a little bit fancier and then .... I think bjam could be made much better with relatively few changes. The documents are actually quite good. I know this as I had to plow through them for the Nth time the other day. A large part of the problem is that there is too much implicit behavior to actually documentation which is fine when things "just work" but then - .... I and others have been complaining about this for many years. No action has been taken. Maybe it's not doable, or maybe it's a thankless task which is not exceeding tedious for the people who are actually capable of addressing this. I don't know. But now we've come to this. Hopefully we can slog through this without getting lost in the weeds - we'll see. Robert Ramey

On Tue, Jul 18, 2017 at 5:59 PM Alain Miniussi via Boost < boost@lists.boost.org> wrote:

On 18/07/2017 23:18, Ion Gaztañaga via Boost wrote:

...

On 18/07/2017 20:08, Louis Dionne via Boost wrote:

...

(2) Prospective Boost developpers are sometimes driven away from submitting because they would have to use Boost's build system, which they don't know.

I don't think a C++ programmer with a programming level to write a Boost library would have any problem to write a Jamfile copy-pasting from any library. ...

Even if there was learning material, one should not have to learn a new

boost specific build system just to contribute. And I don't think bjam can build anything else than a simple C++ project so it's not like you can capitalize on the time spent (I tried, then switched to CMake).

CMake could be a piece of junk, but it's a maintained, somehow documented, community supported piece of junk, that I can use on real projects.

I'm sure this is how a lot of C++ users out there feel. Yes, anyone who can learn C++ can learn another build system. But why require more burden than is strictly necessary? CMake is the very clear trend across the broader community. Yes, it's far from perfect -- despite a monumental clean-up effort. But more developer systems have CMake installed already. Even IDEs such as CLion and Visual Studio are putting their weight behind it. I am hugely appreciative of anyone who is willing to put aside their own solutions in order to improve interoperability and simplicity. This will surely be a positive thing for Boost and C++ in the long term.

2017-07-19 15:19 GMT+03:00 Ion Gaztañaga via Boost :

On 19/07/2017 3:48, John McFarlane via Boost wrote:

...

I'm sure this is how a lot of C++ users out there feel. Yes, anyone who can learn C++ can learn another build system. But why require more burden than is strictly necessary? CMake is the very clear trend across the broader community. Yes, it's far from perfect -- despite a monumental clean-up effort. But more developer systems have CMake installed already.

CMake, for instance, does not really build. AFAIK, it generates build instructions for the real build system.

This is unacceptable to me, I want something that really builds the program and also runs tests from the command line, I want to use the same commands in Windows, Linux, FreeBSD and other systems where I test my software.

JFYI, same commands used on every system 1. generate> cmake .. 2. build> cmake --build . 3. test> ctest -- Best Regards, Sergei Nikulov

2017-07-19 15:47 GMT+03:00 Daniela Engert via Boost :

Am 19.07.2017 um 14:30 schrieb Sergei Nikulov via Boost:

...

2017-07-19 15:19 GMT+03:00 Ion Gaztañaga via Boost :

...

CMake, for instance, does not really build. AFAIK, it generates build instructions for the real build system.

That's my understanding, too.

...

...

This is unacceptable to me, I want something that really builds the program and also runs tests from the command line

That are pretty much my requirements when switching through a ton of different configurations of compiler versions / bitness (32 or 64) / mode (debug or release) when I test changes to one of the 110 Boost libraries, that I needed to fork.

...

JFYI, same commands used on every system 1. generate> cmake .. 2. build> cmake --build . 3. test> ctest

Ok, so how do I fire off a libraries test-suite using f.i. msvc-14.1/32/release concurrently to another one using f.i. msvc-14.0/64/release (and may be some more)? I may be missing something.

Yes, you've got me :) This is one of the bad sides about CMake. To cover your case, I usually using buildbot with the different configurations (Debug/Release/etc...) Disclaimer: I'm not from Boost Steering Committee, and not pushing CMake for Boost libraries. Just provide information to Ion how to use cmake from command line :) -- Best Regards, Sergei Nikulov

Am 19.07.2017 3:12 nachm. schrieb "Peter Dimov via Boost" < boost@lists.boost.org>: Sergei Nikulov wrote: JFYI, same commands used on every system

1. generate> cmake .. 2. build> cmake --build . 3. test> ctest

Well not entirely, because for MS backends you can pick --config Release at build time and for the rest you need to pick -DCMAKE_BUILD_TYPE at configure time. Not to mention the address-model, choosing which MSBuild supports at build time, but CMake not only doesn't, you have to use an entirely different generator for 64 bit. What does this mean for boost's regression test? Especially for the fiber library I need a combination of: - address-model (32/64) - architecture (arm, arm64, mips, ....) - binary format (elf, ms, o32, mach-o, ...) - ABI (sysv, aapcs, ...) - implementation (assembler, ucontext, windows fibers) - segmented stacks (on/off) - valgrind (on/off) - transactional memory (on/off) ... Do I need to provide for each combination a different generator?

On 2017-07-19 14:58, Oliver Kowalke via Boost wrote:

What does this mean for boost's regression test? Especially for the fiber library I need a combination of: - address-model (32/64) - architecture (arm, arm64, mips, ....) - binary format (elf, ms, o32, mach-o, ...) - ABI (sysv, aapcs, ...) - implementation (assembler, ucontext, windows fibers) - segmented stacks (on/off) - valgrind (on/off) - transactional memory (on/off) ... Do I need to provide for each combination a different generator?

I would suggest that you would start off by dropping these options: - address-model - architecture - binary format They are already handled by standard CMake options to choose the compiler and its compile/link flags, so there's no need to deviate from the common way of doing things. The rest can be implemented straightforwardly as cache options so that you can run cmake with options like -Dvalgrind=OFF -Dtransactional-memory=ON -Dsegmented-stacks=ON [-D…] You would need to make a build directory for each combination you want to test, and then run cmake to configure that combination, then build and test. Regards, Roger

On 19/07/2017 14:30, Sergei Nikulov via Boost wrote:

2017-07-19 15:19 GMT+03:00 Ion Gaztañaga via Boost :

...

On 19/07/2017 3:48, John McFarlane via Boost wrote:

...

I'm sure this is how a lot of C++ users out there feel. Yes, anyone who can learn C++ can learn another build system. But why require more burden than is strictly necessary? CMake is the very clear trend across the broader community. Yes, it's far from perfect -- despite a monumental clean-up effort. But more developer systems have CMake installed already.

CMake, for instance, does not really build. AFAIK, it generates build instructions for the real build system.

This is unacceptable to me, I want something that really builds the program and also runs tests from the command line, I want to use the same commands in Windows, Linux, FreeBSD and other systems where I test my software.

JFYI, same commands used on every system 1. generate> cmake .. 2. build> cmake --build . 3. test> ctest

Many thanks. I've seen the build option was added in CMake 3.0 a couple of years ago. Good to know, because there are many internet tutorials calling "MsBuild" and "make". Ion

On 19/07/2017 3:48, John McFarlane via Boost wrote:

...

I'm sure this is how a lot of C++ users out there feel. Yes, anyone who can learn C++ can learn another build system. But why require more burden than is strictly necessary? CMake is the very clear trend across the broader community. Yes, it's far from perfect -- despite a monumental clean-up effort. But more developer systems have CMake installed already.

CMake, for instance, does not really build. AFAIK, it generates build instructions for the real build system. A little bit like bootstrap.sh does, plus the project-config.jam that I need to modify by hand each time I want to test a new configuration.

This is unacceptable to me, I want something that really builds the program and also runs tests from the command line, I want to use the same commands in Windows, Linux, FreeBSD and other systems where I test my software. I don't, I want too use the same system I'm already used to anyway on

I don't want to waste my time recreating MSVC projects every time I build. I want regression tests to continue working nicely and portable passing common useful options that work in every system.

CMake is popular, no doubt. So is autotools, and no one is proposing it for Boost. Because it's not available on Window I guess. On Unix-like, I've found autotools slightly less worse than bjam in the sense that when I need to deal with code mixing MPI, C++, Fortran etc.. bjam is out. So I went autotool->bjam->autotool(yurk!)->CMake. But if a project is simple enough for bjam, then moving to autotool is

On 19/07/2017 14:19, Ion Gaztañaga via Boost wrote: those platforms. probably a bad idea.

I have no problems to switch to CMake if:

- Cmake does everything Boost.Build does with the same or less work. I just enter 'make' in my build directories, cmake is re-called automatically if necessary. And it does a lot of thing I could not do with bjam (arbitrary feature detection mostly, seems a PITA with bjam). And I can switch between all my configurations just by changing the build directory which, when I need to test the cross product of various compilers/MPI, is a huge gain. I am not sure how to build an test N configuration at the same time with bjam without having N instance of the code tree. Maybe it's in the tutorial.

- Cmake performance is equal or better. Well, cmake never required me having to launch a script in the back ground to send signals to hanging bjam tasks during test (eternity can be quite long), so how can it be worse... as for the (usually parallel) build, source dependencies are what they are, and so is the compiler.

CMake popularity is not important for me as a Boost programmer, in some years CMake will be replaced by another super-popular build system.

Yep, and maybe people will choose to move to that system if they think it's worth it.

For users we can automatically generate CMake projects from Boost.Build, and maybe other popular build systems.

Ion

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

On 19/07/2017 14:57, Alain Miniussi via Boost wrote:

...

...

I have no problems to switch to CMake if:

- Cmake does everything Boost.Build does with the same or less work. I just enter 'make' in my build directories, cmake is re-called automatically if necessary. And it does a lot of thing I could not do with bjam (arbitrary feature detection mostly, seems a PITA with bjam). And I can switch between all my configurations just by changing the build directory which, when I need to test the cross product of various compilers/MPI, is a huge gain. I am not sure how to build an test N configuration at the same time with bjam without having N instance of the code tree. Maybe it's in the tutorial.

I test my libraries with the following lines in windows:

MSVC

b2 -j12 toolset=msvc-7.1,msvc-8.0,msvc-9.0,msvc-10.0,msvc-11.0,msvc-12.0,msvc-14.0,msvc-14.1 variant=debug,release address-model=32,64 debug-symbols=on

MINGW

b2 -j12 toolset=toolset=gcc-3.4c++03,gcc-4.1c++03,gcc-4.2c++03,gcc-4.3c++03,gcc-4.4c++03,gcc-4.5c++03,gcc-4.6c++03,gcc-5.3c++03,gcc-6.1c++03,gcc-6.2c++03,gcc-6.3c++03 variant=debug,release address-model=32 debug-symbols=on

Not to mention link=static,shared runtime-link=static-shared, and all possible combinations. B2 compiles and executes it really fast.

My question as a Boost developer is, can CMake do the same with similar performance (time/memory/disk,etc.)? I do not know what are the performances with bjam, I just create one build tree (outside of the source tree) per variant, configure once for each variant and then iterate over the build directories. I want to keep

On 19/07/2017 16:59, Ion Gaztañaga via Boost wrote: the build trees and I want to launch different variants build/texts on different nodes, so the trees need to be separate anyway. So it does take some space since I do not delete the build tree (that is, I choose to keep the object files, I do not know if your technique does the same). But I want to be able to go into the directory of combination X's build when things go wrong anyway. But my variants includes properties (if that the term used to designate toolset, variant etc..) that are not anticipated be bjam. Each MPI implementation correspond to a specify project-config.jam file (sometime simple, sometime not), so I am not sure how I could iterate over intel-mpi-5.0.1,open-mpi-1.6.2, etc... basically, I need to check how it works with different versions/vendor.configuration of an external tools. Regards Alain

Best,

Ion

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

On 19/07/2017 18:03, Olaf van der Spek wrote:

...

...

MSVC

b2 -j12 toolset=msvc-7.1,msvc-8.0,msvc-9.0,msvc-10.0,msvc-11.0,msvc-12.0,msvc-14.0,msvc-14.1 variant=debug,release address-model=32,64 debug-symbols=on

MINGW

b2 -j12 toolset=toolset=gcc-3.4c++03,gcc-4.1c++03,gcc-4.2c++03,gcc-4.3c++03,gcc-4.4c++03,gcc-4.5c++03,gcc-4.6c++03,gcc-5.3c++03,gcc-6.1c++03,gcc-6.2c++03,gcc-6.3c++03 variant=debug,release address-model=32 debug-symbols=on

Not to mention link=static,shared runtime-link=static-shared, and all possible combinations. B2 compiles and executes it really fast.

My question as a Boost developer is, can CMake do the same with similar performance (time/memory/disk,etc.)? I do not know what are the performances with bjam, I just create one build tree (outside of the source tree) per variant, configure once for each variant and then iterate over the build directories. I want to keep the build trees and I want to launch different variants build/texts on different nodes, so the trees need to be separate anyway. So it does take some space since I do not delete the build tree (that is, I choose to keep the object files, I do not know if your technique does the same). But I want to be able to go into the directory of combination X's build when things go wrong anyway. But my variants includes properties (if that the term used to designate toolset, variant etc..) that are not anticipated be bjam. Each MPI implementation correspond to a specify project-config.jam file (sometime simple, sometime not), so I am not sure how I could iterate over intel-mpi-5.0.1,open-mpi-1.6.2, etc... basically, I need to check how it works with different versions/vendor.configuration of an external tools. So in addition to cmake we need scripts to create all those build

On Wed, Jul 19, 2017 at 5:39 PM, Alain Miniussi via Boost wrote: directories and to actually run all those builds? And every project using cmake has to bring their own version of those scripts? Only if you want to use that technique, which I find convenient (and which I cannot use with bjam, so I need to override the previous build for each configuration, cannot run in parallel on different nodes, unless have one git clone per flavor). Right now, with bjam, those libs (the one requiring such tunning) are basically not tested by default. It's not one per project, it's one. And those script/config are likely to be platform specific, they're would be certainly no much point in sharing the specificities of the platforms I use.

On Tue, Jul 18, 2017 at 11:27 AM, Robert Ramey via Boost wrote:

As it reads - it sounds like a decision has been made to .... what exactly?

My reading is as follows: * CMake will be a requirement for all libraries * Bjam will be optional I don't presume to speak for the committee, this is my personal interpretation.

On Tue, 18 Jul 2017 at 15:00 Louis Dionne via Boost wrote:

(1) Users have a hard time integrating Boost into their build system, which is CMake more often than not (but not always, and we're trying to please the majority here)

(2) Prospective Boost developpers are sometimes driven away from submitting because they would have to use Boost's build system, which they don't know.

Furthermore, there was an implicit understanding that if the community as a whole objected to any change or could not come to any consensus, nothing would be forced onto it. However, the _intent_ is clear, and it is that if we do have a good solution for solving problems (1) and (2), we should do it (as opposed to rejecting it, like what has happened in the past).

I would love to see the Boost community come together and figure out how we can solve problems (1) and (2) in the best possible way.

Louis

It has been discussed multiple times that supporting (1) does not require switching to CMake. (2) probably does, but from my point of view, that would actually make boost less usable in my work environment. I use CMake for all of my personal and open source projects and it's great for that, but no company I have worked for has used CMake internally for anything. I'm sure that there are companies that do, but in my experience, every big C++ shop maintains their own custom build system so switching to CMake will add a new dependency that didn't previously exist. It's probably not a deal breaker, but it is a regression because every time I upgrade boost, I might need to upgrade CMake, and because we don't rely on system installed packages for anything I would need to upgrade CMake in our internal package manager before I can upgrade boost. Currently, all I need to do it write a script called from our custom build system that does something like; - call bootstrap - call b2 with appropriate flags (this is the hard part) - add the include path - synthesize the link libraries What's nice about this is that there are no dependencies -- everything is completely self contained, and I like that. For me, from a user point of view, I like things they way they currently are. I can build boost easily in a work environment with no dependencies when not using CMake. When I am using CMake, I can easily set BOOST_ROOT and call FindPackage(Boost) and everything just works. I've had very few problems with this. I've never had to deal with boost.build in any significant way, so I can't speak to how difficult it is. But I feel like this keeps coming up because some people really don't like boost.build and are tying to force the change and something the users really want when that's not actually the case when considering the wider audience. -- chris

On Tue, Jul 18, 2017 at 3:24 PM, Chris Glover via Boost < boost@lists.boost.org> wrote:

[snip]

internal package manager before I can upgrade boost. Currently, all I need

...

to do it write a script called from our custom build system that does something like;

- call bootstrap - call b2 with appropriate flags (this is the hard part) - add the include path - synthesize the link libraries

What's nice about this is that there are no dependencies -- everything is completely self contained, and I like that.

There is no reason why Boost+CMake can't do that too. In order for it to be as self-contained as it is now, it would require embedding the source code for CMake and any of its dependencies (I'm not sure whether there any to speak of) into the Boost distribution. I agree with Chris in that a big advantage of the current setup is that it is not dependent on CMake being installed on the user's system already. Even in today's almost-always-connected-to-a-package-manager world,

On 07/18/2017 04:33 PM, Zach Laine via Boost wrote: there are setups where it is cumbersome to say the least to install additional packages (especially binaries) when they are needed. I'm not a fan of Boost.Build either (I've used it almost exclusively in the workflow described above), but it seems like this effort is "discard one poorly documented, difficult to author/read build tool used by relatively few people, adopt a poorly documented, difficult to author/read build tool used by a lot more people". It's a shame that there really isn't a better tool that is easy to read, write, extend, and use across multiple platforms. At the risk of running into the situation described in https://xkcd.com/927/, I hope something better than CMake emerges someday. Jason

On 18.07.2017 17:00, Vladimir Prus via Boost wrote:

On 18/07/2017 16:12, Jon Kalb via Boost wrote:

...

Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike.

I am obviously biased, so I won't comment on technical merits of this desire. Also, as usual in open-source, those who write the most code get to decide in the end.

Exactly ! A decision such as this one will affect project developers and maintainers the most, as they are the ones who need to fix bugs or respond to support requests. It is precisely in that spirit that I have asked repeatedly for this decision to be made by individual projects, rather than by any "Committee". To make this very explicit: I don't see myself either contributing to nor maintaining any infrastructure that was imposed onto the Boost.Python library by anyone who is not himself actively participating in the project. In fact, I don't see how any single entity could impose anything like this on Boost as a whole. It's not only entirely against the spirit of Free Software and Open Source, but it's also impossible to implement. Who will be responsible for the change ? Who will be responsible for any fallout generated in the process (and one has to be very naive to assume that there won't be any) ? So, in this spirit, I reiterate my counter-proposal: Change the Boost (build) infrastructure to allow *individual projects* to decide what tools are involved in the build process. To make this practical, this could simply mean that individual projects get to decide whether they want to move to cmake or stay with the original b2 infrastructure. Coming up with a simple integration point so boost as a whole can be built with a single command, while its components can use either cmake or b2, shouldn't be any harder than the wholesale switch that is being proposed. Stefan -- ...ich hab' noch einen Koffer in Berlin...

On 18.07.2017 19:43, Louis Dionne via Boost wrote:

...

...

On 18/07/2017 16:12, Jon Kalb via Boost wrote:

...

Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike. I am obviously biased, so I won't comment on technical merits of this desire. Also, as usual in open-source, those who write the most code get to decide in the end. Exactly ! A decision such as this one will affect project developers and

On 18.07.2017 17:00, Vladimir Prus via Boost wrote: maintainers the most, as they are the ones who need to fix bugs or respond to support requests. It is precisely in that spirit that I have asked repeatedly for this decision to be made by individual projects, rather than by any "Committee". Let me please quote the original message:

We are soliciting comments and proposals from the community to guide the process and the goals.

Basically, what we're saying is not "we're doing this, now implement it". It's more like "we've got some problems, let's figure how to fix them together".

While I agree that sounds much better, it is not my reading of the original. "...announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike..." is a statement of a (perceived) solution, not a problem statement combined with an invitation to think about possible solutions.

...

To make this very explicit: I don't see myself either contributing to nor maintaining any infrastructure that was imposed onto the Boost.Python library by anyone who is not himself actively participating in the project. In fact, I don't see how any single entity could impose anything like this on Boost as a whole. To be clear, things will be imposed on people in any decently-sized organization. For example, it was imposed on me to add Boost.Build support when Hana was accepted into Boost, and I conformed.

Yeah, when you submit a library to Boost, you know exactly what you get yourself into. The current situation is quite different, though. (And for avoidance of doubt: I don't really want to talk about the technical details of the change, whether cmake really is the best choice, or how hard it would be for me to learn. As Vladimir has said in another reply: it's the process itself that is utterly broken, as those who are concerned the most aren't even consulted, at least not in the decision-making process.)

...

[...]

So, in this spirit, I reiterate my counter-proposal: Change the Boost (build) infrastructure to allow *individual projects* to decide what tools are involved in the build process. To make this practical, this could simply mean that individual projects get to decide whether they want to move to cmake or stay with the original b2 infrastructure. Coming up with a simple integration point so boost as a whole can be built with a single command, while its components can use either cmake or b2, shouldn't be any harder than the wholesale switch that is being proposed. Please note that the original announcement does not preclude this from happening; It does.

so long as new authors can stick to CMake and users can integrate with Boost seamlessly from CMake, I do think this would be a valid way to solve the problem. But that's not at all what I'm saying. My point is precisely that I (as Boost.Python maintainer) do not want others to request from me that Boost.Python be buildable using cmake, and then submit bug reports about a broken cmake infrastructure that I'm neither able nor willing to maintain. What I do suggest is that I provide a (reasonably simple) way to build Boost.Python (using infrastructure I understand and thus can maintain), with integration points so the Boost super-project can be built with Boost.Python being part of it.

I'm assuming that there would be a way to generate CMake config files that work out of the box from B2 with your approach.

I think that is very naive. Of course, others are free to use their own wrapper tools, but I feel in no way obliged to support those.

It does add complexity to the system, but that's a solution like another, and in fact it does have its advantages too since it means we don't need a wholesale migration when CMake is not cool anymore.

Yes. I have repeatedly pointed out another (much more natural) solution for the problem of wholesale migrations (modularity !), which unfortunately didn't receive the required support to be considered seriously. Stefan -- ...ich hab' noch einen Koffer in Berlin...

On 19/07/2017 11:43, Stefan Seefeld wrote:

So, in this spirit, I reiterate my counter-proposal: Change the Boost (build) infrastructure to allow *individual projects* to decide what tools are involved in the build process. To make this practical, this could simply mean that individual projects get to decide whether they want to move to cmake or stay with the original b2 infrastructure. Coming up with a simple integration point so boost as a whole can be built with a single command, while its components can use either cmake or b2, shouldn't be any harder than the wholesale switch that is being proposed.

Doesn't this just then push the burden onto the user of Boost libraries to have *all* of B2, cmake, autotools, scons, rake, ant, vanilla make (possibly with GNU extensions), etc etc ad infinitum? I don't see how that could ever be practical.

On 19/07/2017 14:41, Robert Ramey wrote:

One thing that always seems to get lost in this discussion is the distinction between library developers and library users. Library users need a simple way to import libraries. If one where to make (or if it already exists) most library users would be satisfied if all that had to do was something like FindBoostSerializaton or something like that. Since they are downloading binaries, they wouldn't care how boost was built etc.

That doesn't necessarily follow. From that perspective, there's two kinds of Boost library users (ignoring those who want to actually modify Boost code): 1. The kind that just downloads prebuilt binaries and wants to use them. This group could be amply served by providing a pkgconfig file for Linux and a props file for Windows+VS -- though since ultimately in both cases it's mostly just specifying where the files were put (which could be different for each user) this is probably more of a documentation thing (providing a template where they fill in the actual path themselves) than anything else. I suspect the Linux distribution package maintainers probably already do this sort of thing; if you want to use system-provided Boost then it Just Works™. 2. The kind that wants to build the libraries themselves. There's many reasons for this; some want to use them on compilers or environments for which prebuilt binaries are not available; some want to tweak the settings for some particular library; some just want confidence that they have the actual source for the binary. These people mostly just want a simple command to build everything (or whatever subset they require). For the most part, they don't care how it happens or what tool is used, but the fewer external dependencies the better (as fewer things to go wrong). I've made some assumptions, of course, but I believe this is true.

On 7/18/2017 7:43 PM, Stefan Seefeld via Boost wrote:

On 18.07.2017 17:00, Vladimir Prus via Boost wrote:

...

On 18/07/2017 16:12, Jon Kalb via Boost wrote:

...

Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike.

I am obviously biased, so I won't comment on technical merits of this desire. Also, as usual in open-source, those who write the most code get to decide in the end.

Exactly ! A decision such as this one will affect project developers and maintainers the most, as they are the ones who need to fix bugs or respond to support requests. It is precisely in that spirit that I have asked repeatedly for this decision to be made by individual projects, rather than by any "Committee".

To make this very explicit: I don't see myself either contributing to nor maintaining any infrastructure that was imposed onto the Boost.Python library by anyone who is not himself actively participating in the project. In fact, I don't see how any single entity could impose anything like this on Boost as a whole. It's not only entirely against the spirit of Free Software and Open Source, but it's also impossible to implement. Who will be responsible for the change ? Who will be responsible for any fallout generated in the process (and one has to be very naive to assume that there won't be any) ?

So, in this spirit, I reiterate my counter-proposal: Change the Boost (build) infrastructure to allow *individual projects* to decide what tools are involved in the build process. To make this practical, this could simply mean that individual projects get to decide whether they want to move to cmake or stay with the original b2 infrastructure. Coming up with a simple integration point so boost as a whole can be built with a single command, while its components can use either cmake or b2, shouldn't be any harder than the wholesale switch that is being proposed.

In the current monolithic structure of Boost, with some 130+ libraries being involved, it would lead to quite a problem for end-users if each library just did their own thing as regards how a library is built, tested, and documented.

Stefan

On 19/07/2017 03:01, Niall Douglas via Boost wrote:

...

There is no doubt that all SC members mean only good for Boost and C++ community, I know many of them as excellent developers who contributed a lot to Boost. However, other members of SC are not involved much, and some, including committee chair, do not seem to even have commit access to Boost. Again, I'm sure everybody meant only best, but something went wrong.

(and for your information, Jon does not have commit access to Boost **by choice** for various reasons not important to this thread. Not for any other reason, certainly nothing to do with lack of service to Boost)

I am sure everybody has good reasons, but of 9 members of SC, I can only find 4 in the list of GitHub project members, specifically Hartmut Kaiser, Louise Dionne, Michael Caisse and Sebastian Redl. I could not find 5 others. It is theoretically possible that I just did not recognize one of the people who do not use full name on GitHub, and it would be great if the Steering Committee either confirm or correct my numbers. However, if the numbers are accurate, it means that significant part of the SC, in fact majority, are not contributors to the project they intend to steer. That is very non-typical in volunteer open-source projects, and frankly I don't see why would an active developer take direction from such as committee or how such committee can make decisions on important matters. Build system question is not trivial, but it can be settled by a sufficiently motivated group of developers just doing a lot of work. There are other questions looming for a while that would require wide agreement, and it would be great for the future of Boost if those who write the code take matters in their hands, and not rely on committee of (mostly) by-standers to make a closed-door decision. Thanks, Volodya

On Tue, Jul 18, 2017 at 5:00 PM, Vladimir Prus via Boost < boost@lists.boost.org> wrote:

On 18/07/2017 16:12, Jon Kalb via Boost wrote:

...

Therefore, we, the Steering Committee, announce to the Boost community our

desire and intent to move Boost’s build system to CMake for users and developers alike.

I am obviously biased, so I won't comment on technical merits of this desire. Also, as usual in open-source, those who write the most code get to decide in the end.

However, I can't call this decision process anything but broken.

Since its founding, Boost was run by open discussions on a mailing list.

Yes, and this is as true today as it was before. Before the steering committee even looked at the CMake issue, there was a large mailing list discussion on moving to CMake. That discussion was started with the express intent to bring a proposal to the steering committee. None of this should be a surprise. Boost needs a steering committee to break stalemates and that is why it was created and exists today. The CMake issue has been around for years and hasn't been able to progress primarily because "obviously biased" vocal minorities were holding it back with threats. Rarely has there been an anti-CMake argument that suggested CMake would hurt Boost's mission. Enough is enough. "Finally" is the word I keep seeing over and over on the reddit discussion. There were people whose opinion carried a lot of weight, but that was

because they wrote a lot of high-quality code and expressed themselves clearly and openly. Today, we have Boost Steering Committee, whose members are elected not by developers or users of Boost through an open process, but through a closed process at a conference somewhere.

There is no doubt that all SC members mean only good for Boost and C++ community, I know many of them as excellent developers who contributed a lot to Boost. However, other members of SC are not involved much, and some, including committee chair, do not seem to even have commit access to Boost. Again, I'm sure everybody meant only best, but something went wrong.

Specifically, a committee that is not elected by Boost community and has members who never contributed any code met somewhere and made a vague decision that was poorly communicated and immediately cost the project a person who actually did a ton of work. I'm sure that a group elected by and from active developers would have done better at all fronts.

The steering committee was created to protect the mission of Boost. It is comprised of Boost developers, users, and leaders in the C++ community. Everyone on that committee is looking out for the best interests of Boost and is well qualified to do so. The decision to move to CMake was made unanimously.

I think that for future of Boost, it would be better if the Steering Committee immediately resign, and have an open election process for its replacement. Personally, I'll be happy to vote for many current members, but I feel that a governance based on open process will be better in the long run.

The steering committee is set up like many others in the Open Source world. People are chosen for various reasons but primary among them is their commitment to Boost's mission and doing what is right for Boost. This is how the founders set it up and how Boost ever switched to git. I'm sorry you and a couple others aren't happy with the decision made, but any decision in a deadlock situation is bound to disappoint someone. -- David Sankel

Le 19.07.17 à 14:27, Rene Rivera via Boost a écrit :

I hate getting into these kinds of arguments.. But this email is a bit too far for me to not respond.

On Wed, Jul 19, 2017 at 6:05 AM, David Sankel via Boost < boost@lists.boost.org> wrote:

...

Boost needs a steering committee to break stalemates and that is why it was created and exists today.

There was no stalemate. Almost every time cmake has been brought up there's been a discussion as to the merits of the build system and the impact on switching. Until now the SC never got involved.

...

The CMake issue has been around for years and hasn't been able to progress primarily because "obviously biased" vocal minorities were holding it back with threats.

No. There where never any threats. Only statements of what would happen. And you are obviously aware of this since you considered those repercussions when making the decision. So please apologize for the mischaracterization and close to slander of that statement.

...

Rarely has there been an anti-CMake argument that suggested CMake would hurt Boost's mission.

There has been that argument. As Boost's mission is impacted by the people that volunteer considerable resources to make it survive. Until now the argument has fallen to not move to cmake. Please search the archives for such evidence.

@Rene: I am fully backing you on this, Rene. My understanding of the cmake topic so far can be summarized like this: 1. Someone says: "cmake is cool, let's move to cmake! (smiley smiley)" 2. "ok, what do we need?" 3. "we need those features: [very ... very long list]" 4. "ok, who is doing what?" 5. Someone says: "I can pick the first two of that list" ... optionally later says, "we do not need the other features". 6. (some random time oblivion) 7. (void or close to it) 8. go back to 1. And I started subscribing to the list only in 2014. So now that there is an official statement from the Steering Committee, that is not only on which folder should receive the CMakeLists.txt, I am really wondering who will do what, and I am eager to see the final code. The cmake track has been enabled, now we need doers. Raffi PS: Of course, this post does not help anything, but I do not want Boost to be in the same spirit as GoT.

On 7/19/17 7:47 AM, Paul A. Bristow via Boost wrote:

To progress beyond statements of desire and intent, we need to have quite a lot of doers to convert some existing libraries to build using CMake. The subset including at least system, chrono and Boost.Test (used by nearly all libraries) for starters, and then at least a couple of BIG libraries.

FWIW - I've included CMakeLists.txt file in the serialization library for some years. I use it to build and test the serialization library. Actually I used it to build the IDE project which I can then use to build and test the serialization library. Which I believe qualifies as a BIG library. The reason I made this effort was that I like and depend upon the IDE for editing, testing, and working with integrated GIT functionality (I'm currently using Xcode). Before making the CMake files I had to maintain the IDE project by hand - not really a practical task. It was easier to figure out CMake - not a trivial task - than to figure out the xcode ide configuration. Here are some interesting points. a) It only builds and tests the serialization library. It doesn't provide the Find... functionality for users. As as library developer I don't really care about users (for all you sad humorless readers - that is a joke. It's depressing that I have to include this disclaimer.) But it's been there for years and no one has ever asked for this functionality. b) As far as I know, I'm the only person on the planet who has ever used this facility - even though it is plain to see for anyone interested. c) It wasn't that hard to setup and maintain - once you spend a non trivial amount of time learning to really understand CMake. Reading the comments on this lists make me think that many commentators have only a cursory knowledge of CMake. Like other build tools, it looks easy when you make a simple toy project - then you need something trivial that doesn't come out of the box (e.g. test compilation failure) you find that it's incredibly difficult and time consuming to add and the result is hacky and fragile and not really understandable. d) It does produce an acceptable project for my IDE. Anyone who is actually interested can use their copy of CMake to test this out by creating IDE project files for their own environment. Again, as far as I know I'm the only person (safe one other) who has ever done this. e) It depends on the rest of boost having been compiled to produce librarie which are consumable. These are built with the normal b2 system. Conclusion: This process doesn't have to be as traumatic as it's been made out to be. If promoters of CMake want to invest actual effort, they might provide tools/templates for doing this and let people start using them. If there is a need to force them, you've probably not got it right yet.

Doers? LOL - don't hold your breath

Paul

--- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

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

On 19/07/2017 16:33, Peter Dimov via Boost wrote:

Organizationally speaking, what needed to be done? First, we choose which scenario we prefer. Second, the SC appoints a person in charge of realizing the plan. If gradual, he sets off to work with the results immediately appearing in Boost as libraries are picked up by the CMake test/build infrastructure one by one. If sudden, he sets off to work on his branch. When ready, the SC votes on the switch.

So far I have left unspoken something that everyone should have picked up - the role of Rene in all this. It's patently obvious that a gradual transition would be much (much!) harder without him around, so we've pretty much ruled that possibility out now. This was, in my opinion, completely unnecessary.

Or was it?

...

The CMake issue has been around for years and hasn't been able to progress primarily because "obviously biased" vocal minorities were holding it back with threats.

To put it bluntly, did the glorious CMake transition HAVE to start with killing the workhorse and driving away the rider who got us where we are?

Thanks Peter. I think you've expressed very precisely what I (and maybe others) think. We want both Rene and Jon in Boost. Ion

There are two ways to do it. The first one is a gradual transition. We currently have two pieces of critical infrastructure reliant on Boost.Build - the test system and the build/install procedure. (Three actually if we include the doc build.)

How would a gradual transition work? For the testing part, obviously, we keep the Boost.Build testing operational and start building a parallel test infrastructure based on CMake/CTest. Libraries that want to be tested via b2 supply test/Jamfile, libraries that want to be tested via CTest supply... test/CMakeLists.txt, for instance. Libraries that supply neither aren't tested by either.

For the building part, we start supplying a secondary way to build and install Boost, alongside the existing one.

The second possibility is a sudden jump. We move, for both testing and building, to CMake at once.

I don't believe that can work: the CMake branch would never keep up with a constantly changing/evolving develop. Frankly unless there are a huge amount of resources (probably at least one full time developer keeping the CMake branch on track with develop), I see this as a non-starter. Remember this was in effect tried before, as I recall it failed because it just couldn't keep up despite Boost.Consulting's resources behind it. What might work, is a "lot of little bangs", moving one whole library at a time to CMake. My concern is that folks leave the difficult stuff to last, get bored, move on, and we're left stuck with a semi-working mess. Frankly, I simply do not know enough about CMake to know if this move is a good thing thing or not, but I am completely certain that there are a lot of folks greatly under-estimating the amount of work involved here. And now I'll go back to lurking again... John.

How would this be best handled? By building the CMake infrastructure on a branch until it's ready for the switch.

Organizationally speaking, what needed to be done? First, we choose which scenario we prefer. Second, the SC appoints a person in charge of realizing the plan. If gradual, he sets off to work with the results immediately appearing in Boost as libraries are picked up by the CMake test/build infrastructure one by one. If sudden, he sets off to work on his branch. When ready, the SC votes on the switch.

So far I have left unspoken something that everyone should have picked up - the role of Rene in all this. It's patently obvious that a gradual transition would be much (much!) harder without him around, so we've pretty much ruled that possibility out now. This was, in my opinion, completely unnecessary.

Or was it?

...

The CMake issue has been around for years and hasn't been able to progress primarily because "obviously biased" vocal minorities were holding it back with threats.

To put it bluntly, did the glorious CMake transition HAVE to start with killing the workhorse and driving away the rider who got us where we are?

And even if some of you believe that the answer to this question is "yes, it did have", can you not at least bring yourselves to not state that openly?

Boost.Build and Rene have done a lot for the C++ community. Unless and until you can match this track record...

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

--- This email has been checked for viruses by AVG. http://www.avg.com

Den 18-07-2017 kl. 23:00 skrev Vladimir Prus via Boost:

On 18/07/2017 16:12, Jon Kalb via Boost wrote:

...

Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike.

[snip]

However, I can't call this decision process anything but broken. Since its founding, Boost was run by open discussions on a mailing list.

Very broken if this is the way the SC is going to announce things. [snip]

There is no doubt that all SC members mean only good for Boost and C++ community,

I think they mean well, but one man's definition of "good" may not equal another man's. However, the lack of SC people actually participating in this thread is not a good sign. [snip]

I think that for future of Boost, it would be better if the Steering Committee immediately resign, and have an open election process for its replacement. Personally, I'll be happy to vote for many current members, but I feel that a governance based on open process will be better in the long run.

I don't know about that. The rules say: "[...] It is not the role of the Steering Committee to inhibit this kind of spontaneous leadership and action, which has served Boost and the wider C++ community so well. On the contrary, it is the role of the Steering Committee to facilitate community-based leadership and decision making. The role of the Committee is to be able to commit the organization to specific action either where funds are required or where consensus cannot be reached, but a decision must be made." Did we see any community-based leadership and decision making? How do one know/decide that a decision /must/ be made? kind regards Thorsten

On 7/20/2017 2:35 PM, Jared Grubb via Boost wrote: 2c:

Having the SC step in now was a good move. At some point, arguments like "tabs vs spaces" stop going anywhere because people dig in (often for good reasons, on both sides), and it's easy to stalemate -- although I think the community was moving towards cmake consensus naturally, based on the recent discussions.

Only a small part of the community engaged in that discussion. Some of us didn't bother to engage because our opinion was already being voiced by others. There was no vote across the developers or even the mailing list as a whole. There was just (yet another) random argument on the mailing list that carries no usable statistical information at all.

...

El jul. 18, 2017, a las 17:22, David Stone via Boost escribió:

...

From where I am sitting, CMake is the clear winner of the "build system war". Regardless of how you personally feel about the technical merits, it is hard to argue that Boost as a project and a community is not better off due to this change.

To some people, this seems out of the blue. To me, this seems inevitable. There have been many discussions on the Boost mailing list over the past months (years, even) about having CMake be a requirement for new libraries and using it as the default build system. We, as a community, pride ourselves on keeping up with modern software development practices. In C++, that increasingly means using CMake.

Technical merit is all that matters. We shouldn't be following the popular vote of the unwashed masses. Boost should be leading--which is really what Boost was about--not "reaching the most people."

...

If you imagine two possible futures: one in which Boost uses CMake as the build system and one in which it uses b2, which future do you imagine is better for Boost in the coming years?

What is better is for Boost to return to what it once was--a bastion of pioneering innovation that pushed the state of the art. That implies that "doing things the way everybody else does just because" is not an argument. Sadly, Boost appears to me to have progressively degenerated and is rapidly approaching mediocrity. CMake is just one more step in that direction. The SC can go ahead and implement everything themselves while all the people that did all the real work leave. What a colossal example of arrogance and overstepping. I agree with Vladimir Prus except that I wouldn't vote to reelect any of them--including those that have contributed to Boost. And, no, Niall, having done some good does not make someone above reproach. Regards, Paul Mensonides

The SC can go ahead and implement everything themselves while all the people that did all the real work leave. What a colossal example of arrogance and overstepping. I agree with Vladimir Prus except that I wouldn't vote to reelect any of them--including those that have contributed to Boost. And, no, Niall, having done some good does not make someone above reproach.

I have seen some enormously ignorant, petty and sanctimonious guff spoken here during this thread, sufficiently so that it makes Reddit look a positive bastion of enlightenment and positivity. It paints the Boost developer community in a sorry light, very sad. But I felt it was important for the SC to handle its own PR, so I have said nothing and will continue to do so. But as someone who has in the past strongly and repeatedly criticised the steering committee for doing no steering and being generally unfit for purpose, I now find myself morally obliged to defend it for doing some steering finally, especially as by making decisions which are actually controversial it is finally fit for purpose and demonstrates the long absent vigour finally returning to this community after nearly a decade of moribund, directionless stagnation. There are lots of good reasons why library developers should not be a majority on the steering committee, and hence are not: 1. Library developers see the world as a top 1% experienced elite C++ developer. They frequently, if not usually, fail to see that same world from the perspective of the 99% of everybody else, and often are *incapable* of seeing that same world from the perspective of the majority. Bjarne has often said publicly that Boost's biggest design flaw is how hard it is to get up and running with it quickly: - Why are top layer APIs riddled with templates instead of being hidden behind simplified convenience typedefs and non-template conventional OO class designs instead? - Why if most of the library is header only capable can't you just drop in a single header file and get to work? - Why is it acceptable for compile times to be so severely affected for end users? ... and the list goes on (more at http://www.stroustrup.com/bs_faq.html#boost). And how many times have I and other end users said the same now? Yet some library developers don't care: they want their cathedral pure and beautiful. And damn the end users if they are too stupid or ignorant to appreciate that cathedral in its untainted majesty. Well, that's just ignorant and self serving elitism. We can do a lot better, be friendlier, more welcoming, more inclusive, make things easier rather than harder for everybody else in C++. After all C++ is fighting for its life against the upstart systems languages, we don't have the luxury to being mean to end users anymore. A steering committee of non-Boost-developers stands a far better chance of seeing the bigger, wider, long term sustainable picture than individual library developers unwilling to look outside their own library's limited silo, and their own limited and narrow self interests. 2. Library developers tend to love coding, else they wouldn't have invested the many years of unpaid effort to get a library into Boost. As a general rule, but not always, people who love coding don't much like doing non-technical admin. It can be the case that people who don't much like doing non-technical admin don't realise how hard it is to be even reasonably competent at it, they think it surely must be easy to shepherd cats because people who do it tend to currently be paid less and have currently lower social status than they have. What they forget however is that shepherding cats, especially when you can't bribe them to behave with regular payments of money better known as "a salary", is extremely hard. *Far* harder than getting a library into Boost. And to be even remotely competent at it when you can't bribe people with "salary" is rare. Now Boost has been enormously fortunate to have the treasure which is Jon Kalb and the ecosystem of people around him which makes so much of Boost and C++ "just happen" without it being obviously made to happen. These people don't appear here, indeed most don't even subscribe to boost-dev because they are not library developers. But they are **just as important** to making Boost work and function as all the library developers and maintainers are. If they all quit, the website, mailing list, library releases, conferences, and **all your hard work on your library** stops happening. Moreover, **C++ itself** stops happening as a viable long term programming language. That means that the 10,000+ hours you've invested in your career and training becomes **worthless**. That eventually means dumping another 10,000+ hours into something else like Rust or Swift, but most of us aren't that young and free anymore. We're locked into C++. So stop dumping hate on the non-technical admin side of Boost and C++. If you have a problem with them, it's the same as library development: if you'd like the non-technical admin to be done differently, **volunteer** and join the small army who do the non-technical admin. Otherwise stop whining when they take decisions that you don't like. If you had taken any time to be familiar with what is discussed in the non-technical admin community, then this decision about cmake above was obviously coming over this past year. I was part of multiple off list discussions, and that was a small subset of the total ongoing. Indeed, it's why I've been so sweetness and nice here on boost-dev in the past year, I was finally seeing some movement on choosing a direction for Boost after many years of trying to no avail. So no longer any need to be nasty here anymore. And for the record, more controversial breaking change is coming. So don't be surprised when it lands. 3. Boost is very fortunate and unusual amongst open source projects to be very wealthy. They have more than enough money to employ contractors at US market day rates to implement a complete cmake transition in weeks if they so chose. However they do not wish to do that if it can at all be avoided. It is felt that a spontaneously designed and implemented cmake solution by the community for the community would be much better in terms of coming up with the right design, and generating buy in amongst a critical mass. Now I'll freely admit as a veteran contributor to the Boost git migration that I find that unrealistically naive. I think it can only work if you drop half the Boost libraries with more complex build needs from the distro, and as much as dropping half the libraries is something I personally want too, the problem is that those halves are not the same halves. I want the undermaintained half of libraries dropped, not the well maintained libraries with complex build needs. Anyway, I'm not on the SC, so I can't say what discussions have been happening off list about that. But I can say that there have been discussions, I have occasionally been looped in off list on specific points only. If the SC were all library developers, I think there would be a temptation to spend some of that cash pile on library development - I certainly would, but then I'm a library developer. I may not personally agree with the rationale to never spend money on development as has historically been held by the SC, but I do understand its logic: the money is there to lubricate and facilitate, not to drive development or admin itself. The current rough balance of half non-technical admin and half library developers on the Boost SC is probably therefore ideal, despite that from boost-dev's perspective the non-technical admin obviously contribute nothing useful. There will no doubt be lots of angry responses to this. And I apologise in advance to those on the SC that I promised I would not participate in this thread. But hey, you guys been taking a beating both here and on Reddit, and I know from off list discussions that it's gotten some of you very down. I want you to know that despite our past differences, I have your back. Breaking change is always unpopular, that's why it's so vital to do it regularly. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On 07/21/2017 01:41 PM, Niall Douglas via Boost wrote: <snip>

Bjarne has often said publicly that Boost's biggest design flaw is how hard it is to get up and running with it quickly:

- Why are top layer APIs riddled with templates instead of being hidden behind simplified convenience typedefs and non-template conventional OO class designs instead? - Why if most of the library is header only capable can't you just drop in a single header file and get to work? - Why is it acceptable for compile times to be so severely affected for end users?

... and the list goes on (more at http://www.stroustrup.com/bs_faq.html#boost). And how many times have I and other end users said the same now? Yet some library developers don't care: they want their cathedral pure and beautiful. And damn the end users if they are too stupid or ignorant to appreciate that cathedral in its untainted majesty.

Actually, there are exactly two items in your source: "- It is too hard to download and use just one Boost library; the libraries seem overly coupled making it hard to pick and choose. - Some of the libraries are too clever for my taste. Sometimes, generality and simplicity coincide; in Boost, the balance is IMO too often so far towards generality that novices and average users are lost." - Bjarne Stroustrup So much for that, if you cite someone, you should at least do it properly.

On 07/21/2017 02:12 PM, Niall Douglas via Boost wrote:

...

Actually, there are exactly two items in your source: "- It is too hard to download and use just one Boost library; the libraries seem overly coupled making it hard to pick and choose. - Some of the libraries are too clever for my taste. Sometimes, generality and simplicity coincide; in Boost, the balance is IMO too often so far towards generality that novices and average users are lost." - Bjarne Stroustrup

So much for that, if you cite someone, you should at least do it properly.

It wasn't a cited source, it was a link to more detail. I was citing Bjarne's public comments on Boost in interviews, in his conference talks as well as his website. His opinion regarding Boost is very well known.

Obviously you know more than I do. Do you mind sharing those interviews/comments and/or recorded talk?

Niall

The problem might be that if you don't involve the developers, they get very offended, and for good reasons.

As no less than two members of the SC have already said here in this thread, boost-dev was consulted and in depth, with at least three boost-dev members proposing technical cmake solution prototypes for the SC to consider. The same old arguments were made, nothing new over previous discussions of the merits or non-merits of cmake vs boost.build were advanced. The SC therefore decided that this decision was making no progress due to stalemate, and enforced a decision. You probably wanted some big banner in the Subject line like "IF YOU DON'T SPEAK NOW THEN CMAKE IS HAPPENING". But the way that the SC was originally set up doesn't allow that to happen. Nobody from the SC can claim that the SC will take some action until they *have* taken some action, and they can't take an action until a *formal* written proposal has been laid before them to vote upon. Formal written proposals land before the SC to vote on all the time. Some are rejected, some approved. I've written a few myself, but not recently as I am winding down my involvement with Boost.

...

If you had taken any time to be familiar with what is discussed in the non-technical admin community, then this decision about cmake above was obviously coming over this past year. I was part of multiple off list discussions, and that was a small subset of the total ongoing. Indeed, it's why I've been so sweetness and nice here on boost-dev in the past year, I was finally seeing some movement on choosing a direction for Boost after many years of trying to no avail. So no longer any need to be nasty here anymore. And for the record, more controversial breaking change is coming. So don't be surprised when it lands.

Huh? More announcements of decisions behind closed doors without list discussions?

All stakeholders involved in the cmake decision were consulted in depth and many weeks in advance. There was nothing closed door about it. Search the boost-dev archives, it's there.

Look, everybody here would like Boost to be easier to consume for end users. But that's a goal that needs a plan and means and feasibility studies. Secondary, should we abandon boost.build internally? That's a different thing entirely.

I hope the SC realize how damaging their actions are.

You all should read the announcement again. The only decision enforced was that cmake is going to happen. Nothing was said about form, design, process, timetable, or anything else. Nothing was said about removing Boost.Build either. Quite frankly the reaction here was way overblown to what had happened. But then if you don't maintain a steady beat of breaking change, people way overreact when it comes. And we haven't had a breaking change here since the git migration five years ago. And that was *awful*. So far, this is going better. Long may it continue. Nothing in any of this reply has not already been previously said on this thread by SC members. I am, quite literally, repeating what they already have said here, despite that I am not a member of the SC. I just pay attention to what people write on boost-dev. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Niall Douglas via Boost Sent: 21 July 2017 12:41 To: boost@lists.boost.org Cc: Niall Douglas Subject: Re: [boost] CMake Announcement from Boost Steering Committee

<snip>

3. Boost is very fortunate and unusual amongst open source projects to be very wealthy. They have more than enough money to employ contractors at US market day rates to implement a complete cmake transition in weeks if they so chose.

However they do not wish to do that if it can at all be avoided. It is felt that a spontaneously designed and implemented cmake solution by the community for the community would be much better in terms of coming up with the right design, and generating buy in amongst a critical mass.

Nobody has yet stepped up to do this :-( So are the Steering Committee now going to put money into actually implementing Boost/CMake? (And I trust that means converting the working bjam/b2 jamfiles fully for all libraries, not just the simple ones. I'd strongly opposed to ditching libraries just because their build is troublesome for CMake). Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

On 18 July 2017 at 16:59, Rene Rivera via Boost wrote:

On Tue, Jul 18, 2017 at 8:15 AM, Rene Rivera wrote:

...

As a consequence.. I herby resign from all my duties in the Boost community effectively immediately. This means that I will no longer be in the Release Team.

Since none of the current Boost Steering Committee members are owners in the Github Boost.ORG organization.. Could one of the github owners please change my role from "owner" to "member"? (github doesn't allow you to do that to yourself).

Done. I'm very sorry that to see you resign, especially under these circumstances. Thanks for all you've contributed over the years.

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Thorsten Ottosen via Boost Sent: 24 July 2017 10:14 To: boost@lists.boost.org Cc: Thorsten Ottosen Subject: Re: [boost] CMake Announcement from Boost Steering Committee

Den 21-07-2017 kl. 18:23 skrev Daniel James via Boost:

...

On 18 July 2017 at 16:59, Rene Rivera via Boost wrote:

...

On Tue, Jul 18, 2017 at 8:15 AM, Rene Rivera wrote:

...

As a consequence.. I herby resign from all my duties in the Boost

[snip]

...

Done. I'm very sorry that to see you resign, especially under these circumstances. Thanks for all you've contributed over the years.

+1 Your abrupt departure is quite understandable (and most regrettable). To me, the trigger for it was most tactless. Moving to CMake will be much harder without your help, even if given reluctantly. Very, very many thanks for all your hard and invaluable work over so many years. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

Niall Douglas wrote:

...

...

Well, that's just ignorant and self serving elitism.

...

Remarkable how much this ignorant and self-serving elitism could do for the C++ community over the years. Surely by accident or by mistake.

Some would say that what has been achieved so far is a pale shadow of what would have been achieved without the self-serving elitism.

Indeed they would. And the best thing about saying it is that it's unfalsifiable. If only Boost were what you think it should have been, it would have been at least 118% more successful. Hypotheticals aside, here in the real world we only have actual observable results on which to base our conclusions.

On 7/21/17 1:50 PM, Niall Douglas via Boost wrote:

On 21/07/2017 16:55, Peter Dimov via Boost wrote:

...

Niall Douglas wrote:

...

Well, that's just ignorant and self serving elitism.

Remarkable how much this ignorant and self-serving elitism could do for the C++ community over the years. Surely by accident or by mistake.

Some would say that what has been achieved so far is a pale shadow of what would have been achieved without the self-serving elitism. If you look at the bits of Boost which got into the C++ standard, they are very obviously the simple bits. There's a lesson in that.

...

...

A steering committee of non-Boost-developers stands a far better chance of...

... changing Boost into non-Boost, because everyone feels the need to remake things that are alien to him in his own image.

Boost has been created and has been maintained (not just in a technical sense) by developers, and what it is today reflects it. A steering committee of non-Boost-developers is capable of producing something good, but this good thing will no longer be Boost, except by name.

No, Boost has been created and has been maintained and funded by its three main stakeholders, only one of which is Boost library developers.

Right - but that stakeholder does 99% of the actual work.

Boost library developers are a quarter to a third of that stakeholdership

where does one get such numbers? We don't any statistics on library usage. This goes not only for boost but for libraries std, CGal, etc. Sure we might have downloads (even that is suspect), but I'd be wary of citing such numbers - much less drawing conclusions from them.

- important, sure, but not a majority like they think they are. A big stakeholder is the user base, most of whom are thrilled with this decision,

right - but they don't do any actual work.

mostly by its symbolic significance rather than any love of cmake. The other big stakeholder is the C++ leadership and WG21, most of whom are also pleased with this decision

LOL - I don't see how anyone can know that.

as it suggests Boost may yet have some relevance as a standards incubator into the future.

Now, none of the above will be popular things to say on boost-dev, there is a widespread belief here that Boost can't exist without the library developers

LOL that is true by definition

and that's all that matters. But equally, Boost can't exist without the C++ ecosystem either, nor can it exist without the people who behind the scenes make the mailing list, website, servers and financial accounts all work.

I don't think these players have a big stake in he build system.

And call me old fashioned, but Boost can't exist without users using it either.

Again trivially true.

Anyone can build a marvelous cathedral. But what's the point if nobody ever marvels at it because nobody ever uses it? I really think that top quality libraries can never be truly top quality unless there is a significant, large, enthusiastic user base for them who finds them amazing. Bigger the better. You need to *know* your cathedral is marvelous through userbase, not just believe it personally.

Right - and we have absolutly no numbers or data on library usage - boost or otherwise

I *definitely* don't think libraries should be standardised without that for sure, and remember Boost was originally set up as an incubator for libraries to be standardised. The end users are in my belief the most important and biggest stakeholder of all. We need to do a lot better by them than we have.

Hmmm - My sense is that we've been doing better than everyone else out there. But again, it's just my sense given the incorporation of so many boost libaries into the standard. I (and no one else) really knows about this. I'm guessing that one reason the discussion is so contentious is the actual lack of factual information involved in it. Robert Ramey

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Jared Grubb via Boost Sent: 20 July 2017 22:35 To: Boost Developers List Cc: Jared Grubb; Jon Kalb Subject: Re: [boost] CMake Announcement from Boost Steering Committee

+1000. I think you summed up my feelings as well.

Having the SC step in now was a good move. At some point, arguments like "tabs vs spaces" stop going anywhere because people dig in (often for good reasons, on both sides), and it's easy to stalemate -- although I think the community was moving towards cmake consensus naturally, based on the recent discussions.

Nobody has been maintaining that there are more potential users of Boost who wish to use CMake.

This decision lets us get past the distraction of arguing what's best and move on to what really matters: How to get there.

The mailing list has recently been focussing on just that - the *how*. The *how* is looking feasible, but the *who* remains entirely unclear. So the Steering isn't going to happen without an engine of some expert volunteers with enthusiasm and time. I ask again ... who? Paul PS Especially as our most valuable packhorse has bolted in fright ;-) --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

On Fri, Jul 21, 2017 at 7:25 AM, Roger Leigh via Boost wrote:

Could I also point to this block in https://gitlab.kitware.com/cmake/cmake/blob/master/Modules/FindBoost.cmake#L... ... *We* pay the cost of this significant defect in the Boost project in the form of a high maintenance burden and breakage with every new Boost release.

I'm new but I am in agreement that whatever is needed to make this work should be part of Boost not CMake, since Boost has the expertise to produce accurate information. Placing the burden on CMake is clearly not scalable. I propose that the Steering Committee take a break from causing unnecessary drama and instead focus on this one particular use-case. I realize it is not the "Full Monte" but its something (10 year old ticket anyone?) and I think would heal the recently caused divisions. Thanks

On Fri, Jul 21, 2017 at 9:25 AM, Roger Leigh via Boost < boost@lists.boost.org> wrote:

On 2017-07-21 09:30, Paul A. Bristow via Boost wrote:

...

The mailing list has recently been focussing on just that - the *how*.

The *how* is looking feasible, but the *who* remains entirely unclear.

So the Steering isn't going to happen without an engine of some expert volunteers with enthusiasm and time.

I ask again ... who?

If you would like volunteers to do this, can I sign up to assist? I've been keen on being able to build Boost with CMake for years, but didn't get involved due to not being a core Boost person, just an end user, and also because it looked like there were also a bunch of keen people already working on it. But if you want additional people on board, I'd be happy to contribute in whatever way I can.

Thanks, Roger. I think a reasonable first effort is to suggest one or more concrete ways forward, like Perter Dimov did a couple of weeks ago. He had example CMake code for people to play with and review, and it sounds like you're quite qualified to do the same. There's been a lot of discussion in the last few days about the manner in which all this has been presented. IMO, what we need now is more concrete and technical efforts. Others may disagree. :) [snip] Could I also point to the lengths I have to go to to build Boost as part of

a larger project:

[snip] I've encountered lots of issues along these lines over the years. This sort of thing is why those of us who support CMake are for it.

I hope the above isn't too upsetting or controversial. I wanted to provide some perspective from the point of view of an outsider and end user, and potential contributor, about what things are like from the other side.

I much appreciate this. Zach

Roger Leigh wrote:

This is what we do in the absence of proper dependency information being provided by Boost, i.e. no pkg-config, cmake config or similar. We hard-code *every* *single* *dependency* from 1.33 up to 1.64 at the time of writing.

Why didn't you ask here for us to include dependency information into the release? http://www.boost.org/doc/libs/master/tools/boostdep/doc/html/ can do all sorts of dependency reports and I'm actively maintaining it, I've recently even added a cmake-specific output as I needed that to generate the -config files.

On 22/07/17 11:47, Peter Dimov via Boost wrote:

...

Roger Leigh wrote:

...

This is what we do in the absence of proper dependency information being > provided by Boost, i.e. no pkg-config, cmake config or similar. We > hard-code *every* *single* *dependency* from 1.33 up to 1.64 at the time > of writing.

Why didn't you ask here for us to include dependency information into the release?

http://www.boost.org/doc/libs/master/tools/boostdep/doc/html/ can do all sorts of dependency reports and I'm actively maintaining it, I've recently even added a cmake-specific output as I needed that to generate the -config files.

This is a serious question, Roger. I'm not trolling you or something.

We obviously can't roll back time so this is water under the bridge, but I'm still interested in your answer. You can be as blunt or explicit as you like.

Terrible to say, but my memory is failing me, and I can't remember! I'm pretty sure I did look at it, but there was some reason why I didn't find it a match for FindBoost's needs at the time, but I can't recall the specifics. I ended up writing this; it's in a CMake script, so it's a bit verbose: https://gitlab.kitware.com/cmake/cmake/blob/master/Utilities/Scripts/BoostSc... One thing the script does to is special-case a number of situations where a header of one component is actually a separate component in its own right, mainly related to python, mpi and serialization. It's also special-cases the zlib/bzip2 autolink stuff so we don't use the windows-specific data on other platforms. These might have been part of the reason, but I'm not entirely certain. Again not remembering exactly, but the mappings we have in FindBoost right now are not exactly boost component interdependencies but shared/static library interdependencies only, based on the autolink data. That might also have been part of the reason. I'd expect that with Boost providing per-component configuration files, this could be greatly improved to cover every component irrespective of whether or not it provides a library (or libraries).

Similarly, the pkg-config one. I'm genuinely interested in how pkg-config support, if we have it, is supposed to handle multiple build variants having been installed.

I've already solved that for the cmake -config files, but I'm not sure I see a way for pkg-config to support it.

It's been a while since I looked at this, but my understanding is that it can't by design. You have one variant installed, with a matching set of pkg-config files which point to those libraries. If you need multiple variants, you need to install each variant into a separate prefix and then configure pkg-config (via an environment variable) to search the desired prefix. This is a case where Boost's policy of appending all of the toolset/configuration/threading model etc. to the library name is somewhat unique and, and generally incompatible with how the rest of the world works. In general, I've found it a hindrance to interoperability, and solving a problem which I didn't have in the first place. No one else does it, and there's likely a good reason for that! At most, I add a 'd' debug postfix on Windows, and that's it (this is handled by CMake as a standard behaviour). If I need multiple configurations, I build them separately and explicitly; I don't expect it of the build system itself. Regards, Roger

This is a case where Boost's policy of appending all of the toolset/configuration/threading model etc. to the library name is somewhat unique and, and generally incompatible with how the rest of the world works. In general, I've found it a hindrance to interoperability, and solving a problem which I didn't have in the first place. No one else does it, and there's likely a good reason for that! At most, I add a 'd' debug postfix on Windows, and that's it (this is handled by CMake as a standard behaviour). If I need multiple configurations, I build them separately and explicitly; I don't expect it of the build system itself.

I had a feeling this would come up, and as the instigator of this let me explain how/why it happened. A very long time ago, before Boost as it happens, I had a toy C++ regex library, I released it to the world and it got some exposure and feedback. However, I was getting about 1 support request a week from folks who were linking regex built one way to an application built in some binary incompatible way (this is with Visual Studio). Now that's a lot of support requests for a library that had only limited exposure pre-boost, pre-github, and yes, pre-sourceforge too. I dread to think how many support requests it would generate now, had this issue not been solved via name mangling and auto-linking when using Visual Studio. It means it "just works" on a platform that has a multitude of different compiler runtimes, all binary-incompatible with each other. Sorry, but a simple "d" suffix on Windows doesn't even begin to cover the whole heap of pain that results from doing this wrong. { Aside 1: If I were forced kicking and screaming to abandon the name mangling, then mangling the library namespace would mitigate this somewhat, but not enough IMO. Aside 2: If the VS CMake generated files were good enough, then the canonical way of using Boost under Visual Studio would be to reference our project files from your applications solution. Then the libraries your using would always be built with the same options that you're using in your project.... well nearly, this actually requires quite a bit of manual intervention to set the properties of every dependent library the same, plus a fair proportion of VS developers seem not to know how to reference an external library from their IDE anyway :( } In short, I simply can't express how much easier name mangling makes the developers life. I can of course see that on other platforms, this makes no sense at all, and assuming there is "one true version" makes perfect sense. Best, John. --- This email has been checked for viruses by AVG. http://www.avg.com

On 7/22/2017 8:10 PM, P F via Boost wrote:

...

On Jul 22, 2017, at 7:25 AM, John Maddock via Boost wrote:

...

This is a case where Boost's policy of appending all of the toolset/configuration/threading model etc. to the library name is somewhat unique and, and generally incompatible with how the rest of the world works. In general, I've found it a hindrance to interoperability, and solving a problem which I didn't have in the first place. No one else does it, and there's likely a good reason for that! At most, I add a 'd' debug postfix on Windows, and that's it (this is handled by CMake as a standard behaviour). If I need multiple configurations, I build them separately and explicitly; I don't expect it of the build system itself.

I had a feeling this would come up, and as the instigator of this let me explain how/why it happened.

A very long time ago, before Boost as it happens, I had a toy C++ regex library, I released it to the world and it got some exposure and feedback. However, I was getting about 1 support request a week from folks who were linking regex built one way to an application built in some binary incompatible way (this is with Visual Studio). Now that's a lot of support requests for a library that had only limited exposure pre-boost, pre-github, and yes, pre-sourceforge too. I dread to think how many support requests it would generate now, had this issue not been solved via name mangling and auto-linking when using Visual Studio. It means it "just works" on a platform that has a multitude of different compiler runtimes, all binary-incompatible with each other. Sorry, but a simple "d" suffix on Windows doesn't even begin to cover the whole heap of pain that results from doing this wrong.

I am very thankful for your work. When I use b2 to create the complete Boost install output files, I simply have one output directory for all 32-bit and a second directory for all 64-bit files. The Intel and Visual Studio versions, thanks to containing specific Boost release numbers live together without any issues. Has this use case been considered for a Cmake based build?

Cmake generates checks for 64/32 in the version config files. So that when using `find_package(lib)` it will pick the correct binary if available. Also, I believe it will also distinguish binaries in multi-configation builds like VS which can build both debug and release.

For a Cmake output on Windows for both Visual Studio and Intel C++, 32 and 64-bit architectures, would it produce the correct name mangled output files? Would the 'find_package(lib)' have a chance to correctly find the Intel and Visual Studio versions as separate files?

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

Niall Douglas wrote:

As I already mentioned in another post, specifying the entire configuration in the target name is exactly the right way to implement modern cmake 3.

Wouldn't this, if taken to its logical conclusion, amount to a (poor?) reimplementation of Boost.Build in CMake? I mean, once you have target-<variant>debug-<link>static that's pretty much what it is.

Niall Douglas wrote:

...

...

As I already mentioned in another post, specifying the entire configuration in the target name is exactly the right way to implement modern cmake 3.

Wouldn't this, if taken to its logical conclusion, amount to a (poor?) reimplementation of Boost.Build in CMake? I mean, once you have target-<variant>debug-<link>static that's pretty much what it is.

Why fix something that's broke? Closely replicating the Boost.Build design will make replacing Boost.Build with cmake so much easier. All the dependent tooling etc will "just work".

Besides, John Maddock is 100% right that ABI requirements ought to be encoded into the shared library name. Saves so much time and hassle and confusion, plus consumers can easily REGEX out the link requirements if needed.

...

So, all in all, very like Boost.Build currently does. And that's because it's the correct design and approach to take. So we should do that in any cmake of Boost too.

I'm not necessarily arguing against that approach, but after having heard many (both over the years, and recently) argue that CMake's "one build directory per configuration" philosophy is better than Boost.Build's multiconfig philosophy, it's amusing to see you suggest that idiomatic and modern CMake 3 is a reinvention of Boost.Build. :-)

On 23/07/17 11:42, Niall Douglas via Boost wrote:

...

...

As I already mentioned in another post, specifying the entire configuration in the target name is exactly the right way to implement modern cmake 3.

Wouldn't this, if taken to its logical conclusion, amount to a (poor?) reimplementation of Boost.Build in CMake? I mean, once you have target-<variant>debug-<link>static that's pretty much what it is.

Why fix something that's broke? Closely replicating the Boost.Build design will make replacing Boost.Build with cmake so much easier. All the dependent tooling etc will "just work".

I have to strongly disagree here. It's not about being "broken", it's about being non-standard and overly-complicated for marginal benefit. This pushes an additional burden on end users of Boost to somehow know in advance which bits are encoded in the library names; it's a terrible requirement to impose on others. This forces every end user to provide some mapping from their own build logic to the names used by Boost for encoding each component of the configuration suffix, and then hope that the system provides that. Consider just how costly and painful this truly is. I've suffered from this in the past trying to use Boost with the autotools on Linux. Debian used to use suffixes for single- and multi-threaded. So what do I do, search for the -st and -mt suffixes and also unsuffixed? Or hardcode the one I expect, complicated by the provided names changing over time? I went with the latter, only to have it fail to build on other systems with different names in use, to then try to autodetect all the variants only to still have people complain it still fails because there's some other variant I didn't cater for. And this was just for a single suffix variant. Thankfully, most Linux distributions later dropped all the suffixes. This policy forces every consumer to need to reimplement a good chunk of logic to determine what name might be in use. And I say might, because it's essentially an unrewarding guessing game. And every failure is an example of compromised portability of other people's codebases caused by this policy. One of the reasons I switched to using CMake was that FindBoost.cmake encoded most of the esoteric rules used in the naming conventions and plays the guessing game really well. It usually finds the right answer. But that's ~2000 lines of nastiness which I have to maintain, and the rules keep changing with each Boost release. If you're not using CMake, and you can't hardcode some specific variant, you have to pay some of this cost as well; multiply that by each independent downstream use of Boost. Is that cost acceptable? The suggestion in another post that some of this stuff could be encoded in the pkg-config names is also subject to this problem. It again pushes a burden onto every single consumer of the boost libraries, which in my opinion is quite unacceptable. It also kind of defeats the point of using pkg-config in the first place. It's whole purpose is to answer the simple question: what do I need to compile and link with X, and if that's not handled, it's failed.

Besides, John Maddock is 100% right that ABI requirements ought to be encoded into the shared library name. Saves so much time and hassle and confusion, plus consumers can easily REGEX out the link requirements if needed.

In my experience as an end user of Boost, it only *adds* time, hassle and confusion. I want to link with a specific library, and I don't want this obfuscated unnecessarily.

Here are the cmake targets which my quickcpplib tooling autogenerates for AFIO v2 based on inspection of the environment (apologies for the long list in advance): [...] ... and <special> is anything affecting the link requirements of the binary, so here QuickCppLib auto detected the code sanitisers asan,msan,tsan,ubsan all of which require to be linked like-with-like, and hence needed a separate <special> category.

Group-level targets also exist, so "afio_sl-tsan" means "all the static library AFIO targets with Thread Sanitiser", "_tsan" means "all the targets with Thread Sanitiser" and so on.

The above is just the mangling for cmake targets which must always be unique within a given cmake build else cmake will refuse to work, hence mangling systematically according to a strict REGEX pattern makes a ton of sense (and using TARGET ALIAS to a more convenient to type target name like "boost::afio").

The actual binaries generated by the build are further mangled again according to this REGEXable pattern:

Apologies for saying this, but this is truly horrific. None of that belongs in a CMake build. One of the benefits of using a standard build system, be it the GNU Autotools, CMake, Maven or something else is that they provide standard ways of doing things. This starts with common command-line options and configurable properties, to build targets and behaviour. This makes the build of one project accessible to others for both development and end use because it uses the same conventions that all the other projects using the build system adhere to. That is to say, there are certain basic expectations of what the system will provide and how it will behave. While it's certainly possible with CMake to deviate from the default behaviour, this breaks a whole lot of those expectations, and significantly complicates and devalues what CMake provides for us. The key disagreement here is that there are two ways of doing things: - Running a build and having it produce multiple builds of the same library, with the configuration details encoded in the name, which may be installed alongside each other. You need to know the specific variant name to link with it. - Running a build with a specific configuration and having it product a single library with a plain name; you need to run multiple separate builds with separate install prefixes to build multiple combinations. You don't need to know the variant name to link with it, but you do need to know the path to the variant you want. The former is what Boost.Build provides. The latter is what the GNU Autotools, CMake and pretty much every one else provides. Boost is the exception here. Pretty much every project I've ever come across does the latter. While I can see the reasons why the Boost conventions were established, I don't agree that they are the ideal solution or that they have value for the general case; there is also value in behaving the same as the rest of the world for ease of interoperability and use. For example, I manage just fine for all my work projects by having the automated CI system doing builds for n configuration variants and packaging up artefacts for each of the n variants for Windows, and also for all the other platforms I support. Also, in the Linux world, look at the biarch and multiarch layouts. Here's multiarch on Ubuntu 17.04: /usr/lib/x86_64-linux-gnu/libtiff.so.5.2.5 /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.62.0 the processor type and system are encoded in the lib path. None of it required any special manging of the library names; I can link with -ltiff or -lboost_filesystem and it will just work. You can also use paths on Windows in exactly the same manner for build variants, again with no name mangling. I would suggest that the CMake build for Boost should do things following the standard practices for CMake, and be as simple as possible. Regards, Roger

On Jul 23, 2017, at 5:23 PM, Niall Douglas via Boost wrote:

...

I would suggest that the CMake build for Boost should do things following the standard practices for CMake, and be as simple as possible.

I appreciate everything you've just said and the time you took to say it. But quite frankly, you're plain wrong:

1. The mangling pattern should be published with a formal regex for parsing it. It should never, ever change.

2. cmake lets external cmake override binary naming arbitrarily, so if you really want the binary to be called foo.so, you can go ahead and do that no problem because you know the mangling of the cmake target names, so you know which target sets to set properties for.

3. If you're working outside of cmake, cmake export writes config files which are of stable layout and which can be easily regex scanned for the name of the binary you need. Any bit of scripting can do this, even Windows batch. I've done this countless times, it's a really nice feature of cmake.

So everything you just said is all irrelevant. Meanwhile, there are *enormous* end user gains to mangling the binary name.

Then why does no linux distro do this? Even when they support compiling for multiple platforms. I think the standard way is to use separate directories instead of using encoded name, which is very much relevant and current practice.

...

So everything you just said is all irrelevant. Meanwhile, there are *enormous* end user gains to mangling the binary name.

Then why does no linux distro do this? Even when they support compiling for multiple platforms. I think the standard way is to use separate directories instead of using encoded name, which is very much relevant and current practice.

Different audiences. Note I have little problem with the boost release zip of precompiled binaries not having mangled names, though I still think it better-safe-than-sorry. For the same reason, a linux package repo need not go mad mangling library names. They control the build config used end-to-end, and end users are rarely going to combine binaries in accidentally stupid ways. But for developers needing to test just compiled binaries in various combinations and configurations, name mangling is an unalloyed win. As I mentioned, I only just shot myself in the foot with this last week because I wasn't mangling the true compiler compiling the binaries into the library names on Windows. So I'd be entirely happy if staging directory had mangled names, and install directory had unmangled names. If that was felt important. Personally speaking, I think there is more than enough work in a cmake conversion without deliberately making more work for yourself unnecessarily. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On 24/07/2017 13:20, Olaf van der Spek wrote:

On Mon, Jul 24, 2017 at 2:12 PM, Niall Douglas via Boost wrote:

...

...

...

So everything you just said is all irrelevant. Meanwhile, there are *enormous* end user gains to mangling the binary name.

Then why does no linux distro do this? Even when they support compiling for multiple platforms. I think the standard way is to use separate directories instead of using encoded name, which is very much relevant and current practice.

Different audiences.

Note I have little problem with the boost release zip of precompiled binaries not having mangled names, though I still think it

How'd you handle Debug vs Release mode on Windows?

Well, Windows is an outlier in that you can't safely mix debug and release CRTs. As I mentioned, me personally I'd ship the name mangled versions always. I've found it leads to less surprise. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On Mon, Jul 24, 2017 at 2:28 PM, Niall Douglas via Boost wrote:

On 24/07/2017 13:20, Olaf van der Spek wrote:

...

On Mon, Jul 24, 2017 at 2:12 PM, Niall Douglas via Boost wrote:

...

...

...

So everything you just said is all irrelevant. Meanwhile, there are *enormous* end user gains to mangling the binary name.

Then why does no linux distro do this? Even when they support compiling for multiple platforms. I think the standard way is to use separate directories instead of using encoded name, which is very much relevant and current practice.

Different audiences.

Note I have little problem with the boost release zip of precompiled binaries not having mangled names, though I still think it

How'd you handle Debug vs Release mode on Windows?

Well, Windows is an outlier in that you can't safely mix debug and release CRTs.

So what do you propose? Not supporting Windows?

As I mentioned, me personally I'd ship the name mangled versions always. I've found it leads to less surprise.

I agree -- Olaf

On 24/07/2017 10:23, Niall Douglas wrote:

So everything you just said is all irrelevant. Meanwhile, there are *enormous* end user gains to mangling the binary name. Even I who has been at this game twenty plus years now I still accidentally link a binary compiled one way with binaries compiled an incompatible way, and then spent hours - occasionally days - scratching my head as to what is wrong. Indeed it only happened to me again a few days ago where I mixed a clang LLVM compiled binary with a MSVC compiled binary. Bad idea.

Name mangling of library outputs is a universal good. It's why Boost does it, and any sane cmake does it. After all, why else has cmake generator expression support for name mangling? And if you're not doing it where you code, with respect I suggest you need a ton load more automated tooling deployed where you work, because you obviously are not doing enough testing or the right testing.

FWIW, for Windows compiles I use auto-linking, and then have a script examine the import table of the resulting binaries to extract the names of the libraries thus auto-linked-to in order to determine which DLLs need to be included in installation scripts and the like. So it's basically all automatic and I don't really ever need to care what the libraries are called, as long as they *do* have mangled names (and thus alternate versions can co-exist in the same target folder). Linux is actually a little more painful, because it doesn't have auto-linking and none of its auto-naming conventions really fit what's really important. Generally speaking Linux is a bit less picky about linking modules built with different compilers or different versions together -- up to a point, that point being which libc gets linked in. But there isn't an option to mangle the name based on the libc version, just the compiler version.

On 24/07/2017 01:19, P F via Boost wrote:

...

On Jul 23, 2017, at 5:42 AM, Niall Douglas via Boost wrote:

...

...

As I already mentioned in another post, specifying the entire configuration in the target name is exactly the right way to implement modern cmake 3. Wouldn't this, if taken to its logical conclusion, amount to a (poor?) reimplementation of Boost.Build in CMake? I mean, once you have target-<variant>debug-<link>static that's pretty much what it is. Why fix something that's broke? Closely replicating the Boost.Build design will make replacing Boost.Build with cmake so much easier. All the dependent tooling etc will "just work".

Besides, John Maddock is 100% right that ABI requirements ought to be encoded into the shared library name. Saves so much time and hassle and confusion, plus consumers can easily REGEX out the link requirements if needed.

Here are the cmake targets which my quickcpplib tooling autogenerates for AFIO v2 based on inspection of the environment (apologies for the long list in advance):

``` ned@lyta:~/windocs/boostish/afio/build_posix$ make help | sort ... afio-asan ... afio_dl ... afio_dl-asan ... afio_dl-asan-atuple ... afio_dl-asan-coverage_main ... afio_dl-asan-execinfo_win64 ... afio_dl-asan-file_handle_create_close ... afio_dl-asan-file_handle_lock_unlock ... afio_dl-asan-map_handle_create_close ... afio_dl-asan-open_hash_index ... afio_dl-asan-packed_backtrace ... afio_dl-asan-ringbuffer_log ... afio_dl-asan-section_handle_create_close ... afio_dl-asan-shared_fs_mutex ... afio_dl-asan-spinlock_tribool ... afio_dl-asan-test_guard ... afio_dl-asan-test_import ... afio_dl-asan-test_message ... afio_dl-asan-type_traits ... afio_dl--atuple ... afio_dl--coverage_main ... afio_dl--execinfo_win64 ... afio_dl--file_handle_create_close ... afio_dl--file_handle_lock_unlock ... afio_dl--map_handle_create_close ... afio_dl-msan ... afio_dl-msan-atuple ... afio_dl-msan-coverage_main ... afio_dl-msan-execinfo_win64 ... afio_dl-msan-file_handle_create_close ... afio_dl-msan-file_handle_lock_unlock ... afio_dl-msan-map_handle_create_close ... afio_dl-msan-open_hash_index ... afio_dl-msan-packed_backtrace ... afio_dl-msan-ringbuffer_log ... afio_dl-msan-section_handle_create_close ... afio_dl-msan-shared_fs_mutex ... afio_dl-msan-spinlock_tribool ... afio_dl-msan-test_guard ... afio_dl-msan-test_import ... afio_dl-msan-test_message ... afio_dl-msan-type_traits ... afio_dl--open_hash_index ... afio_dl--packed_backtrace ... afio_dl--ringbuffer_log ... afio_dl--section_handle_create_close ... afio_dl--shared_fs_mutex ... afio_dl--spinlock_tribool ... afio_dl--test_guard ... afio_dl--test_import ... afio_dl--test_message ... afio_dl-tsan ... afio_dl-tsan-atuple ... afio_dl-tsan-coverage_main ... afio_dl-tsan-execinfo_win64 ... afio_dl-tsan-file_handle_create_close ... afio_dl-tsan-file_handle_lock_unlock ... afio_dl-tsan-map_handle_create_close ... afio_dl-tsan-open_hash_index ... afio_dl-tsan-packed_backtrace ... afio_dl-tsan-ringbuffer_log ... afio_dl-tsan-section_handle_create_close ... afio_dl-tsan-shared_fs_mutex ... afio_dl-tsan-spinlock_tribool ... afio_dl-tsan-test_guard ... afio_dl-tsan-test_import ... afio_dl-tsan-test_message ... afio_dl-tsan-type_traits ... afio_dl--type_traits ... afio_dl-ubsan ... afio_dl-ubsan-atuple ... afio_dl-ubsan-coverage_main ... afio_dl-ubsan-execinfo_win64 ... afio_dl-ubsan-file_handle_create_close ... afio_dl-ubsan-file_handle_lock_unlock ... afio_dl-ubsan-map_handle_create_close ... afio_dl-ubsan-open_hash_index ... afio_dl-ubsan-packed_backtrace ... afio_dl-ubsan-ringbuffer_log ... afio_dl-ubsan-section_handle_create_close ... afio_dl-ubsan-shared_fs_mutex ... afio_dl-ubsan-spinlock_tribool ... afio_dl-ubsan-test_guard ... afio_dl-ubsan-test_import ... afio_dl-ubsan-test_message ... afio_dl-ubsan-type_traits ... afio_docs ... afio_hl-asan-atuple ... afio_hl-asan-coverage_main ... afio_hl-asan-execinfo_win64 ... afio_hl-asan-file_handle_create_close ... afio_hl-asan-file_handle_lock_unlock ... afio_hl-asan-map_handle_create_close ... afio_hl-asan-open_hash_index ... afio_hl-asan-packed_backtrace ... afio_hl-asan-ringbuffer_log ... afio_hl-asan-section_handle_create_close ... afio_hl-asan-shared_fs_mutex ... afio_hl-asan-spinlock_tribool ... afio_hl-asan-test_guard ... afio_hl-asan-test_import ... afio_hl-asan-test_message ... afio_hl-asan-type_traits ... afio_hl--atuple ... afio_hl--coverage_main ... afio_hl--execinfo_win64 ... afio_hl--file_handle_create_close ... afio_hl--file_handle_lock_unlock ... afio_hl--map_handle_create_close ... afio_hl-msan-atuple ... afio_hl-msan-coverage_main ... afio_hl-msan-execinfo_win64 ... afio_hl-msan-file_handle_create_close ... afio_hl-msan-file_handle_lock_unlock ... afio_hl-msan-map_handle_create_close ... afio_hl-msan-open_hash_index ... afio_hl-msan-packed_backtrace ... afio_hl-msan-ringbuffer_log ... afio_hl-msan-section_handle_create_close ... afio_hl-msan-shared_fs_mutex ... afio_hl-msan-spinlock_tribool ... afio_hl-msan-test_guard ... afio_hl-msan-test_import ... afio_hl-msan-test_message ... afio_hl-msan-type_traits ... afio_hl--open_hash_index ... afio_hl--packed_backtrace ... afio_hl--ringbuffer_log ... afio_hl--section_handle_create_close ... afio_hl--shared_fs_mutex ... afio_hl--spinlock_tribool ... afio_hl--test_guard ... afio_hl--test_import ... afio_hl--test_message ... afio_hl-tsan-atuple ... afio_hl-tsan-coverage_main ... afio_hl-tsan-execinfo_win64 ... afio_hl-tsan-file_handle_create_close ... afio_hl-tsan-file_handle_lock_unlock ... afio_hl-tsan-map_handle_create_close ... afio_hl-tsan-open_hash_index ... afio_hl-tsan-packed_backtrace ... afio_hl-tsan-ringbuffer_log ... afio_hl-tsan-section_handle_create_close ... afio_hl-tsan-shared_fs_mutex ... afio_hl-tsan-spinlock_tribool ... afio_hl-tsan-test_guard ... afio_hl-tsan-test_import ... afio_hl-tsan-test_message ... afio_hl-tsan-type_traits ... afio_hl--type_traits ... afio_hl-ubsan-atuple ... afio_hl-ubsan-coverage_main ... afio_hl-ubsan-execinfo_win64 ... afio_hl-ubsan-file_handle_create_close ... afio_hl-ubsan-file_handle_lock_unlock ... afio_hl-ubsan-map_handle_create_close ... afio_hl-ubsan-open_hash_index ... afio_hl-ubsan-packed_backtrace ... afio_hl-ubsan-ringbuffer_log ... afio_hl-ubsan-section_handle_create_close ... afio_hl-ubsan-shared_fs_mutex ... afio_hl-ubsan-spinlock_tribool ... afio_hl-ubsan-test_guard ... afio_hl-ubsan-test_import ... afio_hl-ubsan-test_message ... afio_hl-ubsan-type_traits ... afio-msan ... afio_sl ... afio_sl-asan ... afio_sl-asan-atuple ... afio_sl-asan-coverage_main ... afio_sl-asan-execinfo_win64 ... afio_sl-asan-file_handle_create_close ... afio_sl-asan-file_handle_lock_unlock ... afio_sl-asan-map_handle_create_close ... afio_sl-asan-open_hash_index ... afio_sl-asan-packed_backtrace ... afio_sl-asan-ringbuffer_log ... afio_sl-asan-section_handle_create_close ... afio_sl-asan-shared_fs_mutex ... afio_sl-asan-spinlock_tribool ... afio_sl-asan-test_guard ... afio_sl-asan-test_import ... afio_sl-asan-test_message ... afio_sl-asan-type_traits ... afio_sl--atuple ... afio_sl--coverage_main ... afio_sl--execinfo_win64 ... afio_sl--file_handle_create_close ... afio_sl--file_handle_lock_unlock ... afio_sl--map_handle_create_close ... afio_sl-msan ... afio_sl-msan-atuple ... afio_sl-msan-coverage_main ... afio_sl-msan-execinfo_win64 ... afio_sl-msan-file_handle_create_close ... afio_sl-msan-file_handle_lock_unlock ... afio_sl-msan-map_handle_create_close ... afio_sl-msan-open_hash_index ... afio_sl-msan-packed_backtrace ... afio_sl-msan-ringbuffer_log ... afio_sl-msan-section_handle_create_close ... afio_sl-msan-shared_fs_mutex ... afio_sl-msan-spinlock_tribool ... afio_sl-msan-test_guard ... afio_sl-msan-test_import ... afio_sl-msan-test_message ... afio_sl-msan-type_traits ... afio_sl--open_hash_index ... afio_sl--packed_backtrace ... afio_sl--ringbuffer_log ... afio_sl--section_handle_create_close ... afio_sl--shared_fs_mutex ... afio_sl--spinlock_tribool ... afio_sl--test_guard ... afio_sl--test_import ... afio_sl--test_message ... afio_sl-tsan ... afio_sl-tsan-atuple ... afio_sl-tsan-coverage_main ... afio_sl-tsan-execinfo_win64 ... afio_sl-tsan-file_handle_create_close ... afio_sl-tsan-file_handle_lock_unlock ... afio_sl-tsan-map_handle_create_close ... afio_sl-tsan-open_hash_index ... afio_sl-tsan-packed_backtrace ... afio_sl-tsan-ringbuffer_log ... afio_sl-tsan-section_handle_create_close ... afio_sl-tsan-shared_fs_mutex ... afio_sl-tsan-spinlock_tribool ... afio_sl-tsan-test_guard ... afio_sl-tsan-test_import ... afio_sl-tsan-test_message ... afio_sl-tsan-type_traits ... afio_sl--type_traits ... afio_sl-ubsan ... afio_sl-ubsan-atuple ... afio_sl-ubsan-coverage_main ... afio_sl-ubsan-execinfo_win64 ... afio_sl-ubsan-file_handle_create_close ... afio_sl-ubsan-file_handle_lock_unlock ... afio_sl-ubsan-map_handle_create_close ... afio_sl-ubsan-open_hash_index ... afio_sl-ubsan-packed_backtrace ... afio_sl-ubsan-ringbuffer_log ... afio_sl-ubsan-section_handle_create_close ... afio_sl-ubsan-shared_fs_mutex ... afio_sl-ubsan-spinlock_tribool ... afio_sl-ubsan-test_guard ... afio_sl-ubsan-test_import ... afio_sl-ubsan-test_message ... afio_sl-ubsan-type_traits ... afio-tsan ... afio-ubsan ... all (the default if no target is provided) ... _asan ... clean ... Continuous ... ContinuousBuild ... ContinuousConfigure ... ContinuousCoverage ... ContinuousMemCheck ... ContinuousStart ... ContinuousSubmit ... ContinuousTest ... ContinuousUpdate ... depend ... _dl ... _docs ... edit_cache ... Experimental ... ExperimentalBuild ... ExperimentalConfigure ... ExperimentalCoverage ... ExperimentalMemCheck ... ExperimentalStart ... ExperimentalSubmit ... ExperimentalTest ... ExperimentalUpdate ... _hl ... install ... install/local ... install/strip ... kerneltest_docs ... list_install_components ... _msan ... Nightly ... NightlyBuild ... NightlyConfigure ... NightlyCoverage ... NightlyMemCheck ... NightlyMemoryCheck ... NightlyStart ... NightlySubmit ... NightlyTest ... NightlyUpdate ... quickcpplib_docs ... rebuild_cache ... _sl The following are some of the valid targets for this Makefile: ... _tsan ... _ubsan ```

The target graphs are REGEXable via the pattern "<lib>_-<special>-<binary>" where:

* hl = header only library * sl = static library * dl = shared library There is no need for `hl` as it doesn’t produce binaries.

"hl" is necessary as a CMake logical target, not at as a build output. The problem I have with all those targets, is that they add a lot of overload to IDE solutions who will scan sources for every configuration and for people whose workflow is to build "all" or the whole solution for MSVC, which will build way too many versions.

...

... and <special> is anything affecting the link requirements of the binary, so here QuickCppLib auto detected the code sanitisers asan,msan,tsan,ubsan all of which require to be linked like-with-like, and hence needed a separate <special> category.

Group-level targets also exist, so "afio_sl-tsan" means "all the static library AFIO targets with Thread Sanitiser", "_tsan" means "all the targets with Thread Sanitiser" and so on.

Almost the entire graph above is marked with EXCLUDE_FROM_ALL, so it is NOT built unless you specifically request it at the command line.

The above is just the mangling for cmake targets which must always be unique within a given cmake build else cmake will refuse to work, hence mangling systematically according to a strict REGEX pattern makes a ton of sense (and using TARGET ALIAS to a more convenient to type target name like "boost::afio").

The actual binaries generated by the build are further mangled again according to this REGEXable pattern:

``` if(CMAKE_GENERATOR MATCHES "Visual Studio") set_target_properties(${PROJECT_NAME}_dl PROPERTIES OUTPUT_NAME "${PROJECT_NAME}_dl-${PROJECT_VERSION_MAJOR}.${PROJECT_VERSION_MINOR}-$-$(Platform)-$<CONFIG>" ) elseif(CMAKE_GENERATOR MATCHES "Xcode") set_target_properties(${PROJECT_NAME}_dl PROPERTIES OUTPUT_NAME "${PROJECT_NAME}_dl-${PROJECT_VERSION_MAJOR}.${PROJECT_VERSION_MINOR}-$-${CMAKE_SYSTEM_PROCESSOR}-$<CONFIG>" ) else() set_target_properties(${PROJECT_NAME}_dl PROPERTIES OUTPUT_NAME "${PROJECT_NAME}_dl-${PROJECT_VERSION_MAJOR}.${PROJECT_VERSION_MINOR}-${CMAKE_SYSTEM_NAME}-${CMAKE_SYSTEM_PROCESSOR}-${CMAKE_BUILD_TYPE}" ) endif() ``` We could definitely encode this information from the build into the name, but it should be an option like it is now. Perhaps when building with `-DLAYOUT=tagged` will get this behavior. Of course, all this will require custom functions from our own cmake module to make sure this is consistent across boost libraries.

I think this is the proper middle ground between both approaches and should totally be doable. In order to reduce boilerplate across all libraries, some common support code needs to be added anyway. As for which one should be default, that's I guess another whole discussion (which is kind of moot when using "add_subdirectory()" integration for example). Though, I disagree with the example above, there's no need to separate all the platforms. The Visual Studio generators don't support multiple archs (Intel 32, 64 and ARM) together, so no "$(Platform)" needed. On Darwin, CMAKE_SYSTEM_PROCESSOR is a bit unreliable too if you consider universal builds on the platforms (ppc + i386 + x86_64). For other generators, you should use the generator expressions too.

...

This will generate library binaries of the pattern:

afio_dl-2.0-Linux-x64-Release.so afio_dl-2.0-FreeBSD-x64-MinSizeRel.so afio_dl-2.0-Win32-x86-RelWithDebInfo.dll

... and so on, correctly handling if the user selects different build configs in Visual Studio or XCode which cmake doesn't know anything about. Only when you link against the library using this pattern, which is really only necessary when not using cmake.

...

So, all in all, very like Boost.Build currently does. And that's because it's the correct design and approach to take. So we should do that in any cmake of Boost too. The issue isn’t that we encode build information into the name. Its that cmake doesn’t handle multiple variants in the same build tree, like what boost build does. Cmake could support this as it supports multiple configurations with IDEs like VS or XCode. This could be extended to all build systems. Until then, I think building a frontend for cmake that can automate the multiple build trees would be useful to users of b2.

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

...

...

The target graphs are REGEXable via the pattern "<lib>_-<special>-<binary>" where:

* hl = header only library * sl = static library * dl = shared library There is no need for `hl` as it doesn’t produce binaries.

"hl" is necessary as a CMake logical target, not at as a build output.

Indeed. Paul seems to have a mental block regarding header only cmake targeting.

The problem I have with all those targets, is that they add a lot of overload to IDE solutions who will scan sources for every configuration and for people whose workflow is to build "all" or the whole solution for MSVC, which will build way too many versions.

You are correct - if the end user loads the base .vcxproj file. But be aware that consuming cmake projects will link against only the dependent targets that they use, and if you load those .vcxprojs they consist exactly of the minimum subset of targets used. So consider the base library level .vcxproj as a "database". For example, if I open a .vcxproj for an individual unit test, I will get only the minimum target set for that unit test to compile. You'd do the same thing for a release building project. It would bring in only the targets for doing a release distro. Users ought to open that one instead, and we can hide the base "database" .vcxproj file inside a subdirectory. You might now say why bother with a master "database" .vcxproj file then? A single file eases much of the remaining build scripting without needed to use custom cmake function logic, which I strongly recommend against, but am absolutely sure we will see proliferate with all the usual bad consequences in the Boost conversion (c.f. Paul's library of custom cmake function logic he's pushing). But it is true that as the database gets bigger, cmake takes longer to generate it, and eventually a tradeoff needs to be made. That said, cmake 3.9 got a lot faster at generating huge lists of target permutations into a single solution, and I expect that trend will continue as big cmake users like Google push harder on that. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On Mon, 2017-07-24 at 12:42 +0200, Florent Castelli via Boost wrote:

On 24/07/2017 01:19, P F via Boost wrote:

...

...

On Jul 23, 2017, at 5:42 AM, Niall Douglas via Boost wrote:

...

...

 

The target graphs are REGEXable via the pattern "<lib>_-<special>-<binary>" where:

* hl = header only library * sl = static library * dl = shared library

There is no need for `hl` as it doesn’t produce binaries.

"hl" is necessary as a CMake logical target, not at as a build output. The problem I have with all those targets, is that they add a lot of  overload to IDE solutions who will scan sources for every configuration  and for people whose workflow is to build "all" or the whole solution  for MSVC, which will build way too many versions.

Yea, I dont think we should mangle the logical target name at all. The user should be able to write `target_link_libraries(lib boost::foo)` and that should work for either static, shared, or header-only. Supporting multiple variants like shared and static in the same build tree are not supported with cmake, and creating workarounds to try and support them in the same build tree just creates problems. To build shared and static requires two build directories with cmake. 

...

Yea, I dont think we should mangle the logical target name at all. The user should be able to write `target_link_libraries(lib boost::foo)` and that should work for either static, shared, or header-only.

As we already discussed, sl/dl/hl have the problem that when a non-header-only library links to a header-only one which in turn links to a non-header-only one, the sl/dl of the first one should propagate to the third, which is problematic if the second has to be -hl.

As we also previously discussed, the easy way out of that is to enforce all header, all static or all shared. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

...

As we also previously discussed, the easy way out of that is to enforce all header, all static or all shared.

But this is not possible in general as not all libraries support header-only.

The preference for header-only, if supported, is orthogonal to the preference for static or shared. In sl/dl terms, it's not sl/dl/hl, it's sl/dl/slh/dlh, so that when you propagate downstream through a header-only library, the s/d isn't lost.

I think you're overcomplicating things. If a header only library has a dependency on a non-header only library capable of either static or shared usage, then the header only library simply advertises itself as having static or shared usage only. Not header only. In other words, header only targets means "nothing to link if you use this". Does this make sense now? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On 25/07/2017 23:01, Peter Dimov via Boost wrote:

Niall Douglas wrote:

...

I think you're overcomplicating things.

If a header only library has a dependency on a non-header only library capable of either static or shared usage, then the header only library simply advertises itself as having static or shared usage only. Not header only.

In other words, header only targets means "nothing to link if you use this". Does this make sense now?

The implication is that when a library changes from header-only to static/shared, all dependent libraries need to change themselves to static/shared too.

I'm not sure if this is a question or a statement. But in either case, yes it does. If the final library being consumed is static, all dependencies are static or header only. If the final library being consumed is shared, all dependencies are shared or header only. 95% of end users are probably okay with this default. Unusual needs like people who want static libraries of shared-ready code suitable for a final assembly into some monolithic shared library are likely niche users we need not consider deeply. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On Wed, Jul 26, 2017 at 12:16 AM, Peter Dimov via Boost wrote:

Niall Douglas wrote:

...

...

The implication is that when a library changes from header-only to > static/shared, all dependent libraries need to change themselves to > static/shared too.

I'm not sure if this is a question or a statement. But in either case, yes it does.

My point was that under my overcomplicated scheme, this doesn't happen. Your dependency may change from header-only to static/shared, or from static/shared to header-only, and you don't need to do anything.

And when I say "change" here, I mean that version 1 was header-only, version 2 becomes static/shared, version 3 becomes header-only again, and dependents don't need to make corresponding changes each time this occurs.

Isn't this automatic in Niall's scheme too? I don't know but it should be. -- Olaf

On 7/26/2017 4:22 PM, Niall Douglas via Boost wrote:

On 25/07/2017 23:16, Peter Dimov via Boost wrote:

...

Niall Douglas wrote:

...

...

The implication is that when a library changes from header-only to > static/shared, all dependent libraries need to change themselves to > static/shared too.

I'm not sure if this is a question or a statement. But in either case, yes it does.

My point was that under my overcomplicated scheme, this doesn't happen. Your dependency may change from header-only to static/shared, or from static/shared to header-only, and you don't need to do anything.

And when I say "change" here, I mean that version 1 was header-only, version 2 becomes static/shared, version 3 becomes header-only again, and dependents don't need to make corresponding changes each time this occurs.

This seems highly unlikely to be desirable in practice. A header only library guaranteeing header only usage suddenly requiring something to be linked is a *major* change. You'd *want* libraries dependent on it to stop compiling!

I disagree here. There is nothing unusual in theory for creating a header only library which needs to link to a non-header only library, whether that non-header only library is a static library or a shared library. The choice of a header only or non-header only library should not be predicated on whether or not any other library on which it depends is header only or non-header only. Furthermore, and most obviously, a non-header only library may have a great portion of its code as header only and just a small portion of its code as being built into a static or shared library. So another header only library might depend on a non-header only library, but could depend on only the code in the non-header only library which is header-only, or conversely could depend on the code which is part of a static or shared build of the non-header only library. And those dependencies could change as the design of a header only library evolves. Given all these very real possibilities, none of which should be important in forcing an actual design of a header only library, I find it absurd to "stop compiling" simply because the design of a build system is too simplistic to deal with the variations.

The big reason I keep advocating in favour of specific cmake targets for header-only libraries is because it solves auto-linking for all platforms without using linker magic. I think that a nice win for end users. It also could be extended easily to transparently use C++ Modules in the future, another nice win for end users.

Can you suggest where, in the case of Boost, it would be important to support dependent libraries changing their header only usability?

Niall

On Wed, 2017-07-26 at 23:29 +0100, Niall Douglas via Boost wrote:

...

...

This seems highly unlikely to be desirable in practice. A header only library guaranteeing header only usage suddenly requiring something to be linked is a *major* change. You'd *want* libraries dependent on it to stop compiling!

I disagree here. There is nothing unusual in theory for creating a header only library which needs to link to a non-header only library, whether that non-header only library is a static library or a shared library. The choice of a header only or non-header only library should not be predicated on whether or not any other library on which it depends is header only or non-header only.

I think this the crux of the misunderstanding.

cmake doesn't implement header only library support as you and Peter appear to understand it. It implements INTERFACE targets. These are, quite literally, targets wholly composed of nothing. They cannot contain sources. They can inject paths to search for headers, compile and link flags into things which consume them. That's it.

So when I've been speaking of implementing header only library support into cmake, I really mean targets consisting solely of how to find interface files, and how the final binary ought to be compiled and linked to keep the header only library happy. No non-wholly-interface-file dependencies permitted, though you can inject linking to arbitrary system or other libraries. The target dependency graph is *pure*.

The point in "modern cmake 3" if you will, is that I write: find_package(boost_foo) target_link_libraries(myLib boost::foo) And this will work whether boost_foo is header-only or compiled static or shared. Not only that, but if boost_foo or one of its dependents change from being header-only to being compiled(or vice versa), build scripts to boost_foo or any downstream libraries do not need to change.  This is the usefulness of exporting usage requirements with build systems, and why it is important in cmake 3. What you are proposing does not provide this usefulness and is a major step backwards.

On Thursday, July 27, 2017 2:06:49 AM CDT Niall Douglas via Boost wrote:

Where are you getting the notion that end users want to not care whether their dependencies are in header only, or static, or shared form?

I'm a user and generally: I don't care and certainly don't want to futz around with updating my code's build logic just because a library chose to change from static-only to header-only. -Steve

Yea, I dont think we should mangle the logical target name at all. The user should be able to write `target_link_libraries(lib boost::foo)` and that should work for either static, shared, or header-only. Supporting multiple variants like shared and static in the same build tree are not supported with cmake, and creating workarounds to try and support them in the same build tree just creates problems. To build shared and static requires two build directories with cmake.

This is provably untrue. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On 24/07/2017 21:27, Roger Leigh via Boost wrote:

On 24/07/17 21:07, Niall Douglas via Boost wrote:

...

...

Yea, I dont think we should mangle the logical target name at all. The user should be able to write `target_link_libraries(lib boost::foo)` and that should work for either static, shared, or header-only. Supporting multiple variants like shared and static in the same build tree are not supported with cmake, and creating workarounds to try and support them in the same build tree just creates problems. To build shared and static requires two build directories with cmake.

This is provably untrue.

It's entirely correct if you read what he was saying carefully.

If and only if you start from the cmake 2 design pattern of a build directory per configuration. Which may be wise to choose for a long list of *other* reasons given the wider picture, but the reason that it is "natural", "correct", "modern" or any of the other things Paul is claiming is provably untrue. It for sure is not cmake 3 anyway. cmake 3's target based enhancements are unnecessary extra work and complication if you can hard assume a build directory per configuration. Just go ahead and set things based on directory as you did in cmake 2 e.g. add_definitions(). Make life easier on yourself. Skip all that cmake 3 target nonsense. And then ask yourself why bother with cmake 3 altogether if you're not using it? cmake 2.8.12 was perfectly fine. Let's use that, and lots of custom macros. Plenty of large scale cmake build systems work perfectly well with cmake 2.8.

If you use a single target name "lib", this will be a shared library or a static library depending upon the build configuration (the BUILD_SHARED_LIBS option), or a header-only library.

Supporting shared and static simultaneously isn't possible *with a single target name*. You would have to have e.g. "lib" and "lib-static". And on of the libraries e.g. the static library would need a mangled name since on Windows both the import library and the static library have a .lib extension and would clash with each other. Doing that is possible, but bad practice. The target names are mangled and not as usable downstream; downstream use has to commit to specific variants, and it's a lot less flexible. Choosing shared or static at configure time is the way cmake is designed to work, and it's the better choice here. (I have gone with the lib+list-static approach in the past and regretted it later.)

It is how cmake *was* designed to work in the 2000s. That was later discovered to be suboptimal. cmake 3's improvements enable very significant cmake scripting composability and reusability via a mostly or purely declarative target based specification, including reuse by unknown third party cmake. But I get the feeling that nobody here is listening. You're all set in your cmake ways and that's that. Before the SC made this decision, myself and Peter did up a reasonable prototype use case example for Boost cmake, I obviously think mine is better, but I still find his acceptable as his design was sound. It used an impure declarative design. It was okay. It was cmake 3 at least. If Boost proceeds down a path of build directory per config, I will fight it as hard as I can because I believe it to be seriously suboptimal. But in the end, it comes down to whomever is willing to do the work, and I am definitely not after my experience contributing to the git migration. If those willing to do the work are incapable of understanding cmake 3 design patterns, then Boost will have to adopt a cmake 2 design instead. So long as they don't dress it up as being "modern cmake", I'm fine with that. As I said earlier right at the top of this email, it may well be judged that whatever cmake a critical mass in the community can wrap their heads around is considered better than what is optimal or modern. And cmake 2.8 design patterns would have a critical mass far more than modern cmake, not least in terms of documentation and tutorials. So for all those *other reasons*, maybe a clean cmake 2.8 design is best after all. Just stop calling it anything other than cmake 2, because it's not. And don't pin the cmake version required to anything later than cmake 2.8.12, because you don't need to. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

On 22/07/17 20:00, Peter Dimov via Boost wrote:

Roger Leigh wrote:

...

...

Similarly, the pkg-config one. I'm genuinely interested in how > pkg-config support, if we have it, is supposed to handle multiple build > variants having been installed.

I've already solved that for the cmake -config files, but I'm not sure I > see a way for pkg-config to support it.

It's been a while since I looked at this, but my understanding is that it can't by design. You have one variant installed, with a matching set of pkg-config files which point to those libraries.

I implemented something along those lines. git clone the "feature/pkgconfig" branch of boostorg/boost, and then at the root (after having built b2) issue

b2 tools/pkgconfig//stage

This will stage the .pc files into stage/lib/pkgconfig.

b2 tools/pkgconfig//install

should also work and put them into $(prefix)/lib/pkgconfig.

This is not a 100% working solution because of some irregular cases such as math, exception, test, stacktrace, and it doesn't contain the external dependencies such as -lrt ot -lbzip2 as I can't retrieve them automatically. But it could be useful nevertheless.

Note that I'm generating .pc files for the header-only libraries as well, otherwise there's no way to track static -> header-only -> static dependencies properly.

That makes sense. I've given it a build and taken a look at the .pc files. Overall it looks very promising. I'll have to do a more rigourous check of the depedencies when I have some more free time. I'm unsure of the use of Requires.private for all dependencies, e.g. for filesystem: Cflags: -I${includedir} Libs: -L${libdir} -lboost_filesystem Requires.private: boost_assert = 1.65.0, boost_config = 1.65.0, boost_core = 1.65.0, boost_detail = 1.65.0, boost_functional = 1.65.0, boost_io = 1.65.0, boost_iterator = 1.65.0, boost_range = 1.65.0, boost_smart_ptr = 1.65.0, boost_static_assert = 1.65.0, boost_system = 1.65.0, boost_type_traits = 1.65.0 The boost_system dependency, for example, is required when linking to filesystem dynamically on Linux and BSD because the filesystem headers include the system headers, which forces system it to be explicitly linked even if you don't use it directly. The non-library components could certainly be private, but does it hurt to have them public? Are there some extra subtleties here? Other than that, the only minor cosmetic issue I saw was the duplication of the version in the description. Thanks, Roger

On 07/23/17 01:09, Peter Dimov via Boost wrote:

Roger Leigh wrote:

...

The boost_system dependency, for example, is required when linking to filesystem dynamically on Linux and BSD because the filesystem headers include the system headers, which forces system it to be explicitly linked even if you don't use it directly.

Yes, you're right, these dependencies should be public. (And the private ones weren't being added at all.) Fixed.

Now that it's fixed,

C:\Projects\boost-git>pkg-config --libs --static boost_log Æ A: out of memory This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information.

but, well. :-)

It did succeed for me, but it took about 4.5GB and about 10 seconds to complete. :) BTW, there are two libraries in Boost.Log: libboost_log.so and libboost_log_setup.so (the latter is not mentioned in .pc). They have different dependencies, so if there were two separate .pc files, the list of dependencies could be shorter. But I suspect extracting that information from Boost.Build won't be easy.

On 07/23/17 03:14, Peter Dimov via Boost wrote:

On a related note, an interesting property of these .pc files is that, as currently generated, they are independent of the actual library build (depending on which would mean that the generation could only be done at `b2 install` time, that is, on the user machine.) As it stands though, these we can generate beforehand and include in the release (in f.ex. $BOOST_ROOT/pkgconfig) - but this necessarily implies that I can't include build time information such as actual file names.

But the -l switches should include name tags like -mt or -gd, if present, which are specific to the build config. (I didn't test that with the current implementation as no tags are produced by default on my Linux machine.) PS: As a totally wild idea, would it be possible to generate .pc files as an artefact of dynamically generated Boost.Build targets, each depending on a lib target in the library submodules? That would provide not only the target dependencies but also usage requirements.

On Sat, Jul 22, 2017 at 1:18 PM, Roger Leigh via Boost wrote:

On 22/07/17 11:47, Peter Dimov via Boost wrote: This is a case where Boost's policy of appending all of the toolset/configuration/threading model etc. to the library name is somewhat unique and, and generally incompatible with how the rest of the world works. In general, I've found it a hindrance to interoperability, and solving a problem which I didn't have in the first place. No one else does it, and there's likely a good reason for that! At most, I add a 'd' debug postfix on Windows, and that's it (this is handled by CMake as a standard behaviour). If I need multiple configurations, I build them separately and explicitly; I don't expect it of the build system itself.

What about multiple compiler versions, dynamic vs static library and dynamic vs static runtime? Until vcpkg this has been a disaster for me (on Windows). Having to collect outputs from multiple build trees and then hoping you're linking to the right one.. -- Olaf

Andrey Semashev wrote:

When Boost is packaged though, it is typically compiled in just one configuration, so a single set of binaries is packaged and then installed in the end user system.

Everyone seems to do it differently. Fedora: /usr/lib/libboost_filesystem.so.1.63.0 CentOS 7: /usr/lib64/libboost_filesystem-mt.so.1.53.0 /usr/lib64/libboost_filesystem.so.1.53.0 Ubuntu Trusty: /usr/lib/x86_64-linux-gnu/libboost_filesystem.a /usr/lib/x86_64-linux-gnu/libboost_filesystem.so That's not our problem though, we don't have control over that. What we'd need to do is generate .pc files on `b2 install`, and the number of files this would produce is not known ahead of time, it depends on the options the user gives.

On Fri, Jul 21, 2017 at 4:25 PM, Roger Leigh via Boost wrote:

Could I also point to this block in https://gitlab.kitware.com/cmake/cmake/blob/master/Modules/FindBoost.cmake#L...

Ouch. Wouldn't be even better of non-Windows toolsets supported auto-linking such that this wasn't necessary at all?