I'm thinking this outdated directory probably confuses more than it 
helps. So it should probably be removed.
Now, I could import my own files into CVS, but I'd like to keep them 
separate because:

1. In the current workflow for the debian packages (which includes one 
more person not directly interested in csound, but indirectly through 
TamTam), it would involve working in the current git repository we have, 
and then copying back the changes into CVS.

2. Keeping the debian-specific changes separate allows me some freedom I 
would otherwise not have (eg, a bug in the installation scripts can be 
fixed within debian without creating unnecessary noise).

3. The script is not really fit for a simple import into CVS. There is 
at least the issue of scansyn which has to be stripped for debian.

4. Related to the last point, the debian packages make a few decisions 
on behalf of the users (which opcodes to build, etc), which are not 
always easily overriden, and as such would not be that useful to the few 
people that build csound from source (they probably are building for a 
reason).

Saludos,
Felipe Sateler

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I think it should go as you seem to have Debian package buulding under
control.  We do not have an openSuSE build directory, or RedHat or....
The last point is more to do with controlling loadable opcodes and that
shoudl be addressed in a generic way.  I did write a utility that created
an accurate data base of opcodes to libraries, but changes in alsa seem to
stop it working.  Perhaps when I have time (ie in teh new year) I will get
back to it and controlling opcodes as I originally intended.

==John ff
  ....back to writing exam papers



> I'm thinking this outdated directory probably confuses more than it
> helps. So it should probably be removed.
> Now, I could import my own files into CVS, but I'd like to keep them
> separate because:
>
> 1. In the current workflow for the debian packages (which includes one
> more person not directly interested in csound, but indirectly through
> TamTam), it would involve working in the current git repository we have,
> and then copying back the changes into CVS.
>
> 2. Keeping the debian-specific changes separate allows me some freedom I
> would otherwise not have (eg, a bug in the installation scripts can be
> fixed within debian without creating unnecessary noise).
>
> 3. The script is not really fit for a simple import into CVS. There is
> at least the issue of scansyn which has to be stripped for debian.
>
> 4. Related to the last point, the debian packages make a few decisions
> on behalf of the users (which opcodes to build, etc), which are not
> always easily overriden, and as such would not be that useful to the few
> people that build csound from source (they probably are building for a
> reason).
>
> Saludos,
> Felipe Sateler
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>



------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Gone.

jpff@cs.bath.ac.uk wrote:
> I think it should go as you seem to have Debian package buulding under
> control.  We do not have an openSuSE build directory, or RedHat or....
> The last point is more to do with controlling loadable opcodes and that
> shoudl be addressed in a generic way.  I did write a utility that created
> an accurate data base of opcodes to libraries, but changes in alsa seem to
> stop it working.  Perhaps when I have time (ie in teh new year) I will get
> back to it and controlling opcodes as I originally intended.
> 
> ==John ff
>   ....back to writing exam papers
> 
> 
> 
>> I'm thinking this outdated directory probably confuses more than it
>> helps. So it should probably be removed.
>> Now, I could import my own files into CVS, but I'd like to keep them
>> separate because:
>>
>> 1. In the current workflow for the debian packages (which includes one
>> more person not directly interested in csound, but indirectly through
>> TamTam), it would involve working in the current git repository we have,
>> and then copying back the changes into CVS.
>>
>> 2. Keeping the debian-specific changes separate allows me some freedom I
>> would otherwise not have (eg, a bug in the installation scripts can be
>> fixed within debian without creating unnecessary noise).
>>
>> 3. The script is not really fit for a simple import into CVS. There is
>> at least the issue of scansyn which has to be stripped for debian.
>>
>> 4. Related to the last point, the debian packages make a few decisions
>> on behalf of the users (which opcodes to build, etc), which are not
>> always easily overriden, and as such would not be that useful to the few
>> people that build csound from source (they probably are building for a
>> reason).
>>
>> Saludos,
>> Felipe Sateler
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>> 30-Day
>> trial. Simplify your report design, integration and deployment - and focus
>> on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>>
> 
> 
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


-- 
Saludos,
Felipe Sateler

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net