I think what happens with bzero and such is that people use autoscan to
prepare a preliminary configure.ac. Autoscan reads any existing
configure.ac and source files, and tries to figure out what libraries and
functions configure needs to probe for. Autoscan writes configure.scan
which people tend to turn into configure.ac by declaring the module and
adding some tests. So tests pile up in configure.ac over time.

I would prefer a simpler autotools build system, partly because a simpler
one takes less time to regenerate, partly because by requiring the presence
of PortAudio, libsndfile, FLTK, PortMidi, and whatnot, we are virtually
assuring the presence of most of the operating system facilities required
to build Csound.

I am hoping that by using these libraries, we can get all, or almost all,
non-portable headers and functions out of Csound. Then the autotools
scripts won't have much to do except generate usable makefiles from
Makefile.am.

Original Message:
-----------------
From:  jpff@codemist.co.uk
Date: Sun, 18 Jan 2004 21:30:48 +0000
To: csound-dev@eartha.mills.edu, csound-dev@eartha.mills.edu,
csound-dev@eartha.mills.edu
Subject: [CSOUND-DEV:3954] Re: How to configure


.... I did
cd csound
make winX11.o
cd ..

and then make is running.

I am still seeing a distressing number of undeclared functions -- I
have Csound so there were no such warnings -- but what does "-I
../[csound" mean as a option to gcc?]

I am also rather at a loss as to whu configure asks if bzero (for
example) exists as this not an ANSI C function and Csound should not
care a d*mn whether it does or not.  That suggests some fundamental
errors in the configuration mechyanism to me.

==John ffitch


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

"gogins@pipeline.com"  writes:

> I think what happens with bzero and such is that people use autoscan
> to prepare a preliminary configure.ac. Autoscan reads any existing
> configure.ac and source files, and tries to figure out what
> libraries and functions configure needs to probe for. Autoscan
> writes configure.scan which people tend to turn into configure.ac by
> declaring the module and adding some tests. So tests pile up in
> configure.ac over time.

I am quite sure that the original author of configure.in in the
csound5 module ran autoscan to generate the function tests.  This file
was used as the basis of configure.ac in the csound module.  I ran
autoscan in the csound module and it produced the same tests.  The
trouble is, the results of nearly all of the tests are ignored by the
sources, and are thus completely useless!

In my humble opinion, all of those tests should be removed unless the
source explicitly check the results of the test.

John

>>>>> "John" == John D Ramsdell  writes:

 John> I am quite sure that the original author of configure.in in the
 John> csound5 module ran autoscan to generate the function tests.  This file
 John> was used as the basis of configure.ac in the csound module.  I ran
 John> autoscan in the csound module and it produced the same tests.  The
 John> trouble is, the results of nearly all of the tests are ignored by the
 John> sources, and are thus completely useless!

Yes I did use some tool whose name I forget (might have been autoscan)
and no there was no mention of things not used.  If there was I
removed anyway.  I spent a great deal of time making the source close
to ANSI standard, so functions like bzero, index, rindex,... were
removed long ago even if they were used once.  Similarly I added
proper prototypes, and on my machines Csound built with only warnings
about unused variables and labels (mainly due to conditional
compilation.  All I seek is that degree of precision in the OLD system
which used to be like that.  I am aware that Csound5 is not quite that
organised yet, but it will be.

==John ffitch

jpff@codemist.co.uk writes:

> ....  I spent a great deal of time making the source close to ANSI
> standard, so functions like bzero, index, rindex,... were removed
> long ago even if they were used once.  Similarly I added proper
> prototypes, and on my machines Csound built with only warnings about
> unused variables and labels (mainly due to conditional compilation.

Nice work!  You identified a bug I just patched.  The bug was not
present for those using the original makefiles.  The problem was that
SYS5 was not being defined when it should have been.  Now,
csound/autoheader.h sets it when string.h is available.

John