Could you outline your proposed directory structure in the csound module?
Previously you suggested the standard GNU structure, which is fine with me,
but I don't see exactly how this suggestion fits with that one.

============================================
Michael Gogins
gogins at pipeline period com
Irreducible Productions
CsoundVST, an extended version of Csound for programming music and sound
Available at http://sourceforge.net/projects/csound/
============================================


----- Original Message ----- 
From: "John D. Ramsdell" 
To: "Csound Developers Discussion List" 
Sent: Wednesday, November 26, 2003 4:01 AM
Subject: [CSOUND-DEV:3533] csound4 directory reorganization?


> Does anyone object to me adding a csound directory into the csound
> module, and moving all the files that make up a traditional Csound
> source distibution into it?  In addition to reducing the clutter, this
> change would facilitate adding automake support to CsoundVST.
>
> John
>

"Michael Gogins"  writes:

> Could you outline your proposed directory structure in the csound
> module?  Previously you suggested the standard GNU structure, which
> is fine with me, but I don't see exactly how this suggestion fits
> with that one.

One must keep one's eyes on the prize, and the prize is a well
structured csound5 module.  While the new files configure.ac and
Makefile.am in the csound module make life easier for users of that
package, the real reason to invest effort in configuring this package
is to produce a prototype of the right solution for the csound5
module.

I believe the csound5 module should conform to standard GNU structure,
but I see no value to making the csound module do the same.  Placing
the top-level csound module source files in a csound directory, and
then writing the Makefile.am for the rest of the directories in that
module will help make clear what should be done in the csound5 module.

Already it is clear to me one should organize the the csound5 module
so that program source files are only in in leaf directories,
i.e. directories that contain no directories.  Furthermore, the
sources that make up the library that implements the Csound API should
be placed in their own directory, and windowing software should be
placed elsewhere.  There are more lessons to come as the prototype
evolves.

John

The files in the csound module have been reorganized.  Many of the
files at top-level are now in the csound directory.  The makefiles for
Linux, Iris, Solaris, and MacOS have been modified to reflect the new
structure, and the Linux makefile has been tested.  The only
modifications I had to the current Makefile.lnx was change the
alignment flags and add a line telling where my FLTK headers are
stored.

To get the new system, be sure to update with the -d switch.  To
retrieve the files just before the reorg, use the tag csound-4_23a2.

John

Hi John R,

Just replaced my local csound4 src tree with the new one from cvs and it
autobuilds without a problem on my redhat 9 system. 

On the other hand, I tried to autobuild on MacOSX 10.1.5 and couldn't as
the autoconf version that I had was 2.11.  I also found that OSX
10.1.5's gcc version is 2.95.  I'll have to see if I can update the
autotools package.  

Thanks!
steven



On Sat, 2003-11-29 at 11:25, John D. Ramsdell wrote: 
> The files in the csound module have been reorganized.  Many of the
> files at top-level are now in the csound directory.  The makefiles for
> Linux, Iris, Solaris, and MacOS have been modified to reflect the new
> structure, and the Linux makefile has been tested.  The only
> modifications I had to the current Makefile.lnx was change the
> alignment flags and add a line telling where my FLTK headers are
> stored.
> 
> To get the new system, be sure to update with the -d switch.  To
> retrieve the files just before the reorg, use the tag csound-4_23a2.
> 
> John
> 
> 

stevenyi  writes:

> Hi John R,
> 
> Just replaced my local csound4 src tree with the new one from cvs
> and it autobuilds without a problem on my redhat 9 system.

Good news.  To build on MacOSX, I suggest you build a distribution on
RH9, using "make dist", and then moving csound-4.23a3.tar.gz to the
Mac.  Since this is the first test of the autobuild system on Darwin,
you are on the bleeding edge.  Your feedback on this will be greatly
appreciated.  I don't have access to a Mac, so I cannot do this
testing.  To do complete testing, you should build both with and
without FLTK.

The latest autobuild system builds the programs in anal and util1.  I
haven't gotten to util2, but those programs should not cause problems.
Say Michael, how about adding automake files to the CsoundVST
directory for us?

If makes in anal and util1 break, change the top-level Makefile.am so
it omits them as subdirectories.

John

stevenyi  writes:

> On the other hand, I tried to autobuild on MacOSX 10.1.5 ...

Steven,

I forgot to say something important in my last note.  If you have
build problems on Darwin, be sure to look at csound/autoheader.h.  A
quick fix there may solve problems.

The trick of building distributions on RH9, and the moving them to
the target platform is how I debug for MinGW, which has no autotools.

Finally, I notice is there is something wrong with the automake files
in anal.  The problem appears only when building an RPM, not when
performing an ordinary build.  The main routine in anal/adsyn has
trouble finding files to included that begin with the relative path
"../../csound".  The presence of relative paths in source files seems
strange, don't you think?

John

What is the point of a code freeze if the code is being changed?  Changes 
made to the "froozen" csound directory now mean that I cannot continue 
with my research activity as i foolishly changed to rely on teh CVS files 
rather than my own.  I now cannot rebuild csound, so my student is being 
held up in his work.  Now I know why I did not want to move to a public 
cvs system.

----------------------------------------------------------------------
I guess the point is to improve it...and share responsibilities.
But there should be a stable version somewhere...:)
I'm pretty excited reading the latest development phases...but I hope
Csound won't become a "permanently beta software".
Please indulge my impatience!

Josep M Comajuncosas


-----Mensaje original-----
De: owner-csound-dev@eartha.mills.edu
[mailto:owner-csound-dev@eartha.mills.edu] En nombre de
jpff@cs.bath.ac.uk
Enviado el: domingo, 30 de noviembre de 2003 18:34
Para: Csound Developers Discussion List
Asunto: [CSOUND-DEV:3593] Re: csound directory reorganized

What is the point of a code freeze if the code is being changed?  ...

Improvement maybe, but not in a frozen system.  I do not want to waste my 
time remaking a working system when it was working; far better to spend 
time finishing the new version.  I can remove widgets and sfonts to try to 
get a system that compiles, but there are other things i do not understand 
in cs.h.  It might have been wrong for some time, but I no 
longer have any confidence in csound on the cvs.  Seems like time to cease 
using the CVS.  It would have been better to cease to use it some days 
ago.

Hi John ff and all,

John R has tagged the CVS before changing the directory layout.  To get
the version of cvs prior to the directory changes, you can use:

cvs -d:ext:username@cvs.sourceforge.net:/cvsroot/csound co -r
csound-4_23a2 csound

(replacing username with your sourceforge name).  

As for what's in the CVS at this moment, all of the original Makefile's
are still there, just one level down in the csound directory.  I tried
to build from those just now and got caught with one link error, which
looked pretty easy to fix.  (Using Makefile.lnx). Skipping it for now as
I'm using the autobuild stuff.

I did a diff between the current csound/cs.h  in the csound4 cvs and one
from before the src tree change and the only thing I got was:

< # if !defined __cdecl
< #   define __cdecl
< # endif

which is in the current header.  

If you want the grab earlier versions of cs.h that was originally in the
root dir of the csound module, the history of it is kept in the Attic of
the root dir.  Using the CVS web, it's available here:

http://cvs.sourceforge.net/viewcvs.py/csound/csound/Attic/

with it's complete history since initial checkin.  

Maybe instead of switching out the HEAD branch with the new directory
structure, a branch could have been made for testing and later
reintegrated.  That's a CVS feature that we collectively have not been
taking advantage of, and perhaps would have prevented some hard feelings
in all of this.

I for one am adamant about CVS usage as from my experiences with blue in
CVS the tracking of revisions has come back to save me a number of times
as I backtracked some work.  I hope the above has restored some of your
confidence in CVS.

Thanks, and hope that helps,
steven


On Sun, 2003-11-30 at 09:51, jpff@cs.bath.ac.uk wrote: 
> Improvement maybe, but not in a frozen system.  I do not want to waste my 
> time remaking a working system when it was working; far better to spend 
> time finishing the new version.  I can remove widgets and sfonts to try to 
> get a system that compiles, but there are other things i do not understand 
> in cs.h.  It might have been wrong for some time, but I no 
> longer have any confidence in csound on the cvs.  Seems like time to cease 
> using the CVS.  It would have been better to cease to use it some days 
> ago.
> 
> 

John,

The tag before the reorg is csound-4_23a2.  I'll look into your build
problem immediately.

stevenyi  writes:

> < # if !defined __cdecl
> < #   define __cdecl
> < # endif

This change to cs.h is only active when you define USE_CSOUND_YIELD,
which I'm sure John is not defining.  The only change I made to
widget.cpp is to load autoheader.h.  Its contents are wrapped in a
#ifdef CONFIG_H, so again, nothing should be happening when John
builds.  


> 
> which is in the current header.  
> 
> If you want the grab earlier versions of cs.h that was originally in the
> root dir of the csound module, the history of it is kept in the Attic of
> the root dir.  Using the CVS web, it's available here:
> 
> http://cvs.sourceforge.net/viewcvs.py/csound/csound/Attic/
> 
> with it's complete history since initial checkin.  
> 
> Maybe instead of switching out the HEAD branch with the new directory
> structure, a branch could have been made for testing and later
> reintegrated.  That's a CVS feature that we collectively have not been
> taking advantage of, and perhaps would have prevented some hard feelings
> in all of this.
> 
> I for one am adamant about CVS usage as from my experiences with blue in
> CVS the tracking of revisions has come back to save me a number of times
> as I backtracked some work.  I hope the above has restored some of your
> confidence in CVS.

stevenyi  writes:

> ... I tried to build from those just now and got caught with one
> link error, which looked pretty easy to fix.  (Using
> Makefile.lnx). Skipping it for now as I'm using the autobuild stuff.

Steven, please give the details about this problem or fix it.  I'm
trying to make it so that both build methods work, as not everyone
wants to use the autobuild stuff.

John

John,

I am terribly sorry about the wasted time I caused you this weekend.
While I carefully tagged before the csound directory was reorganized,
and I reported the tag in a message to this mailing list, I buried
this information in a part of the message that not everyone would
read.  I should have placed the tagging information in a more
prominent location.  That simple act would have avoided needless
frustration.

John

jpff@cs.bath.ac.uk writes:

> Improvement maybe, but not in a frozen system.  I do not want to waste my 
> time remaking a working system when it was working; far better to spend 
> time finishing the new version.  I can remove widgets and sfonts to try to 
> get a system that compiles, but there are other things i do not understand 
> in cs.h.  It might have been wrong for some time, but I no 
> longer have any confidence in csound on the cvs.  Seems like time to cease 
> using the CVS.  It would have been better to cease to use it some days 
> ago.

Hi John R,

I just tried a build and with the csound-423a2 sources and I was able to
build without problem.  I checked out the latest sources and don't seem
to be having any problems with that either.  So I guess whatever you
changed since last night fixed up everything for me.  =)

For reference, this is on redhat 9 using Makefile.lnx.  

Thanks,
steven

	

On Mon, 2003-12-01 at 03:40, John D. Ramsdell wrote:
> stevenyi  writes:
> 
> > ... I tried to build from those just now and got caught with one
> > link error, which looked pretty easy to fix.  (Using
> > Makefile.lnx). Skipping it for now as I'm using the autobuild stuff.
> 
> Steven, please give the details about this problem or fix it.  I'm
> trying to make it so that both build methods work, as not everyone
> wants to use the autobuild stuff.
> 
> John
> 
>