Re: [jamboost] Dependency fix

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: [phone]
Research Programmer caligari_at_[hidden]
Computer Science, Melbourne University (or liam_at_[hidden])