Re: [jamboost] Re: What is the point of project-root.jam/Jamroot?

From: Steven Knight (knight_at_[hidden])
Date: 2004-12-30 17:23:33

Hi Volodya--

> > > But, you can't name subsidiary config file SConstruct, right? In other
> > > words, can you write:
> > >
> > > SConscirpt("d/SConstruct")
> > >
> > > and have everything work?
> >
> > Sure, you could, but there are some caveats.
> >
> > When invoked from the d/ subdirectory, SCons would, of course, think
> > that was the top of the tree. This would mean you couldn't rely on an
> > environment (or other variable) passed from a higher-layer SConstruct
> > file, so you'd have to write each SConstruct file to be self-contained
> > (or use some common Python modules or something to share logic).
> >
> > You'd have to use TargetSignatures('content') everywhere. That will give
> > you consistent signatures regardless of whether the file (like a library)
> > is a source in one build (because you're only linking against it) and
> > a target in another build (because you're building it *and* linking
> > against it). By default, SCons uses a "build signature" for targets
> > that consists of the signatures of all its consistuent source files,
> > and the command/action used to build it, which is more efficient than
> > re-scanning the target's contents.
> >
> > Last, you'd definitely want to use the current default behavior of a
> > separate .sconsign file in each directory, no global database file for
> > all of the build's signatures. I mention this because we may be changing
> > the default behavior to use the global file, which is friendlier for
> > most builds. An explicit SConsignFile(None) will specify the existing
> > .sconsign-per-directory behavior regardless of whether we change the
> > default.
> 
> Hmm.. quite a list of caveats. 

Not as bad as it may seem at first glance.

The last behavior described (SConsignFile(None)) is the current default
anyway, so you actually don't need to configure this explicitly right now,
and only will if we change the default behavior.

The second (TargetSignatures('content')) is a long-supported option
that lets SCons "short-circuit" downstream rebuilds if a target file
is re-built to the exact same file as the previous version. It's not
the default because normally your source file signatures provide enough
information.

The first listed item (autonomous SConstruct files) is simply what
you'd have to do if you want to execute "scons" independently from
each subdirectory--which I presume is why you want to have a file named
"SConstruct" in each one. If you don't--that is, if you still plan to
always execute "scons" from the top-level directory--you don't even need
to worry about this. (Note that this really isn't different than what
you have to do with Makefiles in a tree--you either have to "include"
rules from some central location, or you have to have Makefiles higher
in the tree pass things in the environment when they execute subsidiary
Makefiles.)

> > Note that I haven't tried such a configuration (SConstruct in each
> > directory) myself, though, so there may be other snags, but I'd be glad
> > to help figure them out if you wanted to try to make a configuration
> > like this work.
> 
> Actually, I've tried to figure out if using the same name over the tree is a 
> officially supported thing in SCons.

It depends on what you mean by "officially." The behavior necessary
to make it work (specifically TargetSignature('content')) is not the
default, but the tools are all there to set up your build this way.
Personally, I'd say, "Yes, it's supported," (or is supposed to be).
If you have something else in mind that would make "official" support
more natural, let me know.

> Seems like no user wanted this, right?

People have asked about it, and I've never *heard* any complaints that it
can't be done, so I've always assumed that someone out there has figured
out how to set up their build in this fashion. There's certainly no
reason that I know of why it should be impossible.

--SK