The situation as I understand it is thus. Please, anyone involved correct
me if I am wrong. 

In short, the build system story is complicated by hopes to soon release
Csound 5.

I and John Ramsdell have been urging adoption of a GNU autotools build
system for Csound. I have always found the old makefile-based system
unusable, and have always ended up creating my own makefiles.

John Fitch (I think) implemented a new build system based on a configure.in
and makefile.in for Csound 4. I criticized this as not using automake, and
John Ramsdell changed the build system to use recursive Makefile.ams, but
John Fitch does not use it, and has complained it has caused him serious
problems. Therefore, John Ramsdell has adopted his new build system only in
his own package (wxCsound). 

I am trying to get Csound 5 into a releasable state and have stopped
contributing to Csound 4. I am working on a new build system, with a single
Makefile.am, in Csound 5, with the existing directory structure. 

I changed my mind about changing the directory structure, since John
Fitch's existing directories helpfully reflect the structure of the Csound
code while it is in transition.

The advantage of my new build system is that extending Csound will require
merely adding new sources to the one Makefile.am.

I am making good progress, but I am only testing on Cygwin. When the system
is working on Cygwin I will be able to test it on Red Hat Linux at home,
but I have no easy way of testing on any other Linux or on OS X.

It is not clear when Csound 5 will be released, but when it is, it will at
least use libsndfile, PortAudio, and PortMidi, have a better plugin
architecture as well as a standard GUI front end, and have a single build
system for all GNU-able systems, including Windows (with Cygwin).


Original Message:
-----------------
From: Dave Phillips dlphilp@bright.net
Date: Fri, 30 Jan 2004 10:15:18 -0500
To: csound-dev@eartha.mills.edu
Subject: [CSOUND-DEV:4018] Re: How to configure


Hi John:

  I'm sorry I haven't been able to test your suggestions, I've simply 
been too busy with other projects.

  I must also confess that I'm quite confused regarding the recommended 
source archive for Csound for Linux.
I've tried three source packages recently: the tarball at dream/newest 
at Bath, the public source tarball at SourceForge,
and the CVS sources (for Csound4). Only the last package builds on my 
system. I have already reported the build failures
here. I have also built the sources from your wxcsound package; however, 
I hesitate to recommend them because I'm
trying to stay with the canonical track. Be assured, there's nothing 
wrong with your stuff.

  I'm preparing new materials for Rick Boulanger's site and for the 
Csound profile in my book. I'm currently recommending
the CVS sources and have created a brief page of instructions for 
downloading and building those sources under Linux. I'll
probably have stuff up at cSounds.com within a week or so.

  Btw, I've reworked Oeyvind Brandtsegg's ImproSculpt to run under 
Csound 4.23f08 (CVS). It runs
very nicely, and I wanted to pass my thanks to the Csound developers.

Best,

dp


John D. Ramsdell wrote:

>Dave Phillips  writes:
>
>  
>
>>  So I logged back into my Demudi partition, got the correct sources,
>>and ran './configure --with-fltk'. Unfortunately Demudi ...
>>    
>>
>
>Darn, I thought Debian support would be easy.  Dave, please create a
>fresh unarchive of the sources, cd into csound, and then add the
>following text to a file:
>
>./configure --prefix=$HOME/opt/csound
>cat config.log
>make
>make install
>
>Finally, use the file as input to nohup, and send me the generated
>nohup.out.  I should be able to figure out what went wrong from that
>info.
>
>John
>
>
>  
>


--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .

>>>>> "gogins" == gogins@pipeline com  writes:

 gogins> The situation as I understand it is thus. Please, anyone
 gogins> involved correct me if I am wrong.

 gogins> In short, the build system story is complicated by hopes to
 gogins> soon release Csound 5.

 gogins> I and John Ramsdell have been urging adoption of a GNU
 gogins> autotools build system for Csound. I have always found the
 gogins> old makefile-based system unusable, and have always ended up
 gogins> creating my own makefiles.

I realise that I am in a minority but I find Makefiles rather
straightforward.  I was however persuaded to use configure for Csound5

 gogins> John Fitch (I think) implemented a new build system based on
 gogins> a configure.in and makefile.in for Csound 4. I criticized
 gogins> this as not using automake, and John Ramsdell changed the
 gogins> build system to use recursive Makefile.ams, but John Fitch
 gogins> does not use it, and has complained it has caused him serious
 gogins> problems. Therefore, John Ramsdell has adopted his new build
 gogins> system only in his own package (wxCsound).

I had a configure for Csound but it was really aimed at v5.  The
changes to the make in v4.23 completed destroyed my tree and I had to
recover from the Windows machine.  I just do not know how to get back
in step, but as I am only doing bug fixes on 4.23 this should not
worry anyone.

 gogins> I am trying to get Csound 5 into a releasable state and have
 gogins> stopped contributing to Csound 4. I am working on a new build
 gogins> system, with a single Makefile.am, in Csound 5, with the
 gogins> existing directory structure.

 gogins> I changed my mind about changing the directory structure,
 gogins> since John Fitch's existing directories helpfully reflect the
 gogins> structure of the Csound code while it is in transition.

It was the changes to directory structure which was a pain I think.

 gogins> The advantage of my new build system is that extending Csound
 gogins> will require merely adding new sources to the one
 gogins> Makefile.am.

My concerns are still things like Debian not having (in Stable) the
latest autoconf tools.  I rather hope not to have to learn yet another
building system.  I am user to configure-make-make install like I have
done in the last weeks for the kernel, clamd, spamassassin, exim, ....

 gogins> I am making good progress, but I am only testing on
 gogins> Cygwin. When the system is working on Cygwin I will be able
 gogins> to test it on Red Hat Linux at home, but I have no easy way
 gogins> of testing on any other Linux or on OS X.

I am currently running a Redhat7.3 with many (source and rpm)
revisions, on a variety of processors and speeds, as well as a Debian
Stable, and possibly from next week a GenToo system.  I can test on
these without confusing my masters which are on the portable.

 gogins> It is not clear when Csound 5 will be released, but when it
 gogins> is, it will at least use libsndfile, PortAudio, and PortMidi,
 gogins> have a better plugin architecture as well as a standard GUI
 gogins> front end, and have a single build system for all GNU-able
 gogins> systems, including Windows (with Cygwin).

libsndfile is now in my mind a certainty.  As is PortAudio.  PortMidi
still needs work.  Certainly will have the API structure -- I need a
callable, reentrant Csound for research purposes.  I wish I had a
better idea of time-scale.  I am supposed to be marking at present so
time is scarce.  I really do want to incorporate the parser, but that
needs about 10 days without distraction.  linsndfile needs a couple of
days to a workable system, and 2 days after that to clean out the
mis-structures.

==John ff

jpff@codemist.co.uk writes:

> I had a configure for Csound but it was really aimed at v5.  The
> changes to the make in v4.23 completed destroyed my tree and I had
> to recover from the Windows machine.  I just do not know how to get
> back in step, but as I am only doing bug fixes on 4.23 this should
> not worry anyone.

It worries me greatly!  I in no way wanted to destroy your ability to
build the system in the csound module from the original makefiles in
the repository.  This is why I carefully tested that capability on
Linux.

Retaining such capability is critical until it can be confirmed that
the GNU build system works on all platforms of interest.  Recent tests
indicate that the system fails to support Debian stable.  As near as I
can tell, the original makefiles provide the only method for building
on that platform.  The README and comments in csound/Makefile.lnx
describe the non-configure build process.

The good news is that the GNU Build System seems to work on all
platforms of interest other than Debian stable.  The bad news is I
haven't had time to debug the transcript of the build failures on
Debian stable, and a quick look at the transcript just raises
questions.

John

"gogins@pipeline.com"  writes:

> The advantage of my new build system is that extending Csound will
> require merely adding new sources to the one Makefile.am.

Some people think that the single Makefile.am approach to a build
system is superior to the Makefile.am per directory approach.  In
fact, this is the approach I tried first for the csound module.  It
failed for me because there are so many files named main.c in the
various utility directories.  To make it work, you must make sure
there are no duplicate file names anywhere in the directory tree.
Since I didn't think I could rename files, I ended up putting
top-level source files into the csound directory, and then everything
worked out after that change.

One other tip, I strongly recommend you create a libtool-less GNU
build system first, and only after it has been shown to be solid code,
add in libtool support.

John