I'd like to start breaking down SConstruct into several smaller SConscript 
files, the idea being that it should be easier to maintain. The change should 
be done incrementally, so that the build system doesn't block any kind of 
work (eg, having to wait for a full transition to add a new opcode).

To accomplish this, one would have to explicitly export and import variables 
across the different files (if done right, the SConstruct would be the only 
one that would export variables, and the SConscripts would import only the 
variables they need).
However, there are a few utility functions that are used across all of 
SConstruct, and functions can't be exported. I see 3 ways out of this 
problem:

 1. Define the functions in all files that need them.
 2. Define a module that contains all the functions and is imported by all
    SConscripts and SConstruct.
 3. Define a class in SConstruct that contains all the functions, and then
    instantiate it and export that variable.

Of these options, 1 is pretty much a no-no, since it involves repeating the 
functions in different files; 2 is reasonable, but requires additional code 
to clean up python-compiled files; and 3 feels somewhat hackish, but should 
work. I'm inclined towards 3, but I'm not sure.

After this has been done, all targets should be easier to maintain, and maybe 
do other improvements should be easier to do as well (such as definining a 
target that builds the source package).

How would the files interact after this reworking? The main SConstruct file 
would export, among other things, the common environment, the options object 
and the configure context. Each file would then test for whatever it needs 
(yes, this involves repeated checks, but it doesn't matter because they are 
cached) and act accordingly (build targets, etc). They should also take care 
of installing files where and when necessary. Defining options is also the 
responsability of each SConscript, unless an option involves several 
SConscripts, in which case it should be defined in SConstruct.

Is it OK if I go ahead with this? Any comments (specially on what to do about 
utility functions)?
Note that this will probably take some time to finish, so probably a couple of 
csound versions would have a relatively inconsistent system (some stuff in 
SConscripts, other stuff in SConstruct).

-- 
Felipe Sateler