[Boost-build] Custom type generated headers and dependency scanning

Subject: [Boost-build] Custom type generated headers and dependency scanning
From: Jim Hague (jim.hague_at_[hidden])
Date: 2009-12-16 15:55:51

I am dealing with an elderly proprietary scripting language. The language has 
source modules '.mod' which import interface files '.if' to access routines in 
other modules. A tool runs over a '.mod' to generate a '.if' for that module. 
Another converts a '.mod' to a binary '.dlg' for deployment; the '.dlg' must 
be accompanied by its '.if' to be accessed by other '.dlg'.

I've got this all working

type.register MOD : mod ;
type.register MODIF : if ;
type.register DLG : dlg ;

generators.register-standard ods5.iesutl-writeexport : MOD : MODIF ;
generators.register-standard ods5.iesutl-writebin : MOD : DLG(%.mod) ;

I've also done a scanner for '.mod' files, looking for the 'import ModName 
"foo.if"' statements that pull in another '.mod''s interface file. 

class idm-scanner : common-scanner
{
    rule pattern ( )
    {
        return "^[ \t]*import[ \t]*.*[ \t]*\"([^\"]*)\"" ;
    }
}

scanner.register mod-scanner : include ;
type.set-scanner MOD : mod-scanner ;

I then specify the '.if' files to make them available to an install rule, and 
generate the '.dlg' files.

modif interfaces : interfaces.mod ;
modif rings : rings.mod ;

dlg dlg/rings : rings.mod ;

What I'd like to happen is for the scanner to extract all the '.if' for a 
module and make them implicit dependencies of the module depend. This doesn't 
happen; adding a few ECHOs reveals that the scanner rule is working properly, 
but a build will still attempt to generate a '.if' for a '.mod' when that 
'.mod' imports a '.if' that has not yet been generated.

Going through the docs, I suspect that I'm falling foul of the observation in 
the section on generated headers:

***
By default, Boost.Build handles such dependencies within one main target. For 
example, assume that main target "app" has two sources, "app.cpp" and 
"parser.y". The latter source is converted into "parser.c" and "parser.h". 
Then, if "app.cpp" includes "parser.h", Boost.Build will detect this 
dependency. Moreover, since "parser.h" will be generated into a build 
directory, the path to that directory will automatically added to include 
path. 

Making this mechanism work across main target boundaries is possible, but 
imposes certain overhead. For that reason, if there is implicit dependency on 
files from other main targets, the <implicit-dependency>  [ link ] feature 
must be used
***

Am I right? Is my only option to add the dependencies manually?
-- 
Jim Hague - jim.hague_at_[hidden]        Never trust a computer you can't lift.