Re: generated (mutiple) files with omniidl

From: Christopher Currie (Christopher_at_[hidden])
Date: 2004-03-19 16:15:09

Renej,

An approximation of what you want can be done much more simply by using 
a generator. Generators set up a lot of the infrastructure that's needed 
to help bjam work the most cleanly. A skeleton of what might work is below:

# omniidl.jam

import generators ;
import type ;

type.register IDL : idl ;
type.register HH : hh : H ;

# This command registers the rule below
generators.register-standard omniidl.omniidl
: IDL : HH CPP(%SK) CPP(%DynSK)
;

rule omniidl
{
# does nothing, for now
}

# Need -Wbs and -Wbd flags to change the suffix, because the generator
# assumes .cpp extensions.
actions omniidl
{
omniidl -bcxx -Wba -Wbs=SK.cpp -Wbd=DynSK.cpp -C$(<[1]:D) \
-I/usr/share/idl/omniORB -I/usr/share/idl/omniORB/COS $(>)
}

# end of omniidl.jam

You would use this code in a jamfile like:

# Jamfile

import omniidl ;

lib libfoo : ../idl/foo.idl ;

A couple of caveats to this approach:

* bjam will create ALL the files in the build directory
(bin/<toolset>/<variant> by default). It's smart enough to know then
where to look for the source files to create the library, but if you
have other requirements that dictate where the source files must live,
then we'll need a more sophisticated approach.

* Because the generated headers are in the build directory, you may
occasionally find the need to use an implicit dependency in order to
know where to look for the header files, as documented here:

<http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/bbv2.reference.headers.html>

renej_frog wrote:
> me again on multiple generated source files from an IDL file using
> omniidl. At the moment I'm using the following:
> 
> # --- omniidl.jam ---
> rule omniidl ( idl_sources : hh_dir : cc_dir )
> {
> for local f in $(idl_sources)
> {
> local idl_file = $(f) ;
> local hh_file = $(hh_dir)/$(f:B).hh ;
> local ccSK_file = $(cc_dir)/$(f:B)SK.cc ;
> local ccDynSK_file = $(cc_dir)/$(f:B)DynSK.cc ;
> Depends all : $(hh_file) $(ccSK_file) $(ccDynSK_file) ;
> Depends $(hh_file) : $(f) ;
> Depends $(ccSK_file) : $(f) ;
> Depends $(ccDynSK_file) : $(f) ;
> make-omniorb-stubs $(hh_file) $(ccSK_file) $(ccDynSK_file) :
> $(idl_file) ;
> }
> }
> actions make-omniorb-stubs
> {
> omniidl -b cxx -Wba -C $(1[2]:D) -I/usr/share/idl/omniORB
> -I/usr/share/idl/omniORB/COS $(2)
> mv -f $(1[2]:D)/$(2:B).hh $(1[1]:D)/
> }
> # -------------------
> 
> and using it like this:
> 
> # --- Jamfile ---
> IDL_SOURCES =
> Test
> ;
> 
> 
> 
> omniidl ../idl/$(IDL_SOURCES).idl : include/stubs : src/generated ;
> 
> 
> 
> SK_DynSK = SK DynSK ;
> 
> 
> 
> lib libIDLstubs :
> src/generated/$(IDL_SOURCES)$(SK_DynSK).cc
> ;
> 
> 
> # -------------
> 
> the result of running omniidl with *.idl are 3 files: *.hh *SK.cc and
> *DynSK.cc
> 
> when using the Jamfile above I see that the 3 files are generated if
> needed, but the generated files are not compiled and hence the library
> is not built. Of course, a second to bjam will compile the generated
> files and build the library. Am I missing something or am I way off
> trying to achive what I want using the above?
> 
> there are a couple of constraints:
> 
> * the generated source files have extensions .hh and .cc (this is due
> to omniidl; you can instruct it to use .hpp and .cpp, but then it
> assumes that all generated header files have .hpp extensions... which
> is not the case for generated header files I have no control over)
> 
> * de IDL files are placed in ../idl/*
> The jam files as shown above give problems when I do a bjam in another
> directory which relies on the project directory holding the Jamfile
> shown above: "don't know how to make ../idl/Test.idl". It seems that
> the relative ../idl path in "this" project is also assumed to be
> relative in the "other" project.
> 
> any help appreciated...
> 
> renej