On 18.06.2017 13:33, Robert Ramey via Boost wrote:
On 6/18/17 9:09 AM, Stefan Seefeld via Boost wrote:
One of Boost's bottlenecks is its monolithic build infrastructure. It would be beneficial for many different use cases (testing, packaging, etc.) to decouple the building of Boost libraries (well, those that require building, see the listing in http://www.boost.org/doc/libs/1_64_0/more/getting_started/unix-variants.html...)
such that they may optionally be built stand-alone.
At present, building a Boost library requires the entire (super-)repository to be checked out, and the build logic itself involves traversing the entire source tree, looking for a "Jamroot".
What would be beneficial to many would be a workflow like this:
1) Have a development environment with (some version of) Boost pre-installed (or at least the parts that the library being built depends on).
sort of a Boost without the libraries - a Boost developers kit?
Call it what you want. I thought traditionally it has been named "Boost core". (But let's not have a bikeshed discussion about it ;-) )
2) Check out a single Boost repository (e.g., https://github.com/boostorg/python)
3) Invoke a command to build it (if there is anything to build)
4) Invoke a command to test it
5) Invoke a command to install it Hmmm - I don't know what this would actually do than just copy the built library to some "special place"
6) Invoke a command to package it (optional)
After all this time I have no idea what "packaging" means in this context. I never could figure out what CPack is for or what it would do for me. Likewise. There are many different packaging formats in use, depending on the OS (e.g., "Linux distribution"), and someone needs to build those
...as well as headers, documentation, etc. This is all part of the normal Unix development culture. packages. It would be helpful to provide some infrastructure for that, as otherwise (i.e., in the current state), different OSes break up Boost in different and incompatible ways, making it even harder for developers using Boost to write portable code.
While it's of course already possible to do all the above by adding support for another build infrastructure (point in case: Boost.Python right now uses SCons for this very reason), this means duplication of effort, as Boost as a whole is still built, tested (and even packaged for binary packages) using Boost.Build, meaning I need to maintain two sets of build infrastructure.
This proposal thus has two parts:
1) Make the nested build logic independent of the outer bits, so individual libraries can be built stand-alone (for example, using b2 by adding a `--with-boost` set of options to point to the location of the prerequisite parts of Boost).
Hmmm - too fuzzy. For me, I just move to the library directory test and invoke b2 and it builds and runs the tests. By "the directory" you are surely referring to the library directory within the superproject repo, right ? Here is again what I wrote as my ideal use-case:
2) Check out a single Boost repository (e.g., https://github.com/boostorg/python)
3) Invoke a command to build it (if there is anything to build)
which right now does not work.
Then I just copy the built library from the bin.v2 tree to whereever I want so I'm done. I'm thinking this is addressed in the current system.
See above.
2) Define a clear interface the outer build logic will use to invoke the nested build commands.
too fuzzy. Needs to be more specific.
It may appear fuzzy to you because of the above. Once you see what I mean in 1), 2) should become clear. Stefan -- ...ich hab' noch einen Koffer in Berlin...