From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-11-23 03:15:27
> BTW, the generator for .idl files is registered by the following command:
> generators.register-c-compiler msvc.compile.idl : IDL : MSTYPELIB H
> C(%_i) C(%_proxy) C(%_dlldata) : <toolset>msvc ;
> Is it possible to make the output files 'C(%_proxy)' and 'C(%_dlldata)'
> optional? So that if these files are missing bjam will not try to
> recreate them.
Maybe, but the problem is deeper than that. Even if bjam won't try to recrate
them, it will still think that generator produces 3 C files and will try to
compile them all. We basically don't have a mechanism to check if the tool
really created the target. Moreover, at the point when we build dependency
graph we don't execute the actions, and by the time we execute the action
there are 3 compile actions for outputs of MIDL already, and it might be hard
to "rollback" two of them.
In a sense, "clear" architecture of jam where it first decides what to do, and
second executes commands, is not very nice here.
As a bit of history, some time ago I've modified bjam so that when it after it
executes actions that create, say .cpp file, it scans that file for
#includes. So, if you have one generated .cpp file, that includes some
generated .h files, and they are generated completely independently, bjam
will still notice the dependency. Classic Jam will notices that .cpp does not
exists, and won't scan it at all. That change was extremely hard to
accomplish -- I probably spend more that a day on that. Ideal architecture
would be one where you can build a target (executing all actions),
Heh, this might be usefull in other contexts. Say, we want to run a configure
test -- basically a program that links to libwierd and if linking is
successfull, it write libwierd.jam file containing
LIBWIERD = yes ;
That might be implemented like this (pseudocode).
LinkConfigureTest libwierd : libwierd.cpp ;
BUILD_NOW libwierd ;
include libwierd.jam ;
That is, we create a target (Jam target, not even V2 one), immediately build
it, and include the result. Without any BUILD_NOW, we'd need separate
Going back to your example, generator for IDL could do:
local jam_target = [ $(targets).actualize ] ;
BUILD_NOW $(jam_target) ;
# Check what files are produced, if necessary adjust the
# list of returned V2 targets.
That would work for just building, but will fail in "bjam -n" case -- how will
Boost.Build know if MIDL produces 1 or 3 files without running it?
So it seems that tools that optionally produce some files are bad match to a
build system, and maybe "touch" trick is the right one.
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