Re: generated (mutiple) files with omniidl

From: renej_frog (renej.frog_at_[hidden])
Date: 2004-03-23 04:20:02

--- In jamboost_at_[hidden], Vladimir Prus <ghost_at_c...> wrote:
> renej_frog wrote:
> 
> > 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.
> 
> Is there any change you'll send (either to list, or to me
personally), the 
> SCons files so that we can see what approach worked better for you?

The following is used for generating the stubs from IDL files:

# --- SConscript ---
import glob, os, os.path

Import('env')

import idl

# get all idl files 

idl_files = glob.glob('../idl/Test/*.idl')
# generate stubs with builder
idl.generate_stubs(env, idl_files, 'include/Test')

# Build Test library
env.BuildDir('build/generated', 'src/generated', duplicate=0)
src = idl.generated_sources(idl_files, 'build/generated')
env.SharedLibrary('build/generated/Test', src) 

# ---

the idl.* functions hide the use of map(lambda:...) icm with
os.path.join/splitext/etc

the idl.generate_stubs is the following:

def generate_stubs(env, idl_files, hdr_path, hdr_ext=default_hdr_ext):
for f in idl_files:
env.IDL(header_file(f, hdr_path, hdr_ext), f)

and env.IDL is a SCons Builder added to the SCons env(ironment) and as
action it does call omniidl and moves the generated header files to
the specified directory.

It is probably only because I speak python as a second/third language
and not [b]jam that I have this working in little time. I I had more
time to spent boost.build could be used (it was initially our choice),
but since me and another guy are the only ones with some experience
with it and the other developers totally not, we'll be using scons for
now.
Since it is python-based and our developers have (some) experience
with python, it is possible to let other developers add functionality
to the build system. Seperate software libraries by me and the other
guy are using boost.build.
If our developers had the need for something similar to QT support and
needed to come up with stuff like in tools/qt.jam, I don't think
they'd be friendly to me anymore ;-) It's simply a matter of
experience/skills... and time, of course

renej

> 
> Thanks in advance,
> Volodya