I agree with Steven that keeping the old SConstruct going for the time being 
is a good idea.

And I certainly agree that the build system needs refactoring!

Regards,
Mike

----- Original Message ----- 
From: "Steven Yi" 
To: "Developer discussions" 
Sent: Wednesday, March 26, 2008 7:58 PM
Subject: Re: [Cs-dev] Build system refactoring


> 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  
> 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
> 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