I am glad to see libsndfile in the utilities.

However, there is a problem. Your commits to the utilities break the CVS
build, which assumes that most utilities will link with libustub.a, which
contains functions such as err_printf, synterr, and many others, and that
the remaining utilities such as cscore and dnoise link with libcsound.a, the
Csound API library. The CVS build has been building all the utilities for
some time now.

Either I must now remove all the conflicting code from the utilities and you
must adopt the SCons build system (or change your makefiles to build the
ustub library and otherwise make the same targets as the SCons build
system), or I must change the SCons build system to make the same targets as
your makefiles.

I think it makes more sense to use the ustub library which keeps duplicate
source code to a minimum, but please let me know which you prefer. If you
want me to change SConstruct to build the same targets from the same sources
as your makefiles, I will do that.

For the time being, I am removing the redundant code from the utility
programs, and keeping the ustub library.

============================================
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: 
To: "Csound Developers Discussion List" 
Sent: Monday, March 15, 2004 3:30 PM
Subject: [CSOUND-DEV:4328] Getting in step


> I am almost there now.  Just before supper I did manage to compile it
> all, but some problems have crept back.  In principle all the
> utilities now use linsndfile.  I have tested hetro and a little
> others, but will finish the check later.  There are still some
> differences between CVS and my files but I am working on them.
>
> On a different note, am I alone is having noisy output from PortAudio?
> My standard alias test is unusable with PA.
>
> ==John ffitch
>

As far as I could see there was no CVS build.  I have been unable to
build from autoconf for weeks and weeks.  The code I have here
certainly compiles and runs.

I was unaware of any ustub library; does it have a description?  Did
not see any mail about it.  If I knew what it was I might use it.  I
am aware that the CVS system does not build -- but my code does.

I do not know the answer to
> If you want me to change SConstruct to build the same targets from
> the same sources as your makefiles, I will do that
as I know nothing about SConstruct.  You may be aware that I have
repeatedly asked what the purpose of autoconf is, and this seems to be
more code to solve an unknown problem
==John ffitch

The "unknown problem" is only unknown to you as your static makefiles
work for you without you ever having to touch them.  If a good number of
us here are looking at auto-configuring build systems, don't you think
maybe there's a real issue at hand and denying that a problem exists
really won't help get Csound to build on everyone else's computer?  

I have never had Csound build out-of-the-box except in the cases of the
Autotools build for Csound4 and now the SCons system in Csound5. 

Autoconf and SConstruct both address the same issues of analyzing the
system being built on and building the sources depending on what's
available.  By automating this, builds becomes easier to do as the
person building doesn't have to spend time tracking what they have and
configuring the Makefile as it configures itself.  

Regardless, the build system issue is a moot point now.  You have your
Makefile's in the CVS.  The SConstruct file does not generate any files
that can possibly overwrite your Makefile's (as was the case with the
Autotools).  The two systems can coexist without problems so hopefully
we can all have access to build systems that will work for each of us.  

The only thing now is to keep them in sync, so if files are reorganized
in one build system that they are updated in the other build system.  

As for ustub, please see:

http://eartha.mills.edu:8000/guest/archives/CSOUND-DEV/log0402/msg00005.html
http://eartha.mills.edu:8000/guest/archives/CSOUND-DEV/log0402/msg00007.html

I guess I was aware of it from the autoconf builds as well as from
reading the CVS annotations when doing updates; I can see how it may
have gotten missed though.  

steven


On Mon, 2004-03-15 at 23:51, jpff@codemist.co.uk wrote:
> As far as I could see there was no CVS build.  I have been unable to
> build from autoconf for weeks and weeks.  The code I have here
> certainly compiles and runs.
> 
> I was unaware of any ustub library; does it have a description?  Did
> not see any mail about it.  If I knew what it was I might use it.  I
> am aware that the CVS system does not build -- but my code does.
> 
> I do not know the answer to
> > If you want me to change SConstruct to build the same targets from
> > the same sources as your makefiles, I will do that
> as I know nothing about SConstruct.  You may be aware that I have
> repeatedly asked what the purpose of autoconf is, and this seems to be
> more code to solve an unknown problem
> ==John ffitch
> 
> 

>>>>> "stevenyi" == stevenyi   writes:

 stevenyi> The "unknown problem" is only unknown to you as your static makefiles
 stevenyi> work for you without you ever having to touch them.

Not so.  I had and have Makefile.in files and it was the case that
configure was the route.  That was changed so I could no longer use it.

                                                                If a good number of
 stevenyi> us here are looking at auto-configuring build systems, don't you think
 stevenyi> maybe there's a real issue at hand and denying that a problem exists
 stevenyi> really won't help get Csound to build on everyone else's computer?  

That is correct; I do not think there is a problem.

 stevenyi> I have never had Csound build out-of-the-box except in the cases of the
 stevenyi> Autotools build for Csound4 and now the SCons system in Csound5. 

I built csound4 on six different platforms without confusions of autotools

 stevenyi> Autoconf and SConstruct both address the same issues of analyzing the
 stevenyi> system being built on and building the sources depending on what's
 stevenyi> available.  By automating this, builds becomes easier to do as the
 stevenyi> person building doesn't have to spend time tracking what they have and
 stevenyi> configuring the Makefile as it configures itself.  

Disagree.  My experience is that it means that no time is spent on the
code and all available time is spent attempting to get the autoconf
to run.

 stevenyi> Regardless, the build system issue is a moot point now.  You have your
 stevenyi> Makefile's in the CVS.  The SConstruct file does not generate any files
 stevenyi> that can possibly overwrite your Makefile's (as was the case with the
 stevenyi> Autotools).  The two systems can coexist without problems so hopefully
 stevenyi> we can all have access to build systems that will work for each of us.  

The trouble is that structures are being changed and I do not know.
Look, the CVS system was not even updating all my files, if I did a
complete new d/load I was presented with a system that did not compile.

 stevenyi> The only thing now is to keep them in sync, so if files are reorganized
 stevenyi> in one build system that they are updated in the other build system.  

That is precisely what I have been attempting to do.  From where I sit
others were arranging that I was not in sync

 stevenyi> As for ustub, please see:

 stevenyi> http://eartha.mills.edu:8000/guest/archives/CSOUND-DEV/log0402/msg00005.html
says that something is going to happen
 stevenyi> http://eartha.mills.edu:8000/guest/archives/CSOUND-DEV/log0402/msg00007.html
was while I was explaining thatI could not even get a system that
compiled.  Neither of these explain what had changed.

 stevenyi> I guess I was aware of it from the autoconf builds as well as from
 stevenyi> reading the CVS annotations when doing updates; I can see how it may
 stevenyi> have gotten missed though.  

OK for you, but the autoconf never never ever built for me.  As I do
not know the language with is used for autoconf it never occurred to me
to read it.  Actually I wanted to get the sound library fixed.

 stevenyi> steven

==John ffitch

>                                                                 If a good number of
>  stevenyi> us here are looking at auto-configuring build systems, don't you think
>  stevenyi> maybe there's a real issue at hand and denying that a problem exists
>  stevenyi> really won't help get Csound to build on everyone else's computer?  
> 
> That is correct; I do not think there is a problem.
> 
>  stevenyi> I have never had Csound build out-of-the-box except in the cases of the
>  stevenyi> Autotools build for Csound4 and now the SCons system in Csound5. 
> 
> I built csound4 on six different platforms without confusions of autotools


You have your experience and I have mine (Redhat 9, Fedora Core 1,
Win98, Win2k, WinXP, and MacOSX 10.1 and 10.2, all from the past
month).  Granted, two of these OS's I tested on are on virtual machines
using VMWare, and one system is SourceForge's compile farm.  I'm really
not making any of this up for the sake of arguing; I really just want to
find the solution that will work out for you and everyone else here and
all I can offer is what I've come across.

>  stevenyi> Autoconf and SConstruct both address the same issues of analyzing the
>  stevenyi> system being built on and building the sources depending on what's
>  stevenyi> available.  By automating this, builds becomes easier to do as the
>  stevenyi> person building doesn't have to spend time tracking what they have and
>  stevenyi> configuring the Makefile as it configures itself.  
> 
> Disagree.  My experience is that it means that no time is spent on the
> code and all available time is spent attempting to get the autoconf
> to run.

Well, I would say I agree and disagree then.  Autoconf I liked as it was
working for me on different platforms but I found it difficult to make
my way through the file so it was hard to make changes.  SCons I found
to be really nice for me as it so far has worked out for myself and it
is easy for me to edit and builds seem to run faster. I find changes to
the build system easier to manage with an SCons file than a Makefile.  


>  stevenyi> Regardless, the build system issue is a moot point now.  You have your
>  stevenyi> Makefile's in the CVS.  The SConstruct file does not generate any files
>  stevenyi> that can possibly overwrite your Makefile's (as was the case with the
>  stevenyi> Autotools).  The two systems can coexist without problems so hopefully
>  stevenyi> we can all have access to build systems that will work for each of us.  
> 
> The trouble is that structures are being changed and I do not know.
> Look, the CVS system was not even updating all my files, if I did a
> complete new d/load I was presented with a system that did not compile.

For structural issues, perhaps we should all get in the practice of
using some kind of header in the subject line of our email, something
like:

[BUILD CHANGE] - File moved from here to there, etc.

I'm sure you, like myself and others here, get *way* too much email in a
day.  Perhaps this would be the best way for any of us to extend the
courtesy of letting others know what changes are in concrete terms. 
Alternatively, we could add such messages to the ChangeLog so as not to
flood this list.

As for CVS, I have no idea.  I have never had issues with CVS on csound
or blue in terms of updating files with the exception of when
SourceForge was doing maintenance and the CVS was not accessible.  I
also regularly do complete fresh checkouts to test compiles.  


>  stevenyi> The only thing now is to keep them in sync, so if files are reorganized
>  stevenyi> in one build system that they are updated in the other build system.  
> 
> That is precisely what I have been attempting to do.  From where I sit
> others were arranging that I was not in sync

Well, I think everyone is a little out of sync at the moment, as there
are files in the CVS that seem to be relevant to the SConstruct build
and not yours, and vice versa.  The CVS also needs tidying in general as
there are file in there that don't need to be (generated files from
builds, i.e. .xmg files; duplicate ugens6, 7, and 9 in Opcodes and OOps;
etc.).  


>  stevenyi> As for ustub, please see:
> 
>  stevenyi> http://eartha.mills.edu:8000/guest/archives/CSOUND-DEV/log0402/msg00005.html
> says that something is going to happen
>  stevenyi> http://eartha.mills.edu:8000/guest/archives/CSOUND-DEV/log0402/msg00007.html
> was while I was explaining thatI could not even get a system that
> compiled.  Neither of these explain what had changed.

>From Michael's message in the second link above: 

Summary of changes:

I introduced one Makefile.am to build all targets.

I renamed some files in the anal and util directories to avoid duplicate
filenames.

Most opcodes are now working plugins.

I moved a few opcodes from Opcodes back to OOps due to complex
interdependencies.

The Csound console executable links with the Csound API.

I added code to csoundLoadExternals to automatically load all plugin opcodes
in $OPCODEDIR (on systems with dirent.h).

I added a Top/ustub.c file to work with ustub.h and to replace duplicate
code collected from utility sources.

I added a libustub.a library containing ustub.c and a good chunk of csound
to link all utilities.


>  stevenyi> I guess I was aware of it from the autoconf builds as well as from
>  stevenyi> reading the CVS annotations when doing updates; I can see how it may
>  stevenyi> have gotten missed though.  
> 
> OK for you, but the autoconf never never ever built for me.  As I do
> not know the language with is used for autoconf it never occurred to me
> to read it.  Actually I wanted to get the sound library fixed.

Yes, like I said, I can understand how this got missed.  I'd like to
move past all of this as well and get to rebuilding some opcode plugins
I have here for csound5 and testing out the API with Java amongst other
things.  Since I do understand the SCons file and the Makefiles, I'll
try to spend some time figuring out what are the differences.  Hopefully
we can all get back in sync soon and move on to other things.

Thanks,
steven