On 19.06.2017 12:32, Peter Dimov via Boost wrote:
Stefan Seefeld wrote:
I know about these tricks (I use something similar to set up my Boost.Python CI environment), but consider them hacks as they don't really solve the fundamental requests, which are:
* I want to be able to build a given Boost library stand-alone, with nothing but the library's repo being checked out. (In other words: prerequisite Boost components should be assumed pre-installed.)
Why is this so important for you? The difference is just one superproject shell and one tools/build. Is this a matter of principle, or are there technical reasons?
Both. I want to control the environment in which my library is being built (, tested, etc.), and thus I don't want to fetch that environment from a repository and build it on-the-fly.
Anyway.
Boost.Build actually supports this use case:
sudo yum install boost-jam sudo yum install boost-build git clone --depth=1 https://github.com/boostorg/python cd python touch Jamroot bjam test
The first error here is
IMPORT error: rule "requires" unknown in module "../../config/checks/config"
because we don't have Boost.Config checked out as a sibling here.
When I comment out your use of ../../config/checks/config in test/Jamfile, it errors out with
rule numpy_test unknown
Trying to build with
bjam build
fails with
rule py-version unknown
Both of these errors are because these rules don't exist in the 1.53 python.jam.
So frankly, I'm not sure how do you suggest this needs to be addressed.
The numpy_test rule should probably have been added to the local Jamfile (i.e., be part of Boost.Python, rather than Boost.Build). I'm not sure about the config checks. Arguably they are part of the build system, and thus should be included in Boost.Build, rather than a separate Boost library.
On one hand, you want to use the system Boost.Build, and on the other, your Jamfiles depend on features that aren't present in it. This simply cannot work, your desires are contradictory.
Not sure what your point is. I think it's perfectly normal that on some platforms the default (system) version of a package is too old, so a newer version needs to be pulled in from another repo ("testing", perhaps ?). That doesn't invalidate my desire to work with system packages though, rather than development versions. Stefan -- ...ich hab' noch einen Koffer in Berlin...