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