Hi Felipe,

I think this would be very useful work, but also have a hard time
visualizing at the moment.  I think it might be useful if you were
commit your work early but under a different name, SConstruct2
perhaps, so that we could see in code what you are working on and also
to see how this would impact development going forward.  Plus we could
switch between the current build file and the SConstruct2 file using
-f, which would be good for testing.

Are you planning SConscript files for each library then?  (If so, I
think that would be a very good thing.)

Thanks,
steven

On Wed, Mar 26, 2008 at 4:32 PM, Felipe Sateler <fsateler@gmail.com> wrote:
> 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
>
> -------------------------------------------------------------------------
>  Check out the new SourceForge.net Marketplace.
>  It's the best place to buy or sell services for
>  just about anything Open Source.
>  http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
>  Csound-devel mailing list
>  Csound-devel@lists.sourceforge.net
>  https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net