Boost logo

Boost-Build :

From: Liam Routt (caligari_at_[hidden])
Date: 2005-11-20 18:42:23


Chris Dragan wrote:
> The proposed patch fixes header dependency scanning in Jam.
...
> The Patch
> ---------
>
> The patch in the attachment applies the above solution both to Jambase and
> to jambase.c. The patch was made against Boost Jam 3.1.9, but it is
> working as well with e.g. 3.1.6.

It works as well with 3.1.11, although the line numbers change (which
patch picks up easily) to 1196 and 810, for what it is worth.

> I hope that someone will find it useful.

Thanks indeed for those!

I don't have all that much to offer in return, really (although it
takes many lines to describe)...

I have noticed a (slight) problem with dependencies, in that the
compiler include directories are not inculded in STDHDRS unless you
explicitly add them. For example, on my linux box the gcc includes are
in:
/usr/lib/gcc/i686-pc-linux-gnu/3.4.4/include, and
/usr/lib/gcc/i686-pc-linux-gnu/3.4.4/include/g++-v3
If they are not searched, I end up with a directory in my build tree
standing in for the std header "list", which has resulted in most of my
project being rebuilt regardless of changes in dependencies.

Obviously I should change the name of the directory so that this cannot
happen, but such changes can be problematic with legacy code.

Instead I've added the gcc include dirs in STDHDRS, and search them
before my project root dir when looking for headers.

In order to avoid hard-coding the paths I've had to process the return
from "gcc -v" to extract the relevant directories. Unfortunately, doing
that in my Jamerules file requires the use of the documented but
unavailable "SHELL" command.

I've patched jam to give me access to that command as "COMMAND", which
does not collide with other boost command names (as "SHELL" does):

========== builtin_shell_fix (against Bosot Jam 3.1.11) :
--- builtins.c
+++ builtins.c
@@ -320,7 +320,7 @@

{
char * args[] = { "command", 0 };
- bind_builtin( "SHELL",
+ bind_builtin( "COMMAND",
builtin_shell, 0, args );
}
==========

With that in place I create a rule to process a returned list (space
delimted) into a jam list (I'm sure this can be improved upon; the
limitations of the built-in regular expressions led me to convoluted
code which I have not revisted):

==========
rule CommandList
{
local _l = [ MATCH ([0-9a-zA-Z/\.\+-]+)(\ ([0-9a-zA-Z/\.\+-]+))* :
[ COMMAND $(<) ] ] ;
local _i _ret ;

for _i in $(_l)
{
switch $(_i)
{
case [^\ ][0-9a-zA-Z/\.\+-]* : _ret += $(_i) ;
}
}
return $(_ret) ;
}
==========

I then built a (python) script to get the correct paths from each
compiler we use (it has a table with compiler [& optionally the
architecture] as a key, and the command-line flag and regular
expression to use to tease out the include paths). This script is
probably overkill, and I haven't included it here as it is not directly
relevant to jam at all.

I call my script from the configuration jam file I use for the project
(which is in turn called from my Jamrules):

========== in Configure.jam :

STDHDRS += [ CommandList "$(SCRIPTS)/compiler_includes.py $(cc)" ] ;

==========

Note that I had to use the output to list conversion code, as a string
with embeded spaces is treated as a single object by jam, despite
appearing identical to a list when printed.

The result of all this fuss and bother is that STDHDRS includes the
location of the standard library headers as installed on whatever
system we're using (as long as the script knows how to query the
compiler).

I also had to modify the HDRSEARCH setting in the Object rule, as my
project root directory was part of HDR, which is listed before
STDHDRS, but that is only to make up for the bad legacy choice of
directory name.

I hope there is something in all that which is of use to others.

Take care,

Liam

--
Liam Routt Ph: (03) 8344-1315
Research Programmer caligari_at_[hidden]
Computer Science, Melbourne University (or liam_at_[hidden])

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