I totally agree, but how to tell which tests are used and which not -
quickly enough so that it makes sense to remove them?

============================================
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: Monday, January 19, 2004 7:38 AM
Subject: [CSOUND-DEV:3964] Re: How to configure


> "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
>

"Michael Gogins"  writes:

> I totally agree, but how to tell which tests are used and which not -
> quickly enough so that it makes sense to remove them?

I would carefully read the output of the command

$ grep HAVE_ */*.c */*.h */*.cpp */*/*.c */*/*.h

if I were to perform the test in the csound module.  I think all the
function tests define a preprocessor variable that begins with HAVE_.
The problem with this approach is that maybe the reason the
preprocessor variable is not used is simply someone has yet to add in
the appropriate conditional.  

For the csound module, things are a little more complicated than for
the csound5 module.  In the csound5 module, all includes of malloc.h
should be wrapped with a conditional preprocessor test checking the
presence of that file.  If the csound module is changed in that way,
it will break the non-GNU build system makefiles.  Of course, the
correct way to deal with malloc is to make sure all code works using
stdlib.h, and never load malloc.h.

Maybe this issue is simply not important enough to worry about now.
When the code is stable, the results of grep will be definitive.

John

I retested the original makefiles in the csound module and was able to
build csound after copying csound/Makefile.lnx to csound/Makefile, and
modifying it so it knew the location of my FLTK and X11 header files.
All's well on Red Hat Linux.

John

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

I just do not understand this:

 John> For the csound module, things are a little more complicated than for
 John> the csound5 module.  In the csound5 module, all includes of malloc.h
 John> should be wrapped with a conditional preprocessor test checking the
 John> presence of that file.  If the csound module is changed in that way,
 John> it will break the non-GNU build system makefiles.  Of course, the
 John> correct way to deal with malloc is to make sure all code works using
 John> stdlib.h, and never load malloc.h.

That was the case.  Who changed it?

==John ffitch

jpff@codemist.co.uk writes:

>  John> ....  Of course, the
>  John> correct way to deal with malloc is to make sure all code works using
>  John> stdlib.h, and never load malloc.h.
> 
> That was the case.  Who changed it?

The only change I made was to wrap the includes of malloc.h in the
existing source base with an additional preprocessor clause of
"!defined DARWIN" so that the system builds on MacOS X.  Here is the
ChangeLog entry:

2003-12-24  John D. Ramsdell  

	* csound/pvoc.c, csound/dpwelib.h: Added test for DARWIN so the
	files don't include malloc.h on MacOS X.  Csound now builds and
	installs on MacOS X.

By the way, it appears that the sources conditionally include sections
of code only when LINUX is defined, but it should include that code
when __STDC__ is defined.  For example, in util2/mixer/xtrct.c, line
41, we find:

#ifdef LINUX
#include 
#endif

I think unistd.h should be included when compiling on Cygwin too.  I
wouldn't be surprised if there are more problems like this for Cygwin.
The file csound/autoheader.h contains the definitions currently used
to map the preprocessor symbols defined during the configuration
process into definitions for the ones that exist in the source.

John