The inadvertent bugs in 5.12 seem almost settled.  Did we ought to
release a 5.13 (or a 5.12.5) soonish?  
  I have added some more defensive code in ftload/ftsave, and there is
still the question as to whether we should allow a-rate multiple
assigns.  There is also the (a?b:c) construct in the new parser.

I was not very happy with the beta-release we did earlier as it
involved all packagers doing the thing twice.  And there is the ongoing
Linux distribution problem -- in another large cross-platform project
we distributed many (about 6 I think) sets of .o files and a script
to try them all until one version linked.  I would rather not do that
again!

==John ffitch

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I'm deeply involved in trying to solve the problem of portmidi on OSX.  
But it's just being a headache,
I really don't know where the problem is. It's not in the pmidi.c  
module or in the portmidi library itself,
the crash seems to come from within the csound library. I need some  
help here.

Until this is sorted, I am not keen on releasing anything.

Victor


On 1 Mar 2010, at 15:05, jpff wrote:

> The inadvertent bugs in 5.12 seem almost settled.  Did we ought to
> release a 5.13 (or a 5.12.5) soonish?
>  I have added some more defensive code in ftload/ftsave, and there is
> still the question as to whether we should allow a-rate multiple
> assigns.  There is also the (a?b:c) construct in the new parser.
>
> I was not very happy with the beta-release we did earlier as it
> involved all packagers doing the thing twice.  And there is the  
> ongoing
> Linux distribution problem -- in another large cross-platform project
> we distributed many (about 6 I think) sets of .o files and a script
> to try them all until one version linked.  I would rather not do that
> again!
>
> ==John ffitch
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Well, the whole point of a beta is to release it twice, once (or
possibly more) to get feedback and then a final release.  Following
such a practice (or an unstable/stable release) would have mitigated a
lot of the issues with 5.12.

As for Linux distro, I think we should not do a release of linux
binaries.  I think it causes more harm than good, frankly, as really
it might only work on the distro it was built on. I think we should
consider either putting up packages in debs and RPMS (could do both
Fedora and SuSe RPM's) or creating a repo for them.

On Mon, Mar 1, 2010 at 10:05 AM, jpff  wrote:
> The inadvertent bugs in 5.12 seem almost settled.  Did we ought to
> release a 5.13 (or a 5.12.5) soonish?
>  I have added some more defensive code in ftload/ftsave, and there is
> still the question as to whether we should allow a-rate multiple
> assigns.  There is also the (a?b:c) construct in the new parser.
>
> I was not very happy with the beta-release we did earlier as it
> involved all packagers doing the thing twice.  And there is the ongoing
> Linux distribution problem -- in another large cross-platform project
> we distributed many (about 6 I think) sets of .o files and a script
> to try them all until one version linked.  I would rather not do that
> again!
>
> ==John ffitch
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

As I have mentioned before, SCons supports Linux packages as a target
in SConstruct files.

I repeat my proposal that we move the good work that people have done
on the Debian package into SConstruct, insofar as that is possible (I
am not up to speed on what it takes to get a built package into the
official repositories).

It would be helpful to have all the bugs and other issues related to
the packages in the main build file, and packages that we could build
could easily be hosted on SourceForge and cSounds.com. Also, people
who wanted to build and install from scratch would probably find this
an easier and more complete method.

Regards,
Mike

On Mon, Mar 1, 2010 at 10:18 AM, Steven Yi  wrote:
> Well, the whole point of a beta is to release it twice, once (or
> possibly more) to get feedback and then a final release.  Following
> such a practice (or an unstable/stable release) would have mitigated a
> lot of the issues with 5.12.
>
> As for Linux distro, I think we should not do a release of linux
> binaries.  I think it causes more harm than good, frankly, as really
> it might only work on the distro it was built on. I think we should
> consider either putting up packages in debs and RPMS (could do both
> Fedora and SuSe RPM's) or creating a repo for them.
>
> On Mon, Mar 1, 2010 at 10:05 AM, jpff  wrote:
>> The inadvertent bugs in 5.12 seem almost settled.  Did we ought to
>> release a 5.13 (or a 5.12.5) soonish?
>>  I have added some more defensive code in ftload/ftsave, and there is
>> still the question as to whether we should allow a-rate multiple
>> assigns.  There is also the (a?b:c) construct in the new parser.
>>
>> I was not very happy with the beta-release we did earlier as it
>> involved all packagers doing the thing twice.  And there is the ongoing
>> Linux distribution problem -- in another large cross-platform project
>> we distributed many (about 6 I think) sets of .o files and a script
>> to try them all until one version linked.  I would rather not do that
>> again!
>>
>> ==John ffitch
>>
>> ------------------------------------------------------------------------------
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

The problem is not so much with what format the binaries are
distributed, but how you produced them. To take an example, I saw from
recent comments in the list that the linux binaries were linked
against liblo7, which is not yet available in debian! The whole point
is to make the libraries used match the end users'.  I don't think
there is a sensible solution to that outside distros. Clearly
distributing the .o files and linking at each system is a royal pain.

On Mon, Mar 1, 2010 at 12:35, Michael Gogins  wrote:
> As I have mentioned before, SCons supports Linux packages as a target
> in SConstruct files.
>
> I repeat my proposal that we move the good work that people have done
> on the Debian package into SConstruct, insofar as that is possible (I
> am not up to speed on what it takes to get a built package into the
> official repositories).
>
> It would be helpful to have all the bugs and other issues related to
> the packages in the main build file, and packages that we could build
> could easily be hosted on SourceForge and cSounds.com. Also, people
> who wanted to build and install from scratch would probably find this
> an easier and more complete method.
>
> Regards,
> Mike
>
> On Mon, Mar 1, 2010 at 10:18 AM, Steven Yi  wrote:
>> Well, the whole point of a beta is to release it twice, once (or
>> possibly more) to get feedback and then a final release.  Following
>> such a practice (or an unstable/stable release) would have mitigated a
>> lot of the issues with 5.12.
>>
>> As for Linux distro, I think we should not do a release of linux
>> binaries.  I think it causes more harm than good, frankly, as really
>> it might only work on the distro it was built on. I think we should
>> consider either putting up packages in debs and RPMS (could do both
>> Fedora and SuSe RPM's) or creating a repo for them.
>>
>> On Mon, Mar 1, 2010 at 10:05 AM, jpff  wrote:
>>> The inadvertent bugs in 5.12 seem almost settled.  Did we ought to
>>> release a 5.13 (or a 5.12.5) soonish?
>>>  I have added some more defensive code in ftload/ftsave, and there is
>>> still the question as to whether we should allow a-rate multiple
>>> assigns.  There is also the (a?b:c) construct in the new parser.
>>>
>>> I was not very happy with the beta-release we did earlier as it
>>> involved all packagers doing the thing twice.  And there is the ongoing
>>> Linux distribution problem -- in another large cross-platform project
>>> we distributed many (about 6 I think) sets of .o files and a script
>>> to try them all until one version linked.  I would rather not do that
>>> again!
>>>
>>> ==John ffitch
>>>
>>> ------------------------------------------------------------------------------
>>> Download Intel® Parallel Studio Eval
>>> Try the new software tools for yourself. Speed compiling, find bugs
>>> proactively, and fine-tune applications for parallel performance.
>>> See why Intel Parallel Studio got high marks during beta.
>>> http://p.sf.net/sfu/intel-sw-dev
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>> ------------------------------------------------------------------------------
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



-- 

Saludos,
Felipe Sateler

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://

Well, then SConstruct should target libraries available from standard
distributions, right? At least, as an option.

Regards,
Mike

On Mon, Mar 1, 2010 at 10:40 AM, Felipe Sateler  wrote:
> The problem is not so much with what format the binaries are
> distributed, but how you produced them. To take an example, I saw from
> recent comments in the list that the linux binaries were linked
> against liblo7, which is not yet available in debian! The whole point
> is to make the libraries used match the end users'.  I don't think
> there is a sensible solution to that outside distros. Clearly
> distributing the .o files and linking at each system is a royal pain.
>
> On Mon, Mar 1, 2010 at 12:35, Michael Gogins  wrote:
>> As I have mentioned before, SCons supports Linux packages as a target
>> in SConstruct files.
>>
>> I repeat my proposal that we move the good work that people have done
>> on the Debian package into SConstruct, insofar as that is possible (I
>> am not up to speed on what it takes to get a built package into the
>> official repositories).
>>
>> It would be helpful to have all the bugs and other issues related to
>> the packages in the main build file, and packages that we could build
>> could easily be hosted on SourceForge and cSounds.com. Also, people
>> who wanted to build and install from scratch would probably find this
>> an easier and more complete method.
>>
>> Regards,
>> Mike
>>
>> On Mon, Mar 1, 2010 at 10:18 AM, Steven Yi  wrote:
>>> Well, the whole point of a beta is to release it twice, once (or
>>> possibly more) to get feedback and then a final release.  Following
>>> such a practice (or an unstable/stable release) would have mitigated a
>>> lot of the issues with 5.12.
>>>
>>> As for Linux distro, I think we should not do a release of linux
>>> binaries.  I think it causes more harm than good, frankly, as really
>>> it might only work on the distro it was built on. I think we should
>>> consider either putting up packages in debs and RPMS (could do both
>>> Fedora and SuSe RPM's) or creating a repo for them.
>>>
>>> On Mon, Mar 1, 2010 at 10:05 AM, jpff  wrote:
>>>> The inadvertent bugs in 5.12 seem almost settled.  Did we ought to
>>>> release a 5.13 (or a 5.12.5) soonish?
>>>>  I have added some more defensive code in ftload/ftsave, and there is
>>>> still the question as to whether we should allow a-rate multiple
>>>> assigns.  There is also the (a?b:c) construct in the new parser.
>>>>
>>>> I was not very happy with the beta-release we did earlier as it
>>>> involved all packagers doing the thing twice.  And there is the ongoing
>>>> Linux distribution problem -- in another large cross-platform project
>>>> we distributed many (about 6 I think) sets of .o files and a script
>>>> to try them all until one version linked.  I would rather not do that
>>>> again!
>>>>
>>>> ==John ffitch
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Download Intel® Parallel Studio Eval
>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>> proactively, and fine-tune applications for parallel performance.
>>>> See why Intel Parallel Studio got high marks during beta.
>>>> http://p.sf.net/sfu/intel-sw-dev
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Download Intel® Parallel Studio Eval
>>> Try the new software tools for yourself. Speed compiling, find bugs
>>> proactively, and fine-tune applications for parallel performance.
>>> See why Intel Parallel Studio got high marks during beta.
>>> http://p.sf.net/sfu/intel-sw-dev
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>> ------------------------------------------------------------------------------
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
>
>
> --
>
> Saludos,
> Felipe Sateler
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Sconstruct already does that. The problem is that there is no way to
guarantee that the system libraries available at build time will be the
same ones present in the user's system at runtime. To use the liblo
example:
Currently, in debian we have liblo version 0.23. So if we build a binary
distribution for debian unstable, the resulting binaries end up linked
to liblo.so.0. However, liblo 0.26 will be uploaded some time soonish,
which has bumped the SONAME. So, in a couple of months, users will no
longer have liblo.so.0, but liblo.so.7. How can we detect this outside
the debian infrastructure?

On Mon, 2010-03-01 at 10:44 -0500, Michael Gogins wrote:
> Well, then SConstruct should target libraries available from standard
> distributions, right? At least, as an option.
> 
> Regards,
> Mike
> 
> On Mon, Mar 1, 2010 at 10:40 AM, Felipe Sateler  wrote:
> > The problem is not so much with what format the binaries are
> > distributed, but how you produced them. To take an example, I saw from
> > recent comments in the list that the linux binaries were linked
> > against liblo7, which is not yet available in debian! The whole point
> > is to make the libraries used match the end users'.  I don't think
> > there is a sensible solution to that outside distros. Clearly
> > distributing the .o files and linking at each system is a royal pain.
> >
> > On Mon, Mar 1, 2010 at 12:35, Michael Gogins  wrote:
> >> As I have mentioned before, SCons supports Linux packages as a target
> >> in SConstruct files.
> >>
> >> I repeat my proposal that we move the good work that people have done
> >> on the Debian package into SConstruct, insofar as that is possible (I
> >> am not up to speed on what it takes to get a built package into the
> >> official repositories).
> >>
> >> It would be helpful to have all the bugs and other issues related to
> >> the packages in the main build file, and packages that we could build
> >> could easily be hosted on SourceForge and cSounds.com. Also, people
> >> who wanted to build and install from scratch would probably find this
> >> an easier and more complete method.
> >>
> >> Regards,
> >> Mike
> >>
> >> On Mon, Mar 1, 2010 at 10:18 AM, Steven Yi  wrote:
> >>> Well, the whole point of a beta is to release it twice, once (or
> >>> possibly more) to get feedback and then a final release.  Following
> >>> such a practice (or an unstable/stable release) would have mitigated a
> >>> lot of the issues with 5.12.
> >>>
> >>> As for Linux distro, I think we should not do a release of linux
> >>> binaries.  I think it causes more harm than good, frankly, as really
> >>> it might only work on the distro it was built on. I think we should
> >>> consider either putting up packages in debs and RPMS (could do both
> >>> Fedora and SuSe RPM's) or creating a repo for them.
> >>>
> >>> On Mon, Mar 1, 2010 at 10:05 AM, jpff  wrote:
> >>>> The inadvertent bugs in 5.12 seem almost settled.  Did we ought to
> >>>> release a 5.13 (or a 5.12.5) soonish?
> >>>>  I have added some more defensive code in ftload/ftsave, and there is
> >>>> still the question as to whether we should allow a-rate multiple
> >>>> assigns.  There is also the (a?b:c) construct in the new parser.
> >>>>
> >>>> I was not very happy with the beta-release we did earlier as it
> >>>> involved all packagers doing the thing twice.  And there is the ongoing
> >>>> Linux distribution problem -- in another large cross-platform project
> >>>> we distributed many (about 6 I think) sets of .o files and a script
> >>>> to try them all until one version linked.  I would rather not do that
> >>>> again!
> >>>>
> >>>> ==John ffitch
> >>>>
> >>>> ------------------------------------------------------------------------------
> >>>> Download Intel® Parallel Studio Eval
> >>>> Try the new software tools for yourself. Speed compiling, find bugs
> >>>> proactively, and fine-tune applications for parallel performance.
> >>>> See why Intel Parallel Studio got high marks during beta.
> >>>> http://p.sf.net/sfu/intel-sw-dev
> >>>> _______________________________________________
> >>>> Csound-devel mailing list
> >>>> Csound-devel@lists.sourceforge.net
> >>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
> >>>>
> >>>
> >>> ------------------------------------------------------------------------------
> >>> Download Intel® Parallel Studio Eval
> >>> Try the new software tools for yourself. Speed compiling, find bugs
> >>> proactively, and fine-tune applications for parallel performance.
> >>> See why Intel Parallel Studio got high marks during beta.
> >>> http://p.sf.net/sfu/intel-sw-dev
> >>> _______________________________________________
> >>> Csound-devel mailing list
> >>> Csound-devel@lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/csound-devel
> >>>
> >>
> >>
> >>
> >> --
> >> Michael Gogins
> >> Irreducible Productions
> >> http://www.michael-gogins.com
> >> Michael dot Gogins at gmail dot com
> >>
> >> ------------------------------------------------------------------------------
> >> Download Intel® Parallel Studio Eval
> >> Try the new software tools for yourself. Speed compiling, find bugs
> >> proactively, and fine-tune applications for parallel performance.
> >> See why Intel Parallel Studio got high marks during beta.
> >> http://p.sf.net/sfu/intel-sw-dev
> >> _______________________________________________
> >> Csound-devel mailing list
> >> Csound-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
> >>
> >
> >
> >
> > --
> >
> > Saludos,
> > Felipe Sateler
> >
> > ------------------------------------------------------------------------------
> > Download Intel® Parallel Studio Eval
> > Try the new software tools for yourself. Speed compiling, find bugs
> > proactively, and fine-tune applications for parallel performance.
> > See why Intel Parallel Studio got high marks during beta.
> > http://p.sf.net/sfu/intel-sw-dev
> > _______________________________________________
> > Csound-devel mailing list
> > Csound-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/csound-devel
> >
> 
> 
> 

-- 
Saludos,
Felipe Sateler

Right, and can we not statically link against liblo? Or maybe we would
need to add a liblo deb if we maintain a repo?

On Mon, Mar 1, 2010 at 10:44 AM, Michael Gogins
 wrote:
> Well, then SConstruct should target libraries available from standard
> distributions, right? At least, as an option.
>
> Regards,
> Mike
>
> On Mon, Mar 1, 2010 at 10:40 AM, Felipe Sateler  wrote:
>> The problem is not so much with what format the binaries are
>> distributed, but how you produced them. To take an example, I saw from
>> recent comments in the list that the linux binaries were linked
>> against liblo7, which is not yet available in debian! The whole point
>> is to make the libraries used match the end users'.  I don't think
>> there is a sensible solution to that outside distros. Clearly
>> distributing the .o files and linking at each system is a royal pain.
>>
>> On Mon, Mar 1, 2010 at 12:35, Michael Gogins  wrote:
>>> As I have mentioned before, SCons supports Linux packages as a target
>>> in SConstruct files.
>>>
>>> I repeat my proposal that we move the good work that people have done
>>> on the Debian package into SConstruct, insofar as that is possible (I
>>> am not up to speed on what it takes to get a built package into the
>>> official repositories).
>>>
>>> It would be helpful to have all the bugs and other issues related to
>>> the packages in the main build file, and packages that we could build
>>> could easily be hosted on SourceForge and cSounds.com. Also, people
>>> who wanted to build and install from scratch would probably find this
>>> an easier and more complete method.
>>>
>>> Regards,
>>> Mike
>>>
>>> On Mon, Mar 1, 2010 at 10:18 AM, Steven Yi  wrote:
>>>> Well, the whole point of a beta is to release it twice, once (or
>>>> possibly more) to get feedback and then a final release.  Following
>>>> such a practice (or an unstable/stable release) would have mitigated a
>>>> lot of the issues with 5.12.
>>>>
>>>> As for Linux distro, I think we should not do a release of linux
>>>> binaries.  I think it causes more harm than good, frankly, as really
>>>> it might only work on the distro it was built on. I think we should
>>>> consider either putting up packages in debs and RPMS (could do both
>>>> Fedora and SuSe RPM's) or creating a repo for them.
>>>>
>>>> On Mon, Mar 1, 2010 at 10:05 AM, jpff  wrote:
>>>>> The inadvertent bugs in 5.12 seem almost settled.  Did we ought to
>>>>> release a 5.13 (or a 5.12.5) soonish?
>>>>>  I have added some more defensive code in ftload/ftsave, and there is
>>>>> still the question as to whether we should allow a-rate multiple
>>>>> assigns.  There is also the (a?b:c) construct in the new parser.
>>>>>
>>>>> I was not very happy with the beta-release we did earlier as it
>>>>> involved all packagers doing the thing twice.  And there is the ongoing
>>>>> Linux distribution problem -- in another large cross-platform project
>>>>> we distributed many (about 6 I think) sets of .o files and a script
>>>>> to try them all until one version linked.  I would rather not do that
>>>>> again!
>>>>>
>>>>> ==John ffitch
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Download Intel® Parallel Studio Eval
>>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>>> proactively, and fine-tune applications for parallel performance.
>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Download Intel® Parallel Studio Eval
>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>> proactively, and fine-tune applications for parallel performance.
>>>> See why Intel Parallel Studio got high marks during beta.
>>>> http://p.sf.net/sfu/intel-sw-dev
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>
>>>
>>>
>>> --
>>> Michael Gogins
>>> Irreducible Productions
>>> http://www.michael-gogins.com
>>> Michael dot Gogins at gmail dot com
>>>
>>> ------------------------------------------------------------------------------
>>> Download Intel® Parallel Studio Eval
>>> Try the new software tools for yourself. Speed compiling, find bugs
>>> proactively, and fine-tune applications for parallel performance.
>>> See why Intel Parallel Studio got high marks during beta.
>>> http://p.sf.net/sfu/intel-sw-dev
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>>
>>
>> --
>>
>> Saludos,
>> Felipe Sateler
>>
>> ------------------------------------------------------------------------------
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

We should statically link if possible.in such cases.

Regards,
Mike

On Mon, Mar 1, 2010 at 11:22 AM, Steven Yi  wrote:
> Right, and can we not statically link against liblo? Or maybe we would
> need to add a liblo deb if we maintain a repo?
>
> On Mon, Mar 1, 2010 at 10:44 AM, Michael Gogins
>  wrote:
>> Well, then SConstruct should target libraries available from standard
>> distributions, right? At least, as an option.
>>
>> Regards,
>> Mike
>>
>> On Mon, Mar 1, 2010 at 10:40 AM, Felipe Sateler  wrote:
>>> The problem is not so much with what format the binaries are
>>> distributed, but how you produced them. To take an example, I saw from
>>> recent comments in the list that the linux binaries were linked
>>> against liblo7, which is not yet available in debian! The whole point
>>> is to make the libraries used match the end users'.  I don't think
>>> there is a sensible solution to that outside distros. Clearly
>>> distributing the .o files and linking at each system is a royal pain.
>>>
>>> On Mon, Mar 1, 2010 at 12:35, Michael Gogins  wrote:
>>>> As I have mentioned before, SCons supports Linux packages as a target
>>>> in SConstruct files.
>>>>
>>>> I repeat my proposal that we move the good work that people have done
>>>> on the Debian package into SConstruct, insofar as that is possible (I
>>>> am not up to speed on what it takes to get a built package into the
>>>> official repositories).
>>>>
>>>> It would be helpful to have all the bugs and other issues related to
>>>> the packages in the main build file, and packages that we could build
>>>> could easily be hosted on SourceForge and cSounds.com. Also, people
>>>> who wanted to build and install from scratch would probably find this
>>>> an easier and more complete method.
>>>>
>>>> Regards,
>>>> Mike
>>>>
>>>> On Mon, Mar 1, 2010 at 10:18 AM, Steven Yi  wrote:
>>>>> Well, the whole point of a beta is to release it twice, once (or
>>>>> possibly more) to get feedback and then a final release.  Following
>>>>> such a practice (or an unstable/stable release) would have mitigated a
>>>>> lot of the issues with 5.12.
>>>>>
>>>>> As for Linux distro, I think we should not do a release of linux
>>>>> binaries.  I think it causes more harm than good, frankly, as really
>>>>> it might only work on the distro it was built on. I think we should
>>>>> consider either putting up packages in debs and RPMS (could do both
>>>>> Fedora and SuSe RPM's) or creating a repo for them.
>>>>>
>>>>> On Mon, Mar 1, 2010 at 10:05 AM, jpff  wrote:
>>>>>> The inadvertent bugs in 5.12 seem almost settled.  Did we ought to
>>>>>> release a 5.13 (or a 5.12.5) soonish?
>>>>>>  I have added some more defensive code in ftload/ftsave, and there is
>>>>>> still the question as to whether we should allow a-rate multiple
>>>>>> assigns.  There is also the (a?b:c) construct in the new parser.
>>>>>>
>>>>>> I was not very happy with the beta-release we did earlier as it
>>>>>> involved all packagers doing the thing twice.  And there is the ongoing
>>>>>> Linux distribution problem -- in another large cross-platform project
>>>>>> we distributed many (about 6 I think) sets of .o files and a script
>>>>>> to try them all until one version linked.  I would rather not do that
>>>>>> again!
>>>>>>
>>>>>> ==John ffitch
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Download Intel® Parallel Studio Eval
>>>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>>>> proactively, and fine-tune applications for parallel performance.
>>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>>> _______________________________________________
>>>>>> Csound-devel mailing list
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Download Intel® Parallel Studio Eval
>>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>>> proactively, and fine-tune applications for parallel performance.
>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Michael Gogins
>>>> Irreducible Productions
>>>> http://www.michael-gogins.com
>>>> Michael dot Gogins at gmail dot com
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Download Intel® Parallel Studio Eval
>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>> proactively, and fine-tune applications for parallel performance.
>>>> See why Intel Parallel Studio got high marks during beta.
>>>> http://p.sf.net/sfu/intel-sw-dev
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> Saludos,
>>> Felipe Sateler
>>>
>>> ------------------------------------------------------------------------------
>>> Download Intel® Parallel Studio Eval
>>> Try the new software tools for yourself. Speed compiling, find bugs
>>> proactively, and fine-tune applications for parallel performance.
>>> See why Intel Parallel Studio got high marks during beta.
>>> http://p.sf.net/sfu/intel-sw-dev
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>> ------------------------------------------------------------------------------
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

As a downstream distributor, I would advise against distributing
liblo, either by statically linking or by a separate package. The
problem is that security or other bug fixes would require you to
provide a new package if csound is to take advantage of it.
In debian we believe that the action of distributing to users is
better done by distributions rather than upstream developers. Of
course, sometimes it happens that the package cannot be updated for
one reason or another. But synchronizing all the used libraries is
much better done by the people that actually build the environment.

On Mon, Mar 1, 2010 at 13:22, Steven Yi  wrote:
> Right, and can we not statically link against liblo? Or maybe we would
> need to add a liblo deb if we maintain a repo?
>
> On Mon, Mar 1, 2010 at 10:44 AM, Michael Gogins
>  wrote:
>> Well, then SConstruct should target libraries available from standard
>> distributions, right? At least, as an option.
>>
>> Regards,
>> Mike
>>
>> On Mon, Mar 1, 2010 at 10:40 AM, Felipe Sateler  wrote:
>>> The problem is not so much with what format the binaries are
>>> distributed, but how you produced them. To take an example, I saw from
>>> recent comments in the list that the linux binaries were linked
>>> against liblo7, which is not yet available in debian! The whole point
>>> is to make the libraries used match the end users'.  I don't think
>>> there is a sensible solution to that outside distros. Clearly
>>> distributing the .o files and linking at each system is a royal pain.
>>>
>>> On Mon, Mar 1, 2010 at 12:35, Michael Gogins  wrote:
>>>> As I have mentioned before, SCons supports Linux packages as a target
>>>> in SConstruct files.
>>>>
>>>> I repeat my proposal that we move the good work that people have done
>>>> on the Debian package into SConstruct, insofar as that is possible (I
>>>> am not up to speed on what it takes to get a built package into the
>>>> official repositories).
>>>>
>>>> It would be helpful to have all the bugs and other issues related to
>>>> the packages in the main build file, and packages that we could build
>>>> could easily be hosted on SourceForge and cSounds.com. Also, people
>>>> who wanted to build and install from scratch would probably find this
>>>> an easier and more complete method.
>>>>
>>>> Regards,
>>>> Mike
>>>>
>>>> On Mon, Mar 1, 2010 at 10:18 AM, Steven Yi  wrote:
>>>>> Well, the whole point of a beta is to release it twice, once (or
>>>>> possibly more) to get feedback and then a final release.  Following
>>>>> such a practice (or an unstable/stable release) would have mitigated a
>>>>> lot of the issues with 5.12.
>>>>>
>>>>> As for Linux distro, I think we should not do a release of linux
>>>>> binaries.  I think it causes more harm than good, frankly, as really
>>>>> it might only work on the distro it was built on. I think we should
>>>>> consider either putting up packages in debs and RPMS (could do both
>>>>> Fedora and SuSe RPM's) or creating a repo for them.
>>>>>
>>>>> On Mon, Mar 1, 2010 at 10:05 AM, jpff  wrote:
>>>>>> The inadvertent bugs in 5.12 seem almost settled.  Did we ought to
>>>>>> release a 5.13 (or a 5.12.5) soonish?
>>>>>>  I have added some more defensive code in ftload/ftsave, and there is
>>>>>> still the question as to whether we should allow a-rate multiple
>>>>>> assigns.  There is also the (a?b:c) construct in the new parser.
>>>>>>
>>>>>> I was not very happy with the beta-release we did earlier as it
>>>>>> involved all packagers doing the thing twice.  And there is the ongoing
>>>>>> Linux distribution problem -- in another large cross-platform project
>>>>>> we distributed many (about 6 I think) sets of .o files and a script
>>>>>> to try them all until one version linked.  I would rather not do that
>>>>>> again!
>>>>>>
>>>>>> ==John ffitch
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Download Intel® Parallel Studio Eval
>>>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>>>> proactively, and fine-tune applications for parallel performance.
>>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>>> _______________________________________________
>>>>>> Csound-devel mailing list
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Download Intel® Parallel Studio Eval
>>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>>> proactively, and fine-tune applications for parallel performance.
>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Michael Gogins
>>>> Irreducible Productions
>>>> http://www.michael-gogins.com
>>>> Michael dot Gogins at gmail dot com
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Download Intel® Parallel Studio Eval
>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>> proactively, and fine-tune applications for parallel performance.
>>>> See why Intel Parallel Studio got high marks during beta.
>>>> http://p.sf.net/sfu/intel-sw-dev
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> Saludos,
>>> Felipe Sateler
>>>
>>> ------------------------------------------------------------------------------
>>> Download Intel® Parallel Studio Eval
>>> Try the new software tools for yourself. Speed compiling, find bugs
>>> proactively, and fine-tune applications for parallel performance.
>>> See why Intel Parallel Studio got high marks during beta.
>>> http://p.sf.net/sfu/intel-sw-dev
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>> ------------------------------------------------------------------------------
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



-- 

Saludos,
Felipe Sateler

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.ne

Thanks Felipe. For something like this then, would the process be to
submit a package request for liblo?  (I do not have experience with
Debian's process)

Thanks!
steven

On Mon, Mar 1, 2010 at 11:41 AM, Felipe Sateler  wrote:
> As a downstream distributor, I would advise against distributing
> liblo, either by statically linking or by a separate package. The
> problem is that security or other bug fixes would require you to
> provide a new package if csound is to take advantage of it.
> In debian we believe that the action of distributing to users is
> better done by distributions rather than upstream developers. Of
> course, sometimes it happens that the package cannot be updated for
> one reason or another. But synchronizing all the used libraries is
> much better done by the people that actually build the environment.
>
> On Mon, Mar 1, 2010 at 13:22, Steven Yi  wrote:
>> Right, and can we not statically link against liblo? Or maybe we would
>> need to add a liblo deb if we maintain a repo?
>>
>> On Mon, Mar 1, 2010 at 10:44 AM, Michael Gogins
>>  wrote:
>>> Well, then SConstruct should target libraries available from standard
>>> distributions, right? At least, as an option.
>>>
>>> Regards,
>>> Mike
>>>
>>> On Mon, Mar 1, 2010 at 10:40 AM, Felipe Sateler  wrote:
>>>> The problem is not so much with what format the binaries are
>>>> distributed, but how you produced them. To take an example, I saw from
>>>> recent comments in the list that the linux binaries were linked
>>>> against liblo7, which is not yet available in debian! The whole point
>>>> is to make the libraries used match the end users'.  I don't think
>>>> there is a sensible solution to that outside distros. Clearly
>>>> distributing the .o files and linking at each system is a royal pain.
>>>>
>>>> On Mon, Mar 1, 2010 at 12:35, Michael Gogins  wrote:
>>>>> As I have mentioned before, SCons supports Linux packages as a target
>>>>> in SConstruct files.
>>>>>
>>>>> I repeat my proposal that we move the good work that people have done
>>>>> on the Debian package into SConstruct, insofar as that is possible (I
>>>>> am not up to speed on what it takes to get a built package into the
>>>>> official repositories).
>>>>>
>>>>> It would be helpful to have all the bugs and other issues related to
>>>>> the packages in the main build file, and packages that we could build
>>>>> could easily be hosted on SourceForge and cSounds.com. Also, people
>>>>> who wanted to build and install from scratch would probably find this
>>>>> an easier and more complete method.
>>>>>
>>>>> Regards,
>>>>> Mike
>>>>>
>>>>> On Mon, Mar 1, 2010 at 10:18 AM, Steven Yi  wrote:
>>>>>> Well, the whole point of a beta is to release it twice, once (or
>>>>>> possibly more) to get feedback and then a final release.  Following
>>>>>> such a practice (or an unstable/stable release) would have mitigated a
>>>>>> lot of the issues with 5.12.
>>>>>>
>>>>>> As for Linux distro, I think we should not do a release of linux
>>>>>> binaries.  I think it causes more harm than good, frankly, as really
>>>>>> it might only work on the distro it was built on. I think we should
>>>>>> consider either putting up packages in debs and RPMS (could do both
>>>>>> Fedora and SuSe RPM's) or creating a repo for them.
>>>>>>
>>>>>> On Mon, Mar 1, 2010 at 10:05 AM, jpff  wrote:
>>>>>>> The inadvertent bugs in 5.12 seem almost settled.  Did we ought to
>>>>>>> release a 5.13 (or a 5.12.5) soonish?
>>>>>>>  I have added some more defensive code in ftload/ftsave, and there is
>>>>>>> still the question as to whether we should allow a-rate multiple
>>>>>>> assigns.  There is also the (a?b:c) construct in the new parser.
>>>>>>>
>>>>>>> I was not very happy with the beta-release we did earlier as it
>>>>>>> involved all packagers doing the thing twice.  And there is the ongoing
>>>>>>> Linux distribution problem -- in another large cross-platform project
>>>>>>> we distributed many (about 6 I think) sets of .o files and a script
>>>>>>> to try them all until one version linked.  I would rather not do that
>>>>>>> again!
>>>>>>>
>>>>>>> ==John ffitch
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Download Intel® Parallel Studio Eval
>>>>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>>>>> proactively, and fine-tune applications for parallel performance.
>>>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>>>> _______________________________________________
>>>>>>> Csound-devel mailing list
>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Download Intel® Parallel Studio Eval
>>>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>>>> proactively, and fine-tune applications for parallel performance.
>>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>>> _______________________________________________
>>>>>> Csound-devel mailing list
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Michael Gogins
>>>>> Irreducible Productions
>>>>> http://www.michael-gogins.com
>>>>> Michael dot Gogins at gmail dot com
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Download Intel® Parallel Studio Eval
>>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>>> proactively, and fine-tune applications for parallel performance.
>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Saludos,
>>>> Felipe Sateler
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Download Intel® Parallel Studio Eval
>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>> proactively, and fine-tune applications for parallel performance.
>>>> See why Intel Parallel Studio got high marks during beta.
>>>> http://p.sf.net/sfu/intel-sw-dev
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>
>>>
>>>
>>> --
>>> Michael Gogins
>>> Irreducible Productions
>>> http://www.michael-gogins.com
>>> Michael dot Gogins at gmail dot com
>>>
>>> ------------------------------------------------------------------------------
>>> Download Intel® Parallel Studio Eval
>>> Try the new software tools for yourself. Speed compiling, find bugs
>>> proactively, and fine-tune applications for parallel performance.
>>> See why Intel Parallel Studio got high marks during beta.
>>> http://p.sf.net/sfu/intel-sw-dev
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>> ------------------------------------------------------------------------------
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
>
>
> --
>
> Saludos,
> Felipe Sateler
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

In the particular case of liblo, it is being handled right now. We got
approval to upload the 0.26 release just yesterday, so it will
hopefully be uploaded today or tomorrow.
In the general case, I believe the solution is to have an uptodate
csound in debian and ubuntu, so that users do not need to download
from the sourceforge page. I will try to coordinate myself with some
Ubuntu people to update csound in Ubuntu (and create the 5.12 package
too! Unless there is going to be a bugfix release now?).

On Mon, Mar 1, 2010 at 13:44, Steven Yi  wrote:
> Thanks Felipe. For something like this then, would the process be to
> submit a package request for liblo?  (I do not have experience with
> Debian's process)
>
> Thanks!
> steven
>
> On Mon, Mar 1, 2010 at 11:41 AM, Felipe Sateler  wrote:
>> As a downstream distributor, I would advise against distributing
>> liblo, either by statically linking or by a separate package. The
>> problem is that security or other bug fixes would require you to
>> provide a new package if csound is to take advantage of it.
>> In debian we believe that the action of distributing to users is
>> better done by distributions rather than upstream developers. Of
>> course, sometimes it happens that the package cannot be updated for
>> one reason or another. But synchronizing all the used libraries is
>> much better done by the people that actually build the environment.
>>
>> On Mon, Mar 1, 2010 at 13:22, Steven Yi  wrote:
>>> Right, and can we not statically link against liblo? Or maybe we would
>>> need to add a liblo deb if we maintain a repo?
>>>
>>> On Mon, Mar 1, 2010 at 10:44 AM, Michael Gogins
>>>  wrote:
>>>> Well, then SConstruct should target libraries available from standard
>>>> distributions, right? At least, as an option.
>>>>
>>>> Regards,
>>>> Mike
>>>>
>>>> On Mon, Mar 1, 2010 at 10:40 AM, Felipe Sateler  wrote:
>>>>> The problem is not so much with what format the binaries are
>>>>> distributed, but how you produced them. To take an example, I saw from
>>>>> recent comments in the list that the linux binaries were linked
>>>>> against liblo7, which is not yet available in debian! The whole point
>>>>> is to make the libraries used match the end users'.  I don't think
>>>>> there is a sensible solution to that outside distros. Clearly
>>>>> distributing the .o files and linking at each system is a royal pain.
>>>>>
>>>>> On Mon, Mar 1, 2010 at 12:35, Michael Gogins  wrote:
>>>>>> As I have mentioned before, SCons supports Linux packages as a target
>>>>>> in SConstruct files.
>>>>>>
>>>>>> I repeat my proposal that we move the good work that people have done
>>>>>> on the Debian package into SConstruct, insofar as that is possible (I
>>>>>> am not up to speed on what it takes to get a built package into the
>>>>>> official repositories).
>>>>>>
>>>>>> It would be helpful to have all the bugs and other issues related to
>>>>>> the packages in the main build file, and packages that we could build
>>>>>> could easily be hosted on SourceForge and cSounds.com. Also, people
>>>>>> who wanted to build and install from scratch would probably find this
>>>>>> an easier and more complete method.
>>>>>>
>>>>>> Regards,
>>>>>> Mike
>>>>>>
>>>>>> On Mon, Mar 1, 2010 at 10:18 AM, Steven Yi  wrote:
>>>>>>> Well, the whole point of a beta is to release it twice, once (or
>>>>>>> possibly more) to get feedback and then a final release.  Following
>>>>>>> such a practice (or an unstable/stable release) would have mitigated a
>>>>>>> lot of the issues with 5.12.
>>>>>>>
>>>>>>> As for Linux distro, I think we should not do a release of linux
>>>>>>> binaries.  I think it causes more harm than good, frankly, as really
>>>>>>> it might only work on the distro it was built on. I think we should
>>>>>>> consider either putting up packages in debs and RPMS (could do both
>>>>>>> Fedora and SuSe RPM's) or creating a repo for them.
>>>>>>>
>>>>>>> On Mon, Mar 1, 2010 at 10:05 AM, jpff  wrote:
>>>>>>>> The inadvertent bugs in 5.12 seem almost settled.  Did we ought to
>>>>>>>> release a 5.13 (or a 5.12.5) soonish?
>>>>>>>>  I have added some more defensive code in ftload/ftsave, and there is
>>>>>>>> still the question as to whether we should allow a-rate multiple
>>>>>>>> assigns.  There is also the (a?b:c) construct in the new parser.
>>>>>>>>
>>>>>>>> I was not very happy with the beta-release we did earlier as it
>>>>>>>> involved all packagers doing the thing twice.  And there is the ongoing
>>>>>>>> Linux distribution problem -- in another large cross-platform project
>>>>>>>> we distributed many (about 6 I think) sets of .o files and a script
>>>>>>>> to try them all until one version linked.  I would rather not do that
>>>>>>>> again!
>>>>>>>>
>>>>>>>> ==John ffitch
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> Download Intel® Parallel Studio Eval
>>>>>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>>>>>> proactively, and fine-tune applications for parallel performance.
>>>>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>>>>> _______________________________________________
>>>>>>>> Csound-devel mailing list
>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Download Intel® Parallel Studio Eval
>>>>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>>>>> proactively, and fine-tune applications for parallel performance.
>>>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>>>> _______________________________________________
>>>>>>> Csound-devel mailing list
>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Michael Gogins
>>>>>> Irreducible Productions
>>>>>> http://www.michael-gogins.com
>>>>>> Michael dot Gogins at gmail dot com
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Download Intel® Parallel Studio Eval
>>>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>>>> proactively, and fine-tune applications for parallel performance.
>>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>>> _______________________________________________
>>>>>> Csound-devel mailing list
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Saludos,
>>>>> Felipe Sateler
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Download Intel® Parallel Studio Eval
>>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>>> proactively, and fine-tune applications for parallel performance.
>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Michael Gogins
>>>> Irreducible Productions
>>>> http://www.michael-gogins.com
>>>> Michael dot Gogins at gmail dot com
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Download Intel® Parallel Studio Eval
>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>> proactively, and fine-tune applications for parallel performance.
>>>> See why Intel Parallel Studio got high marks during beta.
>>>> http://p.sf.net/sfu/intel-sw-dev
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Download Intel® Parallel Studio Eval
>>> Try the new software tools for yourself. Speed compiling, find bugs
>>> proactively, and fine-tune applications for parallel performance.
>>> See why Intel Parallel Studio got high marks during beta.
>>> http://p.sf.net/sfu/intel-sw-dev
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>>
>>
>> --
>>
>> Saludos,
>> Felipe Sateler
>>
>> ------------------------------------------------------------------------------
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



-- 

Saludos,
Felipe Sateler

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listin

Using apt would definitely be ideal!  Ubuntu also scored as the most
popular distro on the questionnaire, so getting an up to date version
there would be awesome. Thanks for your hard work!

On Mon, Mar 1, 2010 at 11:59 AM, Felipe Sateler  wrote:
> In the particular case of liblo, it is being handled right now. We got
> approval to upload the 0.26 release just yesterday, so it will
> hopefully be uploaded today or tomorrow.
> In the general case, I believe the solution is to have an uptodate
> csound in debian and ubuntu, so that users do not need to download
> from the sourceforge page. I will try to coordinate myself with some
> Ubuntu people to update csound in Ubuntu (and create the 5.12 package
> too! Unless there is going to be a bugfix release now?).
>
> On Mon, Mar 1, 2010 at 13:44, Steven Yi  wrote:
>> Thanks Felipe. For something like this then, would the process be to
>> submit a package request for liblo?  (I do not have experience with
>> Debian's process)
>>
>> Thanks!
>> steven
>>
>> On Mon, Mar 1, 2010 at 11:41 AM, Felipe Sateler  wrote:
>>> As a downstream distributor, I would advise against distributing
>>> liblo, either by statically linking or by a separate package. The
>>> problem is that security or other bug fixes would require you to
>>> provide a new package if csound is to take advantage of it.
>>> In debian we believe that the action of distributing to users is
>>> better done by distributions rather than upstream developers. Of
>>> course, sometimes it happens that the package cannot be updated for
>>> one reason or another. But synchronizing all the used libraries is
>>> much better done by the people that actually build the environment.
>>>
>>> On Mon, Mar 1, 2010 at 13:22, Steven Yi  wrote:
>>>> Right, and can we not statically link against liblo? Or maybe we would
>>>> need to add a liblo deb if we maintain a repo?
>>>>
>>>> On Mon, Mar 1, 2010 at 10:44 AM, Michael Gogins
>>>>  wrote:
>>>>> Well, then SConstruct should target libraries available from standard
>>>>> distributions, right? At least, as an option.
>>>>>
>>>>> Regards,
>>>>> Mike
>>>>>
>>>>> On Mon, Mar 1, 2010 at 10:40 AM, Felipe Sateler  wrote:
>>>>>> The problem is not so much with what format the binaries are
>>>>>> distributed, but how you produced them. To take an example, I saw from
>>>>>> recent comments in the list that the linux binaries were linked
>>>>>> against liblo7, which is not yet available in debian! The whole point
>>>>>> is to make the libraries used match the end users'.  I don't think
>>>>>> there is a sensible solution to that outside distros. Clearly
>>>>>> distributing the .o files and linking at each system is a royal pain.
>>>>>>
>>>>>> On Mon, Mar 1, 2010 at 12:35, Michael Gogins  wrote:
>>>>>>> As I have mentioned before, SCons supports Linux packages as a target
>>>>>>> in SConstruct files.
>>>>>>>
>>>>>>> I repeat my proposal that we move the good work that people have done
>>>>>>> on the Debian package into SConstruct, insofar as that is possible (I
>>>>>>> am not up to speed on what it takes to get a built package into the
>>>>>>> official repositories).
>>>>>>>
>>>>>>> It would be helpful to have all the bugs and other issues related to
>>>>>>> the packages in the main build file, and packages that we could build
>>>>>>> could easily be hosted on SourceForge and cSounds.com. Also, people
>>>>>>> who wanted to build and install from scratch would probably find this
>>>>>>> an easier and more complete method.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Mike
>>>>>>>
>>>>>>> On Mon, Mar 1, 2010 at 10:18 AM, Steven Yi  wrote:
>>>>>>>> Well, the whole point of a beta is to release it twice, once (or
>>>>>>>> possibly more) to get feedback and then a final release.  Following
>>>>>>>> such a practice (or an unstable/stable release) would have mitigated a
>>>>>>>> lot of the issues with 5.12.
>>>>>>>>
>>>>>>>> As for Linux distro, I think we should not do a release of linux
>>>>>>>> binaries.  I think it causes more harm than good, frankly, as really
>>>>>>>> it might only work on the distro it was built on. I think we should
>>>>>>>> consider either putting up packages in debs and RPMS (could do both
>>>>>>>> Fedora and SuSe RPM's) or creating a repo for them.
>>>>>>>>
>>>>>>>> On Mon, Mar 1, 2010 at 10:05 AM, jpff  wrote:
>>>>>>>>> The inadvertent bugs in 5.12 seem almost settled.  Did we ought to
>>>>>>>>> release a 5.13 (or a 5.12.5) soonish?
>>>>>>>>>  I have added some more defensive code in ftload/ftsave, and there is
>>>>>>>>> still the question as to whether we should allow a-rate multiple
>>>>>>>>> assigns.  There is also the (a?b:c) construct in the new parser.
>>>>>>>>>
>>>>>>>>> I was not very happy with the beta-release we did earlier as it
>>>>>>>>> involved all packagers doing the thing twice.  And there is the ongoing
>>>>>>>>> Linux distribution problem -- in another large cross-platform project
>>>>>>>>> we distributed many (about 6 I think) sets of .o files and a script
>>>>>>>>> to try them all until one version linked.  I would rather not do that
>>>>>>>>> again!
>>>>>>>>>
>>>>>>>>> ==John ffitch
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>> Download Intel® Parallel Studio Eval
>>>>>>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>>>>>>> proactively, and fine-tune applications for parallel performance.
>>>>>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>>>>>> _______________________________________________
>>>>>>>>> Csound-devel mailing list
>>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> Download Intel® Parallel Studio Eval
>>>>>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>>>>>> proactively, and fine-tune applications for parallel performance.
>>>>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>>>>> _______________________________________________
>>>>>>>> Csound-devel mailing list
>>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Michael Gogins
>>>>>>> Irreducible Productions
>>>>>>> http://www.michael-gogins.com
>>>>>>> Michael dot Gogins at gmail dot com
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Download Intel® Parallel Studio Eval
>>>>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>>>>> proactively, and fine-tune applications for parallel performance.
>>>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>>>> _______________________________________________
>>>>>>> Csound-devel mailing list
>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Saludos,
>>>>>> Felipe Sateler
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Download Intel® Parallel Studio Eval
>>>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>>>> proactively, and fine-tune applications for parallel performance.
>>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>>> _______________________________________________
>>>>>> Csound-devel mailing list
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Michael Gogins
>>>>> Irreducible Productions
>>>>> http://www.michael-gogins.com
>>>>> Michael dot Gogins at gmail dot com
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Download Intel® Parallel Studio Eval
>>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>>> proactively, and fine-tune applications for parallel performance.
>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Download Intel® Parallel Studio Eval
>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>> proactively, and fine-tune applications for parallel performance.
>>>> See why Intel Parallel Studio got high marks during beta.
>>>> http://p.sf.net/sfu/intel-sw-dev
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> Saludos,
>>> Felipe Sateler
>>>
>>> ------------------------------------------------------------------------------
>>> Download Intel® Parallel Studio Eval
>>> Try the new software tools for yourself. Speed compiling, find bugs
>>> proactively, and fine-tune applications for parallel performance.
>>> See why Intel Parallel Studio got high marks during beta.
>>> http://p.sf.net/sfu/intel-sw-dev
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>> ------------------------------------------------------------------------------
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
>
>
> --
>
> Saludos,
> Felipe Sateler
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

BTW Steven, current code fails your test 25 -- but I think test25 is wrong
to use out with one argument in a stereo output context
==J


------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi John,

The test25 was actually committed by you on 4/20/09.  Regardless, it
seems fail differently for the old parser and the new parser.  I think
if we have bugs in our tests then anyone should feel free to update
and notify this list.  I have no attachment to any test and just want
to make sure they are correct.

I will add a flag to the test runner to allow old parser or new parser
(defaulting to new parser).

Thanks!
steven


On Mon, Mar 1, 2010 at 12:34 PM,   wrote:
> BTW Steven, current code fails your test 25 -- but I think test25 is wrong
> to use out with one argument in a stereo output context
> ==J
>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

If we use static links, the package will not be approved  by Fedora  
(and I guess Debian too),

Victor
On 1 Mar 2010, at 16:32, Michael Gogins wrote:

> We should statically link if possible.in such cases.
>
> Regards,
> Mike
>
> On Mon, Mar 1, 2010 at 11:22 AM, Steven Yi  wrote:
>> Right, and can we not statically link against liblo? Or maybe we  
>> would
>> need to add a liblo deb if we maintain a repo?
>>
>> On Mon, Mar 1, 2010 at 10:44 AM, Michael Gogins
>>  wrote:
>>> Well, then SConstruct should target libraries available from  
>>> standard
>>> distributions, right? At least, as an option.
>>>
>>> Regards,
>>> Mike
>>>
>>> On Mon, Mar 1, 2010 at 10:40 AM, Felipe Sateler  
>>>  wrote:
>>>> The problem is not so much with what format the binaries are
>>>> distributed, but how you produced them. To take an example, I saw  
>>>> from
>>>> recent comments in the list that the linux binaries were linked
>>>> against liblo7, which is not yet available in debian! The whole  
>>>> point
>>>> is to make the libraries used match the end users'.  I don't think
>>>> there is a sensible solution to that outside distros. Clearly
>>>> distributing the .o files and linking at each system is a royal  
>>>> pain.
>>>>
>>>> On Mon, Mar 1, 2010 at 12:35, Michael Gogins >>> > wrote:
>>>>> As I have mentioned before, SCons supports Linux packages as a  
>>>>> target
>>>>> in SConstruct files.
>>>>>
>>>>> I repeat my proposal that we move the good work that people have  
>>>>> done
>>>>> on the Debian package into SConstruct, insofar as that is  
>>>>> possible (I
>>>>> am not up to speed on what it takes to get a built package into  
>>>>> the
>>>>> official repositories).
>>>>>
>>>>> It would be helpful to have all the bugs and other issues  
>>>>> related to
>>>>> the packages in the main build file, and packages that we could  
>>>>> build
>>>>> could easily be hosted on SourceForge and cSounds.com. Also,  
>>>>> people
>>>>> who wanted to build and install from scratch would probably find  
>>>>> this
>>>>> an easier and more complete method.
>>>>>
>>>>> Regards,
>>>>> Mike
>>>>>
>>>>> On Mon, Mar 1, 2010 at 10:18 AM, Steven Yi   
>>>>> wrote:
>>>>>> Well, the whole point of a beta is to release it twice, once (or
>>>>>> possibly more) to get feedback and then a final release.   
>>>>>> Following
>>>>>> such a practice (or an unstable/stable release) would have  
>>>>>> mitigated a
>>>>>> lot of the issues with 5.12.
>>>>>>
>>>>>> As for Linux distro, I think we should not do a release of linux
>>>>>> binaries.  I think it causes more harm than good, frankly, as  
>>>>>> really
>>>>>> it might only work on the distro it was built on. I think we  
>>>>>> should
>>>>>> consider either putting up packages in debs and RPMS (could do  
>>>>>> both
>>>>>> Fedora and SuSe RPM's) or creating a repo for them.
>>>>>>
>>>>>> On Mon, Mar 1, 2010 at 10:05 AM, jpff  wrote:
>>>>>>> The inadvertent bugs in 5.12 seem almost settled.  Did we  
>>>>>>> ought to
>>>>>>> release a 5.13 (or a 5.12.5) soonish?
>>>>>>>  I have added some more defensive code in ftload/ftsave, and  
>>>>>>> there is
>>>>>>> still the question as to whether we should allow a-rate multiple
>>>>>>> assigns.  There is also the (a?b:c) construct in the new parser.
>>>>>>>
>>>>>>> I was not very happy with the beta-release we did earlier as it
>>>>>>> involved all packagers doing the thing twice.  And there is  
>>>>>>> the ongoing
>>>>>>> Linux distribution problem -- in another large cross-platform  
>>>>>>> project
>>>>>>> we distributed many (about 6 I think) sets of .o files and a  
>>>>>>> script
>>>>>>> to try them all until one version linked.  I would rather not  
>>>>>>> do that
>>>>>>> again!
>>>>>>>
>>>>>>> ==John ffitch
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Download Intel® Parallel Studio Eval
>>>>>>> Try the new software tools for yourself. Speed compiling, find  
>>>>>>> bugs
>>>>>>> proactively, and fine-tune applications for parallel  
>>>>>>> performance.
>>>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>>>> _______________________________________________
>>>>>>> Csound-devel mailing list
>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Download Intel® Parallel Studio Eval
>>>>>> Try the new software tools for yourself. Speed compiling, find  
>>>>>> bugs
>>>>>> proactively, and fine-tune applications for parallel performance.
>>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>>> _______________________________________________
>>>>>> Csound-devel mailing list
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Michael Gogins
>>>>> Irreducible Productions
>>>>> http://www.michael-gogins.com
>>>>> Michael dot Gogins at gmail dot com
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Download Intel® Parallel Studio Eval
>>>>> Try the new software tools for yourself. Speed compiling, find  
>>>>> bugs
>>>>> proactively, and fine-tune applications for parallel performance.
>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Saludos,
>>>> Felipe Sateler
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Download Intel® Parallel Studio Eval
>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>> proactively, and fine-tune applications for parallel performance.
>>>> See why Intel Parallel Studio got high marks during beta.
>>>> http://p.sf.net/sfu/intel-sw-dev
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>
>>>
>>>
>>> --
>>> Michael Gogins
>>> Irreducible Productions
>>> http://www.michael-gogins.com
>>> Michael dot Gogins at gmail dot com
>>>
>>> ------------------------------------------------------------------------------
>>> Download Intel® Parallel Studio Eval
>>> Try the new software tools for yourself. Speed compiling, find bugs
>>> proactively, and fine-tune applications for parallel performance.
>>> See why Intel Parallel Studio got high marks during beta.
>>> http://p.sf.net/sfu/intel-sw-dev
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>> ------------------------------------------------------------------------------
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
>
>
> -- 
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

But that is kind of what I meant -- that the SConstruct file would
know what libraries belong in the targeted distribution, and link only
with those. Is there some way of automating this?

Regards,
Mike

On Mon, Mar 1, 2010 at 11:15 AM, Felipe Sateler  wrote:
> Sconstruct already does that. The problem is that there is no way to
> guarantee that the system libraries available at build time will be the
> same ones present in the user's system at runtime. To use the liblo
> example:
> Currently, in debian we have liblo version 0.23. So if we build a binary
> distribution for debian unstable, the resulting binaries end up linked
> to liblo.so.0. However, liblo 0.26 will be uploaded some time soonish,
> which has bumped the SONAME. So, in a couple of months, users will no
> longer have liblo.so.0, but liblo.so.7. How can we detect this outside
> the debian infrastructure?
>
> On Mon, 2010-03-01 at 10:44 -0500, Michael Gogins wrote:
>> Well, then SConstruct should target libraries available from standard
>> distributions, right? At least, as an option.
>>
>> Regards,
>> Mike
>>
>> On Mon, Mar 1, 2010 at 10:40 AM, Felipe Sateler  wrote:
>> > The problem is not so much with what format the binaries are
>> > distributed, but how you produced them. To take an example, I saw from
>> > recent comments in the list that the linux binaries were linked
>> > against liblo7, which is not yet available in debian! The whole point
>> > is to make the libraries used match the end users'.  I don't think
>> > there is a sensible solution to that outside distros. Clearly
>> > distributing the .o files and linking at each system is a royal pain.
>> >
>> > On Mon, Mar 1, 2010 at 12:35, Michael Gogins  wrote:
>> >> As I have mentioned before, SCons supports Linux packages as a target
>> >> in SConstruct files.
>> >>
>> >> I repeat my proposal that we move the good work that people have done
>> >> on the Debian package into SConstruct, insofar as that is possible (I
>> >> am not up to speed on what it takes to get a built package into the
>> >> official repositories).
>> >>
>> >> It would be helpful to have all the bugs and other issues related to
>> >> the packages in the main build file, and packages that we could build
>> >> could easily be hosted on SourceForge and cSounds.com. Also, people
>> >> who wanted to build and install from scratch would probably find this
>> >> an easier and more complete method.
>> >>
>> >> Regards,
>> >> Mike
>> >>
>> >> On Mon, Mar 1, 2010 at 10:18 AM, Steven Yi  wrote:
>> >>> Well, the whole point of a beta is to release it twice, once (or
>> >>> possibly more) to get feedback and then a final release.  Following
>> >>> such a practice (or an unstable/stable release) would have mitigated a
>> >>> lot of the issues with 5.12.
>> >>>
>> >>> As for Linux distro, I think we should not do a release of linux
>> >>> binaries.  I think it causes more harm than good, frankly, as really
>> >>> it might only work on the distro it was built on. I think we should
>> >>> consider either putting up packages in debs and RPMS (could do both
>> >>> Fedora and SuSe RPM's) or creating a repo for them.
>> >>>
>> >>> On Mon, Mar 1, 2010 at 10:05 AM, jpff  wrote:
>> >>>> The inadvertent bugs in 5.12 seem almost settled.  Did we ought to
>> >>>> release a 5.13 (or a 5.12.5) soonish?
>> >>>>  I have added some more defensive code in ftload/ftsave, and there is
>> >>>> still the question as to whether we should allow a-rate multiple
>> >>>> assigns.  There is also the (a?b:c) construct in the new parser.
>> >>>>
>> >>>> I was not very happy with the beta-release we did earlier as it
>> >>>> involved all packagers doing the thing twice.  And there is the ongoing
>> >>>> Linux distribution problem -- in another large cross-platform project
>> >>>> we distributed many (about 6 I think) sets of .o files and a script
>> >>>> to try them all until one version linked.  I would rather not do that
>> >>>> again!
>> >>>>
>> >>>> ==John ffitch
>> >>>>
>> >>>> ------------------------------------------------------------------------------
>> >>>> Download Intel® Parallel Studio Eval
>> >>>> Try the new software tools for yourself. Speed compiling, find bugs
>> >>>> proactively, and fine-tune applications for parallel performance.
>> >>>> See why Intel Parallel Studio got high marks during beta.
>> >>>> http://p.sf.net/sfu/intel-sw-dev
>> >>>> _______________________________________________
>> >>>> Csound-devel mailing list
>> >>>> Csound-devel@lists.sourceforge.net
>> >>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >>>>
>> >>>
>> >>> ------------------------------------------------------------------------------
>> >>> Download Intel® Parallel Studio Eval
>> >>> Try the new software tools for yourself. Speed compiling, find bugs
>> >>> proactively, and fine-tune applications for parallel performance.
>> >>> See why Intel Parallel Studio got high marks during beta.
>> >>> http://p.sf.net/sfu/intel-sw-dev
>> >>> _______________________________________________
>> >>> Csound-devel mailing list
>> >>> Csound-devel@lists.sourceforge.net
>> >>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> Michael Gogins
>> >> Irreducible Productions
>> >> http://www.michael-gogins.com
>> >> Michael dot Gogins at gmail dot com
>> >>
>> >> ------------------------------------------------------------------------------
>> >> Download Intel® Parallel Studio Eval
>> >> Try the new software tools for yourself. Speed compiling, find bugs
>> >> proactively, and fine-tune applications for parallel performance.
>> >> See why Intel Parallel Studio got high marks during beta.
>> >> http://p.sf.net/sfu/intel-sw-dev
>> >> _______________________________________________
>> >> Csound-devel mailing list
>> >> Csound-devel@lists.sourceforge.net
>> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >>
>> >
>> >
>> >
>> > --
>> >
>> > Saludos,
>> > Felipe Sateler
>> >
>> > ------------------------------------------------------------------------------
>> > Download Intel® Parallel Studio Eval
>> > Try the new software tools for yourself. Speed compiling, find bugs
>> > proactively, and fine-tune applications for parallel performance.
>> > See why Intel Parallel Studio got high marks during beta.
>> > http://p.sf.net/sfu/intel-sw-dev
>> > _______________________________________________
>> > Csound-devel mailing list
>> > Csound-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >
>>
>>
>>
>
> --
> Saludos,
> Felipe Sateler
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I'm not quite sure what you mean. You want to bundle the linked
libraries into the distributed packages? If so, the package will
conflict with the distro-provided packages of said libraries, causing
more pain than gains.

On Mon, Mar 1, 2010 at 16:30, Michael Gogins  wrote:
> But that is kind of what I meant -- that the SConstruct file would
> know what libraries belong in the targeted distribution, and link only
> with those. Is there some way of automating this?
>
> Regards,
> Mike
>
> On Mon, Mar 1, 2010 at 11:15 AM, Felipe Sateler  wrote:
>> Sconstruct already does that. The problem is that there is no way to
>> guarantee that the system libraries available at build time will be the
>> same ones present in the user's system at runtime. To use the liblo
>> example:
>> Currently, in debian we have liblo version 0.23. So if we build a binary
>> distribution for debian unstable, the resulting binaries end up linked
>> to liblo.so.0. However, liblo 0.26 will be uploaded some time soonish,
>> which has bumped the SONAME. So, in a couple of months, users will no
>> longer have liblo.so.0, but liblo.so.7. How can we detect this outside
>> the debian infrastructure?
>>
>> On Mon, 2010-03-01 at 10:44 -0500, Michael Gogins wrote:
>>> Well, then SConstruct should target libraries available from standard
>>> distributions, right? At least, as an option.
>>>
>>> Regards,
>>> Mike
>>>
>>> On Mon, Mar 1, 2010 at 10:40 AM, Felipe Sateler  wrote:
>>> > The problem is not so much with what format the binaries are
>>> > distributed, but how you produced them. To take an example, I saw from
>>> > recent comments in the list that the linux binaries were linked
>>> > against liblo7, which is not yet available in debian! The whole point
>>> > is to make the libraries used match the end users'.  I don't think
>>> > there is a sensible solution to that outside distros. Clearly
>>> > distributing the .o files and linking at each system is a royal pain.
>>> >
>>> > On Mon, Mar 1, 2010 at 12:35, Michael Gogins  wrote:
>>> >> As I have mentioned before, SCons supports Linux packages as a target
>>> >> in SConstruct files.
>>> >>
>>> >> I repeat my proposal that we move the good work that people have done
>>> >> on the Debian package into SConstruct, insofar as that is possible (I
>>> >> am not up to speed on what it takes to get a built package into the
>>> >> official repositories).
>>> >>
>>> >> It would be helpful to have all the bugs and other issues related to
>>> >> the packages in the main build file, and packages that we could build
>>> >> could easily be hosted on SourceForge and cSounds.com. Also, people
>>> >> who wanted to build and install from scratch would probably find this
>>> >> an easier and more complete method.
>>> >>
>>> >> Regards,
>>> >> Mike
>>> >>
>>> >> On Mon, Mar 1, 2010 at 10:18 AM, Steven Yi  wrote:
>>> >>> Well, the whole point of a beta is to release it twice, once (or
>>> >>> possibly more) to get feedback and then a final release.  Following
>>> >>> such a practice (or an unstable/stable release) would have mitigated a
>>> >>> lot of the issues with 5.12.
>>> >>>
>>> >>> As for Linux distro, I think we should not do a release of linux
>>> >>> binaries.  I think it causes more harm than good, frankly, as really
>>> >>> it might only work on the distro it was built on. I think we should
>>> >>> consider either putting up packages in debs and RPMS (could do both
>>> >>> Fedora and SuSe RPM's) or creating a repo for them.
>>> >>>
>>> >>> On Mon, Mar 1, 2010 at 10:05 AM, jpff  wrote:
>>> >>>> The inadvertent bugs in 5.12 seem almost settled.  Did we ought to
>>> >>>> release a 5.13 (or a 5.12.5) soonish?
>>> >>>>  I have added some more defensive code in ftload/ftsave, and there is
>>> >>>> still the question as to whether we should allow a-rate multiple
>>> >>>> assigns.  There is also the (a?b:c) construct in the new parser.
>>> >>>>
>>> >>>> I was not very happy with the beta-release we did earlier as it
>>> >>>> involved all packagers doing the thing twice.  And there is the ongoing
>>> >>>> Linux distribution problem -- in another large cross-platform project
>>> >>>> we distributed many (about 6 I think) sets of .o files and a script
>>> >>>> to try them all until one version linked.  I would rather not do that
>>> >>>> again!
>>> >>>>
>>> >>>> ==John ffitch
>>> >>>>
>>> >>>> ------------------------------------------------------------------------------
>>> >>>> Download Intel® Parallel Studio Eval
>>> >>>> Try the new software tools for yourself. Speed compiling, find bugs
>>> >>>> proactively, and fine-tune applications for parallel performance.
>>> >>>> See why Intel Parallel Studio got high marks during beta.
>>> >>>> http://p.sf.net/sfu/intel-sw-dev
>>> >>>> _______________________________________________
>>> >>>> Csound-devel mailing list
>>> >>>> Csound-devel@lists.sourceforge.net
>>> >>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>> >>>>
>>> >>>
>>> >>> ------------------------------------------------------------------------------
>>> >>> Download Intel® Parallel Studio Eval
>>> >>> Try the new software tools for yourself. Speed compiling, find bugs
>>> >>> proactively, and fine-tune applications for parallel performance.
>>> >>> See why Intel Parallel Studio got high marks during beta.
>>> >>> http://p.sf.net/sfu/intel-sw-dev
>>> >>> _______________________________________________
>>> >>> Csound-devel mailing list
>>> >>> Csound-devel@lists.sourceforge.net
>>> >>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>> >>>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Michael Gogins
>>> >> Irreducible Productions
>>> >> http://www.michael-gogins.com
>>> >> Michael dot Gogins at gmail dot com
>>> >>
>>> >> ------------------------------------------------------------------------------
>>> >> Download Intel® Parallel Studio Eval
>>> >> Try the new software tools for yourself. Speed compiling, find bugs
>>> >> proactively, and fine-tune applications for parallel performance.
>>> >> See why Intel Parallel Studio got high marks during beta.
>>> >> http://p.sf.net/sfu/intel-sw-dev
>>> >> _______________________________________________
>>> >> Csound-devel mailing list
>>> >> Csound-devel@lists.sourceforge.net
>>> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> >
>>> > Saludos,
>>> > Felipe Sateler
>>> >
>>> > ------------------------------------------------------------------------------
>>> > Download Intel® Parallel Studio Eval
>>> > Try the new software tools for yourself. Speed compiling, find bugs
>>> > proactively, and fine-tune applications for parallel performance.
>>> > See why Intel Parallel Studio got high marks during beta.
>>> > http://p.sf.net/sfu/intel-sw-dev
>>> > _______________________________________________
>>> > Csound-devel mailing list
>>> > Csound-devel@lists.sourceforge.net
>>> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>>> >
>>>
>>>
>>>
>>
>> --
>> Saludos,
>> Felipe Sateler
>>
>> ------------------------------------------------------------------------------
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



-- 

Saludos,
Felipe Sateler

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https:

I meant link with static libraries, not shared libraries.

Regards,
Mike

On Mon, Mar 1, 2010 at 3:27 PM, Felipe Sateler  wrote:
> I'm not quite sure what you mean. You want to bundle the linked
> libraries into the distributed packages? If so, the package will
> conflict with the distro-provided packages of said libraries, causing
> more pain than gains.
>
> On Mon, Mar 1, 2010 at 16:30, Michael Gogins  wrote:
>> But that is kind of what I meant -- that the SConstruct file would
>> know what libraries belong in the targeted distribution, and link only
>> with those. Is there some way of automating this?
>>
>> Regards,
>> Mike
>>
>> On Mon, Mar 1, 2010 at 11:15 AM, Felipe Sateler  wrote:
>>> Sconstruct already does that. The problem is that there is no way to
>>> guarantee that the system libraries available at build time will be the
>>> same ones present in the user's system at runtime. To use the liblo
>>> example:
>>> Currently, in debian we have liblo version 0.23. So if we build a binary
>>> distribution for debian unstable, the resulting binaries end up linked
>>> to liblo.so.0. However, liblo 0.26 will be uploaded some time soonish,
>>> which has bumped the SONAME. So, in a couple of months, users will no
>>> longer have liblo.so.0, but liblo.so.7. How can we detect this outside
>>> the debian infrastructure?
>>>
>>> On Mon, 2010-03-01 at 10:44 -0500, Michael Gogins wrote:
>>>> Well, then SConstruct should target libraries available from standard
>>>> distributions, right? At least, as an option.
>>>>
>>>> Regards,
>>>> Mike
>>>>
>>>> On Mon, Mar 1, 2010 at 10:40 AM, Felipe Sateler  wrote:
>>>> > The problem is not so much with what format the binaries are
>>>> > distributed, but how you produced them. To take an example, I saw from
>>>> > recent comments in the list that the linux binaries were linked
>>>> > against liblo7, which is not yet available in debian! The whole point
>>>> > is to make the libraries used match the end users'.  I don't think
>>>> > there is a sensible solution to that outside distros. Clearly
>>>> > distributing the .o files and linking at each system is a royal pain.
>>>> >
>>>> > On Mon, Mar 1, 2010 at 12:35, Michael Gogins  wrote:
>>>> >> As I have mentioned before, SCons supports Linux packages as a target
>>>> >> in SConstruct files.
>>>> >>
>>>> >> I repeat my proposal that we move the good work that people have done
>>>> >> on the Debian package into SConstruct, insofar as that is possible (I
>>>> >> am not up to speed on what it takes to get a built package into the
>>>> >> official repositories).
>>>> >>
>>>> >> It would be helpful to have all the bugs and other issues related to
>>>> >> the packages in the main build file, and packages that we could build
>>>> >> could easily be hosted on SourceForge and cSounds.com. Also, people
>>>> >> who wanted to build and install from scratch would probably find this
>>>> >> an easier and more complete method.
>>>> >>
>>>> >> Regards,
>>>> >> Mike
>>>> >>
>>>> >> On Mon, Mar 1, 2010 at 10:18 AM, Steven Yi  wrote:
>>>> >>> Well, the whole point of a beta is to release it twice, once (or
>>>> >>> possibly more) to get feedback and then a final release.  Following
>>>> >>> such a practice (or an unstable/stable release) would have mitigated a
>>>> >>> lot of the issues with 5.12.
>>>> >>>
>>>> >>> As for Linux distro, I think we should not do a release of linux
>>>> >>> binaries.  I think it causes more harm than good, frankly, as really
>>>> >>> it might only work on the distro it was built on. I think we should
>>>> >>> consider either putting up packages in debs and RPMS (could do both
>>>> >>> Fedora and SuSe RPM's) or creating a repo for them.
>>>> >>>
>>>> >>> On Mon, Mar 1, 2010 at 10:05 AM, jpff  wrote:
>>>> >>>> The inadvertent bugs in 5.12 seem almost settled.  Did we ought to
>>>> >>>> release a 5.13 (or a 5.12.5) soonish?
>>>> >>>>  I have added some more defensive code in ftload/ftsave, and there is
>>>> >>>> still the question as to whether we should allow a-rate multiple
>>>> >>>> assigns.  There is also the (a?b:c) construct in the new parser.
>>>> >>>>
>>>> >>>> I was not very happy with the beta-release we did earlier as it
>>>> >>>> involved all packagers doing the thing twice.  And there is the ongoing
>>>> >>>> Linux distribution problem -- in another large cross-platform project
>>>> >>>> we distributed many (about 6 I think) sets of .o files and a script
>>>> >>>> to try them all until one version linked.  I would rather not do that
>>>> >>>> again!
>>>> >>>>
>>>> >>>> ==John ffitch
>>>> >>>>
>>>> >>>> ------------------------------------------------------------------------------
>>>> >>>> Download Intel® Parallel Studio Eval
>>>> >>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>> >>>> proactively, and fine-tune applications for parallel performance.
>>>> >>>> See why Intel Parallel Studio got high marks during beta.
>>>> >>>> http://p.sf.net/sfu/intel-sw-dev
>>>> >>>> _______________________________________________
>>>> >>>> Csound-devel mailing list
>>>> >>>> Csound-devel@lists.sourceforge.net
>>>> >>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>> >>>>
>>>> >>>
>>>> >>> ------------------------------------------------------------------------------
>>>> >>> Download Intel® Parallel Studio Eval
>>>> >>> Try the new software tools for yourself. Speed compiling, find bugs
>>>> >>> proactively, and fine-tune applications for parallel performance.
>>>> >>> See why Intel Parallel Studio got high marks during beta.
>>>> >>> http://p.sf.net/sfu/intel-sw-dev
>>>> >>> _______________________________________________
>>>> >>> Csound-devel mailing list
>>>> >>> Csound-devel@lists.sourceforge.net
>>>> >>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>> >>>
>>>> >>
>>>> >>
>>>> >>
>>>> >> --
>>>> >> Michael Gogins
>>>> >> Irreducible Productions
>>>> >> http://www.michael-gogins.com
>>>> >> Michael dot Gogins at gmail dot com
>>>> >>
>>>> >> ------------------------------------------------------------------------------
>>>> >> Download Intel® Parallel Studio Eval
>>>> >> Try the new software tools for yourself. Speed compiling, find bugs
>>>> >> proactively, and fine-tune applications for parallel performance.
>>>> >> See why Intel Parallel Studio got high marks during beta.
>>>> >> http://p.sf.net/sfu/intel-sw-dev
>>>> >> _______________________________________________
>>>> >> Csound-devel mailing list
>>>> >> Csound-devel@lists.sourceforge.net
>>>> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>> >>
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> >
>>>> > Saludos,
>>>> > Felipe Sateler
>>>> >
>>>> > ------------------------------------------------------------------------------
>>>> > Download Intel® Parallel Studio Eval
>>>> > Try the new software tools for yourself. Speed compiling, find bugs
>>>> > proactively, and fine-tune applications for parallel performance.
>>>> > See why Intel Parallel Studio got high marks during beta.
>>>> > http://p.sf.net/sfu/intel-sw-dev
>>>> > _______________________________________________
>>>> > Csound-devel mailing list
>>>> > Csound-devel@lists.sourceforge.net
>>>> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>> >
>>>>
>>>>
>>>>
>>>
>>> --
>>> Saludos,
>>> Felipe Sateler
>>>
>>> ------------------------------------------------------------------------------
>>> Download Intel® Parallel Studio Eval
>>> Try the new software tools for yourself. Speed compiling, find bugs
>>> proactively, and fine-tune applications for parallel performance.
>>> See why Intel Parallel Studio got high marks during beta.
>>> http://p.sf.net/sfu/intel-sw-dev
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>
>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>> ------------------------------------------------------------------------------
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
>
>
> --
>
> Saludos,
> Felipe Sateler
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I think it is just a matter of prepending -static (or -Wl,-static, I'm
not sure) to the linker lines. But, as was said before, csound will
then not take advantage of any bugfix/enhancement in the libraries
without producing a new package of csound.

On Mon, Mar 1, 2010 at 17:37, Michael Gogins  wrote:
> I meant link with static libraries, not shared libraries.
>
> Regards,
> Mike
>
> On Mon, Mar 1, 2010 at 3:27 PM, Felipe Sateler  wrote:
>> I'm not quite sure what you mean. You want to bundle the linked
>> libraries into the distributed packages? If so, the package will
>> conflict with the distro-provided packages of said libraries, causing
>> more pain than gains.
>>
>> On Mon, Mar 1, 2010 at 16:30, Michael Gogins  wrote:
>>> But that is kind of what I meant -- that the SConstruct file would
>>> know what libraries belong in the targeted distribution, and link only
>>> with those. Is there some way of automating this?
>>>
>>> Regards,
>>> Mike
>>>
>>> On Mon, Mar 1, 2010 at 11:15 AM, Felipe Sateler  wrote:
>>>> Sconstruct already does that. The problem is that there is no way to
>>>> guarantee that the system libraries available at build time will be the
>>>> same ones present in the user's system at runtime. To use the liblo
>>>> example:
>>>> Currently, in debian we have liblo version 0.23. So if we build a binary
>>>> distribution for debian unstable, the resulting binaries end up linked
>>>> to liblo.so.0. However, liblo 0.26 will be uploaded some time soonish,
>>>> which has bumped the SONAME. So, in a couple of months, users will no
>>>> longer have liblo.so.0, but liblo.so.7. How can we detect this outside
>>>> the debian infrastructure?
>>>>
>>>> On Mon, 2010-03-01 at 10:44 -0500, Michael Gogins wrote:
>>>>> Well, then SConstruct should target libraries available from standard
>>>>> distributions, right? At least, as an option.
>>>>>
>>>>> Regards,
>>>>> Mike
>>>>>
>>>>> On Mon, Mar 1, 2010 at 10:40 AM, Felipe Sateler  wrote:
>>>>> > The problem is not so much with what format the binaries are
>>>>> > distributed, but how you produced them. To take an example, I saw from
>>>>> > recent comments in the list that the linux binaries were linked
>>>>> > against liblo7, which is not yet available in debian! The whole point
>>>>> > is to make the libraries used match the end users'.  I don't think
>>>>> > there is a sensible solution to that outside distros. Clearly
>>>>> > distributing the .o files and linking at each system is a royal pain.
>>>>> >
>>>>> > On Mon, Mar 1, 2010 at 12:35, Michael Gogins  wrote:
>>>>> >> As I have mentioned before, SCons supports Linux packages as a target
>>>>> >> in SConstruct files.
>>>>> >>
>>>>> >> I repeat my proposal that we move the good work that people have done
>>>>> >> on the Debian package into SConstruct, insofar as that is possible (I
>>>>> >> am not up to speed on what it takes to get a built package into the
>>>>> >> official repositories).
>>>>> >>
>>>>> >> It would be helpful to have all the bugs and other issues related to
>>>>> >> the packages in the main build file, and packages that we could build
>>>>> >> could easily be hosted on SourceForge and cSounds.com. Also, people
>>>>> >> who wanted to build and install from scratch would probably find this
>>>>> >> an easier and more complete method.
>>>>> >>
>>>>> >> Regards,
>>>>> >> Mike
>>>>> >>
>>>>> >> On Mon, Mar 1, 2010 at 10:18 AM, Steven Yi  wrote:
>>>>> >>> Well, the whole point of a beta is to release it twice, once (or
>>>>> >>> possibly more) to get feedback and then a final release.  Following
>>>>> >>> such a practice (or an unstable/stable release) would have mitigated a
>>>>> >>> lot of the issues with 5.12.
>>>>> >>>
>>>>> >>> As for Linux distro, I think we should not do a release of linux
>>>>> >>> binaries.  I think it causes more harm than good, frankly, as really
>>>>> >>> it might only work on the distro it was built on. I think we should
>>>>> >>> consider either putting up packages in debs and RPMS (could do both
>>>>> >>> Fedora and SuSe RPM's) or creating a repo for them.
>>>>> >>>
>>>>> >>> On Mon, Mar 1, 2010 at 10:05 AM, jpff  wrote:
>>>>> >>>> The inadvertent bugs in 5.12 seem almost settled.  Did we ought to
>>>>> >>>> release a 5.13 (or a 5.12.5) soonish?
>>>>> >>>>  I have added some more defensive code in ftload/ftsave, and there is
>>>>> >>>> still the question as to whether we should allow a-rate multiple
>>>>> >>>> assigns.  There is also the (a?b:c) construct in the new parser.
>>>>> >>>>
>>>>> >>>> I was not very happy with the beta-release we did earlier as it
>>>>> >>>> involved all packagers doing the thing twice.  And there is the ongoing
>>>>> >>>> Linux distribution problem -- in another large cross-platform project
>>>>> >>>> we distributed many (about 6 I think) sets of .o files and a script
>>>>> >>>> to try them all until one version linked.  I would rather not do that
>>>>> >>>> again!
>>>>> >>>>
>>>>> >>>> ==John ffitch
>>>>> >>>>
>>>>> >>>> ------------------------------------------------------------------------------
>>>>> >>>> Download Intel® Parallel Studio Eval
>>>>> >>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>>> >>>> proactively, and fine-tune applications for parallel performance.
>>>>> >>>> See why Intel Parallel Studio got high marks during beta.
>>>>> >>>> http://p.sf.net/sfu/intel-sw-dev
>>>>> >>>> _______________________________________________
>>>>> >>>> Csound-devel mailing list
>>>>> >>>> Csound-devel@lists.sourceforge.net
>>>>> >>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>> >>>>
>>>>> >>>
>>>>> >>> ------------------------------------------------------------------------------
>>>>> >>> Download Intel® Parallel Studio Eval
>>>>> >>> Try the new software tools for yourself. Speed compiling, find bugs
>>>>> >>> proactively, and fine-tune applications for parallel performance.
>>>>> >>> See why Intel Parallel Studio got high marks during beta.
>>>>> >>> http://p.sf.net/sfu/intel-sw-dev
>>>>> >>> _______________________________________________
>>>>> >>> Csound-devel mailing list
>>>>> >>> Csound-devel@lists.sourceforge.net
>>>>> >>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>> >>>
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> --
>>>>> >> Michael Gogins
>>>>> >> Irreducible Productions
>>>>> >> http://www.michael-gogins.com
>>>>> >> Michael dot Gogins at gmail dot com
>>>>> >>
>>>>> >> ------------------------------------------------------------------------------
>>>>> >> Download Intel® Parallel Studio Eval
>>>>> >> Try the new software tools for yourself. Speed compiling, find bugs
>>>>> >> proactively, and fine-tune applications for parallel performance.
>>>>> >> See why Intel Parallel Studio got high marks during beta.
>>>>> >> http://p.sf.net/sfu/intel-sw-dev
>>>>> >> _______________________________________________
>>>>> >> Csound-devel mailing list
>>>>> >> Csound-devel@lists.sourceforge.net
>>>>> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>> >>
>>>>> >
>>>>> >
>>>>> >
>>>>> > --
>>>>> >
>>>>> > Saludos,
>>>>> > Felipe Sateler
>>>>> >
>>>>> > ------------------------------------------------------------------------------
>>>>> > Download Intel® Parallel Studio Eval
>>>>> > Try the new software tools for yourself. Speed compiling, find bugs
>>>>> > proactively, and fine-tune applications for parallel performance.
>>>>> > See why Intel Parallel Studio got high marks during beta.
>>>>> > http://p.sf.net/sfu/intel-sw-dev
>>>>> > _______________________________________________
>>>>> > Csound-devel mailing list
>>>>> > Csound-devel@lists.sourceforge.net
>>>>> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Saludos,
>>>> Felipe Sateler
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Download Intel® Parallel Studio Eval
>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>> proactively, and fine-tune applications for parallel performance.
>>>> See why Intel Parallel Studio got high marks during beta.
>>>> http://p.sf.net/sfu/intel-sw-dev
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Michael Gogins
>>> Irreducible Productions
>>> http://www.michael-gogins.com
>>> Michael dot Gogins at gmail dot com
>>>
>>> ------------------------------------------------------------------------------
>>> Download Intel® Parallel Studio Eval
>>> Try the new software tools for yourself. Speed compiling, find bugs
>>> proactively, and fine-tune applications for parallel performance.
>>> See why Intel Parallel Studio got high marks during beta.
>>> http://p.sf.net/sfu/intel-sw-dev
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>>
>>
>> --
>>
>> Saludos,
>> Felipe Sateler
>>
>> ------------------------------------------------------------------------------
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



-- 

Saludos,
Felipe Sateler

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinf

I understand that. It's just a way to release Csound with wiimote or
whatever without there yet being packages for them in the
repositories. Everything else would be kosher.

Regards,
Mike

On Mon, Mar 1, 2010 at 4:15 PM, Felipe Sateler  wrote:
> I think it is just a matter of prepending -static (or -Wl,-static, I'm
> not sure) to the linker lines. But, as was said before, csound will
> then not take advantage of any bugfix/enhancement in the libraries
> without producing a new package of csound.
>
> On Mon, Mar 1, 2010 at 17:37, Michael Gogins  wrote:
>> I meant link with static libraries, not shared libraries.
>>
>> Regards,
>> Mike
>>
>> On Mon, Mar 1, 2010 at 3:27 PM, Felipe Sateler  wrote:
>>> I'm not quite sure what you mean. You want to bundle the linked
>>> libraries into the distributed packages? If so, the package will
>>> conflict with the distro-provided packages of said libraries, causing
>>> more pain than gains.
>>>
>>> On Mon, Mar 1, 2010 at 16:30, Michael Gogins  wrote:
>>>> But that is kind of what I meant -- that the SConstruct file would
>>>> know what libraries belong in the targeted distribution, and link only
>>>> with those. Is there some way of automating this?
>>>>
>>>> Regards,
>>>> Mike
>>>>
>>>> On Mon, Mar 1, 2010 at 11:15 AM, Felipe Sateler  wrote:
>>>>> Sconstruct already does that. The problem is that there is no way to
>>>>> guarantee that the system libraries available at build time will be the
>>>>> same ones present in the user's system at runtime. To use the liblo
>>>>> example:
>>>>> Currently, in debian we have liblo version 0.23. So if we build a binary
>>>>> distribution for debian unstable, the resulting binaries end up linked
>>>>> to liblo.so.0. However, liblo 0.26 will be uploaded some time soonish,
>>>>> which has bumped the SONAME. So, in a couple of months, users will no
>>>>> longer have liblo.so.0, but liblo.so.7. How can we detect this outside
>>>>> the debian infrastructure?
>>>>>
>>>>> On Mon, 2010-03-01 at 10:44 -0500, Michael Gogins wrote:
>>>>>> Well, then SConstruct should target libraries available from standard
>>>>>> distributions, right? At least, as an option.
>>>>>>
>>>>>> Regards,
>>>>>> Mike
>>>>>>
>>>>>> On Mon, Mar 1, 2010 at 10:40 AM, Felipe Sateler  wrote:
>>>>>> > The problem is not so much with what format the binaries are
>>>>>> > distributed, but how you produced them. To take an example, I saw from
>>>>>> > recent comments in the list that the linux binaries were linked
>>>>>> > against liblo7, which is not yet available in debian! The whole point
>>>>>> > is to make the libraries used match the end users'.  I don't think
>>>>>> > there is a sensible solution to that outside distros. Clearly
>>>>>> > distributing the .o files and linking at each system is a royal pain.
>>>>>> >
>>>>>> > On Mon, Mar 1, 2010 at 12:35, Michael Gogins  wrote:
>>>>>> >> As I have mentioned before, SCons supports Linux packages as a target
>>>>>> >> in SConstruct files.
>>>>>> >>
>>>>>> >> I repeat my proposal that we move the good work that people have done
>>>>>> >> on the Debian package into SConstruct, insofar as that is possible (I
>>>>>> >> am not up to speed on what it takes to get a built package into the
>>>>>> >> official repositories).
>>>>>> >>
>>>>>> >> It would be helpful to have all the bugs and other issues related to
>>>>>> >> the packages in the main build file, and packages that we could build
>>>>>> >> could easily be hosted on SourceForge and cSounds.com. Also, people
>>>>>> >> who wanted to build and install from scratch would probably find this
>>>>>> >> an easier and more complete method.
>>>>>> >>
>>>>>> >> Regards,
>>>>>> >> Mike
>>>>>> >>
>>>>>> >> On Mon, Mar 1, 2010 at 10:18 AM, Steven Yi  wrote:
>>>>>> >>> Well, the whole point of a beta is to release it twice, once (or
>>>>>> >>> possibly more) to get feedback and then a final release.  Following
>>>>>> >>> such a practice (or an unstable/stable release) would have mitigated a
>>>>>> >>> lot of the issues with 5.12.
>>>>>> >>>
>>>>>> >>> As for Linux distro, I think we should not do a release of linux
>>>>>> >>> binaries.  I think it causes more harm than good, frankly, as really
>>>>>> >>> it might only work on the distro it was built on. I think we should
>>>>>> >>> consider either putting up packages in debs and RPMS (could do both
>>>>>> >>> Fedora and SuSe RPM's) or creating a repo for them.
>>>>>> >>>
>>>>>> >>> On Mon, Mar 1, 2010 at 10:05 AM, jpff  wrote:
>>>>>> >>>> The inadvertent bugs in 5.12 seem almost settled.  Did we ought to
>>>>>> >>>> release a 5.13 (or a 5.12.5) soonish?
>>>>>> >>>>  I have added some more defensive code in ftload/ftsave, and there is
>>>>>> >>>> still the question as to whether we should allow a-rate multiple
>>>>>> >>>> assigns.  There is also the (a?b:c) construct in the new parser.
>>>>>> >>>>
>>>>>> >>>> I was not very happy with the beta-release we did earlier as it
>>>>>> >>>> involved all packagers doing the thing twice.  And there is the ongoing
>>>>>> >>>> Linux distribution problem -- in another large cross-platform project
>>>>>> >>>> we distributed many (about 6 I think) sets of .o files and a script
>>>>>> >>>> to try them all until one version linked.  I would rather not do that
>>>>>> >>>> again!
>>>>>> >>>>
>>>>>> >>>> ==John ffitch
>>>>>> >>>>
>>>>>> >>>> ------------------------------------------------------------------------------
>>>>>> >>>> Download Intel® Parallel Studio Eval
>>>>>> >>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>>>> >>>> proactively, and fine-tune applications for parallel performance.
>>>>>> >>>> See why Intel Parallel Studio got high marks during beta.
>>>>>> >>>> http://p.sf.net/sfu/intel-sw-dev
>>>>>> >>>> _______________________________________________
>>>>>> >>>> Csound-devel mailing list
>>>>>> >>>> Csound-devel@lists.sourceforge.net
>>>>>> >>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>> >>>>
>>>>>> >>>
>>>>>> >>> ------------------------------------------------------------------------------
>>>>>> >>> Download Intel® Parallel Studio Eval
>>>>>> >>> Try the new software tools for yourself. Speed compiling, find bugs
>>>>>> >>> proactively, and fine-tune applications for parallel performance.
>>>>>> >>> See why Intel Parallel Studio got high marks during beta.
>>>>>> >>> http://p.sf.net/sfu/intel-sw-dev
>>>>>> >>> _______________________________________________
>>>>>> >>> Csound-devel mailing list
>>>>>> >>> Csound-devel@lists.sourceforge.net
>>>>>> >>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>> >>>
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >> --
>>>>>> >> Michael Gogins
>>>>>> >> Irreducible Productions
>>>>>> >> http://www.michael-gogins.com
>>>>>> >> Michael dot Gogins at gmail dot com
>>>>>> >>
>>>>>> >> ------------------------------------------------------------------------------
>>>>>> >> Download Intel® Parallel Studio Eval
>>>>>> >> Try the new software tools for yourself. Speed compiling, find bugs
>>>>>> >> proactively, and fine-tune applications for parallel performance.
>>>>>> >> See why Intel Parallel Studio got high marks during beta.
>>>>>> >> http://p.sf.net/sfu/intel-sw-dev
>>>>>> >> _______________________________________________
>>>>>> >> Csound-devel mailing list
>>>>>> >> Csound-devel@lists.sourceforge.net
>>>>>> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>> >>
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > --
>>>>>> >
>>>>>> > Saludos,
>>>>>> > Felipe Sateler
>>>>>> >
>>>>>> > ------------------------------------------------------------------------------
>>>>>> > Download Intel® Parallel Studio Eval
>>>>>> > Try the new software tools for yourself. Speed compiling, find bugs
>>>>>> > proactively, and fine-tune applications for parallel performance.
>>>>>> > See why Intel Parallel Studio got high marks during beta.
>>>>>> > http://p.sf.net/sfu/intel-sw-dev
>>>>>> > _______________________________________________
>>>>>> > Csound-devel mailing list
>>>>>> > Csound-devel@lists.sourceforge.net
>>>>>> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>> >
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Saludos,
>>>>> Felipe Sateler
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Download Intel® Parallel Studio Eval
>>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>>> proactively, and fine-tune applications for parallel performance.
>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Michael Gogins
>>>> Irreducible Productions
>>>> http://www.michael-gogins.com
>>>> Michael dot Gogins at gmail dot com
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Download Intel® Parallel Studio Eval
>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>> proactively, and fine-tune applications for parallel performance.
>>>> See why Intel Parallel Studio got high marks during beta.
>>>> http://p.sf.net/sfu/intel-sw-dev
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> Saludos,
>>> Felipe Sateler
>>>
>>> ------------------------------------------------------------------------------
>>> Download Intel® Parallel Studio Eval
>>> Try the new software tools for yourself. Speed compiling, find bugs
>>> proactively, and fine-tune applications for parallel performance.
>>> See why Intel Parallel Studio got high marks during beta.
>>> http://p.sf.net/sfu/intel-sw-dev
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>> ------------------------------------------------------------------------------
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
>
>
> --
>
> Saludos,
> Felipe Sateler
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net