Re: generated (mutiple) files with omniidl

From: renej_frog (renej.frog_at_[hidden])
Date: 2004-03-21 09:12:01

--- In jamboost_at_[hidden], Christopher Currie <Christopher_at_C...>
wrote:
> 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 ;
> 
that was the approach that was suggested as reply on my previous post
and that worked for a "local" project; I have multiple projects that
need eachothers generated header files

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

I alread was afraid of that... and I definitely need the generated
header files to be accesible by other projects, easy to find, and
installable, and...

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

anyway, although I/we keep using Boost.Build for our underlying
boost-like libraries, I switched to SCons last night for the libraries
(those needing this omniidle stuff) that are to be used by a number
of developers. Within an hour I had everything set up and running and
I think that for those developers SCons is much easier to comprehend
and extend. Those developers are doing their first steps in the world
of c++/OO/etc, so I think Boost.Build is too much right now (no
offense ;-). The boost-like parts (nurbs, route planning, etc) are
based on Boost.Build and will be; they are maintained by other developers.

thanks,

renej 

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