[Boost-build] Optional targets (Was: support of Microsoft .idl files for MSVC)

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-11-23 03:15:27

Hi Alexey,

> 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), 
immediately.

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

Going back to your example, generator for IDL could do:

  local jam_target = [ $(targets[1]).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.

- Volodya