|
Boost-Build : |
From: Markus Schöpflin (markus.schoepflin_at_[hidden])
Date: 2006-01-13 05:19:31
Vladimir Prus wrote:
> 7. Any issues are ironed out.
Some things which come to my mind:
1. Quite a number of test jam files contain workarounds for specific
compilers or platforms. Most look something like this (just as an example):
local rule special-requirements ( toolset variant : properties * )
{
if $(UNIX) && $(OS) = OSF
{
switch $(toolset)
{
case gcc* : properties += <cflags>-mfp-rounding-mode=d ;
case tru64cxx* : properties += <cflags>-fprm <cflags>d ;
}
}
return $(properties) ;
}
local rule local-run ( sources + : args * : input-files * : requirements *
: name ? : default-build * : args2 * )
{
return [ run $(sources) : $(args) : $(input-files)
: $(requirements) special-requirements
: $(name) : $(default-build) : $(args2) ] ;
}
How does the corresponding V2 code look like?
2. I use customized tool sets for all of my regression runs. For V1, one
such file looks like this:
{
extends-toolset tru64cxx65 ;
flags tru64cxx65 CFLAGS : -version V6.5-042 -ieee ;
flags tru64cxx65 LINKFLAGS : -version V6.5-042 -ieee ;
}
How will these customized tool sets work under V2?
3. Some jam files use internal V1 functions when calculating the local
requirements. For example, expressive uses "properties = [ difference
$(properties) : <debug-symbols>on ] <debug-symbols>off ;", multi_index uses
"properties = [ replace-properties $(properties) : <debug-symbols>off ] ;"
How will this have to look in V2?
Markus
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