There are three general categories for the direction of Boost.Build once BBv2 has been released:
(M) The maintenance of BBv2 should happen independently of the Python port.
(M) The core logic should be as stable as possible, only changing if there is a bug that needs fixing.
(P) The core logic will be rewritten in Python.
(P) The initial Python port must be compatible with existing BBv2 projects, unless there is a good reason for it to differ.
(P) Where possible, the Python port should make use of Python facilities (lists, tuples and dictionaries) and standard libraries.
(P) Replace most (if not all) of the util code with Python equivalents, for example, replace util/set.jam with Set.
(P) Should this be built on top of SCons to handle the target dependancy graphs or should the current BBv2 logic be directly ported? This is because it is preceived that SCons has performance issues (although work has undergone to improve this).
(3/P) Replace calls to rm/del and other shell utilities with their Python equivalents.
(3) Instead of using the shell to execute commands, use the facilities of Python to help with this. For example, executing a process can be done by:
import subprocess
PIPE = subprocess.PIPE STDOUT = subprocess.STDOUT
EOL = '\r\n' # Make this Windows/Mac?/Linux? compatible
def run( cmd, input=None ): p = subprocess.Popen( cmd, shell=True, stdout=PIPE, stderr=STDOUT, stdin=PIPE )
stdin_ = None if input != None: stdin_ = '\n'.join( input )
out, err = p.communicate( stdin_ )
return out.split( '\r\n' )
def run2( cmd, input=None ): p = subprocess.Popen( cmd, shell=True, stdout=PIPE, stderr=PIPE, stdin=PIPE )
stdin_ = None if input != None: stdin_ = '\n'.join( input )
out, err = p.communicate( stdin_ )
return out.split( '\r\n' ), err.split( '\r\n' )
This then allows for things like:
run( [ 'cl.exe', '-c', 'hello.cpp' ] )
TODO: What about printing the output of a command incrementally to the user and collecting the output.
(3) Combine the rule/action logic into one. At the moment, it is difficult to write portable logic inside the action block (see the Boost.Test logic for an example). This would then allow the Boost.Test logic to be written cleanly using Python and the run command above.
(3) Better support passing optional named arguments to an action, allowing them to be used in the Python code to determine what to do. For example:
def msvc_link( ..., conditionals ): cmd = [ 'link.exe', '-c' ] if( conditionals.has_key( 'DEF_FILE' )): cmd.extend( '-def', conditionals[ 'DEF_FILE' ] ) # Or whatever this is. run( cmd )
(3) Allow properties to be propagated upstream as well as down. This is to help PCH support.
(3) Provide support for generating different outputs (preprocessed, assembler) from the toolsets.
(3) Improve support for multi-pass builds through the same toolset (e.g. CPP -> [preprocess] -> OBJ).
(3) Multiple source input model to compile actions (Java/C#) or single input model (C++).
(3) Allow an external preprocessor to be used for the preprocess step (e.g. Boost.Wave or the preprocess tool that comes with the Borland compiler).
(3) Support multiple (orthogonal) toolsets within the same build; that is, one toolset *per* language. For example:
(3) Make it easier to support more advanced build models, for example, building an external tool (such as Flex/Bison?) that will then be used to generate source targets.
[buy lipitor online] [buy lipitor] [[buy lipitor online]]
[buy fioricet online] [buy fioricet] [[buy fioricet online]]