Re: [scons-devel] SCons BOF at O'Reilly OSCon 2003

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-06-17 09:42:13

Steven Knight wrote:

> > I always imagined that many features might end up being translated
> > into Environment settings, but I guess another possibility is that we
> > just bypass the Environment so that its "smarts" don't get in the way
> >
> > :(.
>
> Hmm, maybe I gave you the wrong impression. Environments are actually
> pretty dumb, they're basically just dictionaries of values that get
> plugged in to how you build things. They're also *the* way to interact
> with the SCons build engine.

Uhmm... if Environment is dump, then it looks very similiar to our 
property-set class. If needed, we could establish 1-1 mapping from property 
values to variables in environment.

So, at least in theory we can convert property-set to environment and then 
attach that environment to a Node. 

> > That won't happen except in special cases. In general there are
> > differences between how libraries and their dependents need to be
> > built. This is just a mechanism for propagating the known required
> > similarities.
>
> Cool, so your interface would probably just have to track how you want
> them propagated, and then set up Environments appropriately.

Yep, that's similiar to what I say above.

> Builders have a 'src_builder' attribute that can be set to one or
> more other Builders that can be used to generate input source files.
> Builders also have 'suffix' and 'src_suffix' attributes that can be set
> to the target and (list of) source file suffixes.

... 

Hmm... that seems very much like our 'generators' mechanism. I'd say that
we could benefit a lot from discussing both scheme and Dave's prototype, too.
Need to look at Builder.py one more time...

> > That was just an example. There are lots of other common options,
> > such as enabling/disabling debug symbols, optimizations, ... I think
> > Volodya's question is whether there's a general framework for handling
> > these things.
>
> Yes, there is a framwork for this.
>
> We have a separate module for each of the tools that we support,
> each module with two interface functions: one searches for the tool
> and returns a value that says, "Yes, they have compiler X installed
> in a PATH that this Environment can get to;" the other actually
> initializes an Environment with all of the appropriate values so that
> the Environment can use the tool, creating any necessary Builders or
> doing anything else that's required to set up things properly.

I think Dave has explained what we meant in a followup. I can only add that 
toolsets would be a complex thing if Boost.Build will use SCons as backend.
For one thing, we very much like the mechanism for translating properties
into compiler flags. For other thing, it's better to integrate with Scons 
tools handling: yes, we can generate command like options ourself, and just 
pass it via environment, but that non optimal, since SCons has some code for 
toolset already.

> (BTW, are you guys aware that Ralf W. Grosse-Kunstleve is already using
> or shipping Boost, I believe, with an SCons-based build system for
> cctbx, his Computational Crystallography ToolBox? I guess he has about
> twenty lines of Python code that parse up the .jam or .bjam or whatever
> files and turn them into calls into the SCons build engine. Might be a
> useful starting point to look at how someone else has done some of the
> basic stuff.)

Need to look. Since Python version of Boost.Build is only distant plan for 
now, we'd have a lot of Jam code by the time it works. Another alternative I 
was thinking about was extending Python with Jam. So, you'd have Python 
function "compile_jam_file", or something.

- Volodya

>
> --SK