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

Subject: Re: [Boost-build] Custom type generated headers and dependency scanning
From: Vladimir Prus (ghost_at_[hidden])
Date: 2009-12-17 02:12:27

On Wednesday 16 December 2009 23:55:51 Jim Hague wrote:

> 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?

Could you start with a small experiment? When you build, the .if files should
be placed in a directory like bin/gcc/whatever
Can you try adding that directory to include path, with the <include> requirement
on the project? Does that make dependencies work right?

If so, then your next step is to actually implement the magic for setting include
paths automatically. Please take a look at builtin.jam:compile-action and
builtin.jam:C-compiling-generator -- which is what is doing that magic for C++.
I suspect you did not do this for your types. Once you do, I suspect things
will just work for you, as soon as all targets are in the same project.

- Volodya