From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-12-14 06:28:25
> 1. Initially, bjam will invoke SCons at the lowest level (creating
> SCons Nodes instead of bjam's targets).
> My first feeling was that it was indeed the best way to proceed and I
> implemented a prototype of 1.:
> 1. change build-system.jam to dump a Python map of all virtual-targets
> and their relevant properties
> 2. create a Python script that reads the map an creates the appropriate
> SCons nodes
> 3. map BB properties into SCons environment settings
> This works fine when using simple properties, such as <define>,
> <include> and <linkflags>, which are readily supported by SCons
> But, in order to map things like <optimization> or <debug-symbols>, you
> need to know which compiler you are using.
> And, there must be a mapping between BB target type and the appropriate
> Environment method to call in order to create a target. And you must
> choose env.StaticObject or env.SharedObject depending on the target
> being a DLL or a LIB.
I'd expect that we create very low-level SCons representation, where each Node
represent a file, and actions and variables are computed by Boost.Build. That
is, the settings that toolset.set-target-variables is passed over to SCons
together with the command lines used by toolsets.
Why have another feature->variable translation if the existing one works?
> So, I got to the conclusion that we would be better off moving directly
> to Python.
It might be less terrible thing that it sounds, due to large number of tests
V2 has, but still will take unpredictable time. Of course, if somebody can do
it over weekend, that would be great.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk