Stefan Seefeld wrote:
Then what about the second point, which was:
2) Define a clear interface the outer build logic will use to invoke the nested build commands.
The clear interface at present is that you need to have a Jamfile. Building using something else as part of the global build is not supported, unless you somehow invoke this something else from your Jamfile. But this would imply that whatever something else you pick - for instance, SCons - would now become a prerequisite for building Boost.
In other words, what does that Jamroot file need to contain at a minimum, to satisfy the global build processes (i.e., the ones used to build Boost as a whole, including building release docs etc.) ?
The global build process currently in use requires you to not have a Jamroot.
There are globally called rules such as "boost-install", "boostrelease", etc. that seem to be required.
Yes, if you want to use the boost-install rule, it won't work without the global Boost Jamroot. I'm not entirely clear on what we're talking about here though. Are we in the "git clone boostorg/python" standalone case yet, or are we in "git clone --recursive boostorg/boost", except you want to use SCons for libs/python instead?