I think this is a good idea, to not release binaries and rely on packages 
instead.

The current version of SCons has a "Package" target that presumably could be 
used to create packages for Debian/Ubuntu, and perhaps other systems as 
well. This could become part of the regular SConstruct file. I am greatly 
thankful for the existence of the Debian packages and I think that it has 
helped keep Csound going with Linux people, but I worry that keeping the 
package maintenance separate may be creating problems with patches that 
diverge.

Is anyone using the "new" SConstruct2 file to build Csound? If not, I will 
remove the file from CVS.

The existing SConstruct file could be improved, and this is what I think we 
should do. We can create functions in SConstruct for building opcodes, 
shared libraries, SWIG interfaces, static libraries, binaries, etc, and then 
call these for each target. These functions should of course be customized 
for each target operating system. Some of this actually has been done. So as 
not to break the existing logic in SConstruct, these functions should be 
called AFTER platform identification:

if getPlatform() == 'win':
    buildWin32Opcode('myopcode', myopcodesources)
elif getPlatform() == 'darwin':
    #existing code, until somebody writes buildDarwinOpcode(), which I don't 
know how to do.
elif getPlatform() == 'linux':
    buildLinuxOpcode('myopcode', myopcodesources)

Your thoughts?

Regards,
Mike

----- Original Message ----- 
From: "Victor Lazzarini" 
To: 
Sent: Sunday, February 21, 2010 8:36 AM
Subject: [Csnd] Re: Re: Re: Re: sloppy packaging


> My suggestion is not to release binaries for Linux. Leave them for 
> distributions (Fedora, Debian, etc). Maybe the release of binaries  raises 
> too many expectations, and it is not possible to attend all of  them, 
> given the diversity of distributions and systems. Or label them 
> explicitely: 'suse binaries' etc..
>
> Victor
>
> On 21 Feb 2010, at 13:27, john ffitch wrote:
>
>>> Aren't release candidates supposed to "just work" at that point?
>>
>> The problem is that it did for me.  I use Csound myself for what I
>> call music, and if it did not work it would not be released.  The
>> problem is your definition of "work".  I do not use MIDI or realtime
>> much, so I rely on others to test that.  We have used a RC system in
>> the past and it increased the amount of work and had no effect on bug
>> finding.
>>  I am open to suggestions, and especially positive ones.
>>
>> ==John ffitch
>> Sorry for any delay; unplanned I have been away for a week.
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  "unsubscribe 
>> csound"
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
> csound"
>