Csound Csound-dev Csound-tekno Search About

[CSOUND-DEV:4078] Re: autoreconf -i -f

Date2004-02-22 14:20
From"Michael Gogins"
Subject[CSOUND-DEV:4078] Re: autoreconf -i -f
It looks like you have an earlier version of autoconf. Can you upgrade it?

It also looks like you do not have libtool; you will need it to use this
build system. You should execute "libtoolize" in the root build directory.

My versions:

autoconf (GNU Autoconf) 2.59
automake (GNU automake) 1.7.9
ltmain.sh (GNU libtool) 1.5 (1.1220.2.1 2003/04/14 22:48:00)

The libtool library name warnings occur for me and can safely be ignored.

============================================
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: Sunday, February 22, 2004 9:08 AM
Subject: [CSOUND-DEV:4077] autoreconf -i -f


> gives the following output
> ==John ffitch
>
> automake: both `configure.ac' and `configure.in' present: ignoring
`configure.in'
> automake: configure.ac: `PACKAGE' not defined in `configure.ac'
> automake: configure.ac: `VERSION' not defined in `configure.ac'
> automake: configure.ac: required file `./mkinstalldirs' not found
> automake: configure.ac: required file `./missing' not found
> configure.ac: 20: required file `./ltmain.sh' not found
> Makefile.am:355: CONDITIONAL_SGI does not appear in AM_CONDITIONAL
> Makefile.am:356: CONDITIONAL_USE_RTAUDIO does not appear in AM_CONDITIONAL
> Makefile.am:137: libcsound_la_SOURCES defined both conditionally and
unconditionally
> Makefile.am:361: CONDITIONAL_sun does not appear in AM_CONDITIONAL
> Makefile.am:362: CONDITIONAL_USE_RTAUDIO does not appear in AM_CONDITIONAL
> Makefile.am:367: CONDITIONAL_DEC does not appear in AM_CONDITIONAL
> Makefile.am:368: CONDITIONAL_USE_RTAUDIO does not appear in AM_CONDITIONAL
> Makefile.am:373: CONDITIONAL_HP does not appear in AM_CONDITIONAL
> Makefile.am:374: CONDITIONAL_USE_RTAUDIO does not appear in AM_CONDITIONAL
> Makefile.am:379: CONDITIONAL_WIN32 does not appear in AM_CONDITIONAL
> Makefile.am:380: CONDITIONAL_USE_RTAUDIO does not appear in AM_CONDITIONAL
> Makefile.am:385: CONDITIONAL_LINUX does not appear in AM_CONDITIONAL
> Makefile.am:386: CONDITIONAL_USE_RTAUDIO does not appear in AM_CONDITIONAL
> Makefile.am:391: CONDITIONAL_WINDOWS does not appear in AM_CONDITIONAL
> Makefile.am:392: CONDITIONAL_USE_FLTK does not appear in AM_CONDITIONAL
> Makefile.am:394: CONDITIONAL_USE_FLTK_WIDGETS does not appear in
AM_CONDITIONAL
> Makefile.am:137: libcsound_la_SOURCES multiply defined in condition
> Makefile.am:398: CONDITIONAL_USE_X11 does not appear in AM_CONDITIONAL
> configure.ac: 12: required file `./[H/config.h].in' not found
> configure.ac: 12: required file `./[H/stamp-h.in' not found
> automake: Makefile.am: warning: automake does not support
libcsound_la_SOURCES being defined conditionally
> automake: Makefile.am: `babo.la' is not a standard libtool library name
> automake: Makefile.am: `bbcut.la' is not a standard libtool library name
> automake: Makefile.am: `biquad.la' is not a standard libtool library name
> automake: Makefile.am: `butter.la' is not a standard libtool library name
> automake: Makefile.am: `clfilt.la' is not a standard libtool library name
> automake: Makefile.am: `cross2.la' is not a standard libtool library name
> automake: Makefile.am: `dam.la' is not a standard libtool library name
> automake: Makefile.am: `filter.la' is not a standard libtool library name
> automake: Makefile.am: `flanger.la' is not a standard libtool library name
> automake: Makefile.am: `follow.la' is not a standard libtool library name
> automake: Makefile.am: `grain.la' is not a standard libtool library name
> automake: Makefile.am: `grain4.la' is not a standard libtool library name
> automake: Makefile.am: `hrtferX.la' is not a standard libtool library name
> automake: Makefile.am: `locsig.la' is not a standard libtool library name
> automake: Makefile.am: `lowpassr.la' is not a standard libtool library
name
> automake: Makefile.am: `midiops2.la' is not a standard libtool library
name
> automake: Makefile.am: `midiops3.la' is not a standard libtool library
name
> automake: Makefile.am: `modal4.la' is not a standard libtool library name
> automake: Makefile.am: `nlfilt.la' is not a standard libtool library name
> automake: Makefile.am: `oscbnk.la' is not a standard libtool library name
> automake: Makefile.am: `phisem.la' is not a standard libtool library name
> automake: Makefile.am: `physmod.la' is not a standard libtool library name
> automake: Makefile.am: `pitch.la' is not a standard libtool library name
> automake: Makefile.am: `pluck.la' is not a standard libtool library name
> automake: Makefile.am: `repluck.la' is not a standard libtool library name
> automake: Makefile.am: `scansyn.la' is not a standard libtool library name
> automake: Makefile.am: `scansynx.la' is not a standard libtool library
name
> automake: Makefile.am: `sfont.la' is not a standard libtool library name
> automake: Makefile.am: `sndwarp.la' is not a standard libtool library name
> automake: Makefile.am: `space.la' is not a standard libtool library name
> automake: Makefile.am: `spat3d.la' is not a standard libtool library name
> automake: Makefile.am: `ugensa.la' is not a standard libtool library name
> automake: Makefile.am: `uggab.la' is not a standard libtool library name
> automake: Makefile.am: `ugmoss.la' is not a standard libtool library name
> automake: Makefile.am: `ugsc.la' is not a standard libtool library name
> automake: Makefile.am: `wave_terrain.la' is not a standard libtool library
name
> automake: configure.ac: AC_ARG_PROGRAM must be used in `configure.ac'
> automake: configure.ac: AC_PROG_INSTALL must be used in `configure.ac'
> FATAL ERROR: Autoconf version 2.57 or higher is required for this script
> FATAL ERROR: Autoconf version 2.57 or higher is required for this script
> touch: creating `[H/stamp-h.in': No such file or directory
>

Date2004-02-22 14:48
FromJohn ffitch
Subject[CSOUND-DEV:4079] Re: autoreconf -i -f

Date2004-02-22 14:50
FromJohn ffitch
Subject[CSOUND-DEV:4080] Re: autoreconf -i -f
I think rather that having to upgrade four or five machines to use a more 
complex building system, it would be better to use a system that works 
more easily!

Certainly do not have time today to search out these tools, and no doubt 
their dependencies.

==John

Date2004-02-23 19:42
FromAnthony Kozar
Subject[CSOUND-DEV:4116] Re: autoreconf -i -f
On 2/22/04 9:20 AM, Michael Gogins etched in stone:

> It looks like you have an earlier version of autoconf. Can you upgrade it?

I think that we have already established from people's comments on this list
that there are many current Linux distributions that do not come with the
latest autotools.  I know that I recently installed Mandrake PPC 9.1 and it
had an older version.  My impression was that other major x86 linuxes were
in the same boat.

You cannot expect people to upgrade half a dozen different command-line
tools to the latest versions just to be able to correctly install CSound.
Too many people will simply not be able to do this.  Not everyone is a
programmer.  Not everyone who uses Unix can sort out package dependency
problems, understand why autoconf -i -f fails, etc.

The solution is to find a reasonable version of autotools to work from.
Find out what versions come installed by default on several popular Linux
distributions maybe even going back several versions of those distros and
use the oldest version you find for developing Csound.

We need to start thinking about the Csound end users.

Thanks.

Anthony Kozar
anthony.kozar@utoledo.edu

Date2004-02-23 20:54
Fromsteven yi
Subject[CSOUND-DEV:4118] Re: autoreconf -i -f
Hi Anthony,

End user shouldn't need the autotools to compile as they would get a src 
tarball that has all the auto-stuff predone, so will only need to do 
"./configure; make".  For most end users, they probably shouldn't need 
to compile either and just receive binaries (with installers, as Richard 
Dobson mentioned). 

But I agree with you that we should maybe scale back to an earlier 
version (2.57?) of autotools as it's more likely to be found stock on 
most distributions.  I have no idea what would have to be taken out to 
do that.

steven

p.s. - for OSX, releasing an App bundle wouldn't be likely as csound 
would be released as a commanline tool.  Is there a convention for OSX 
commandline apps for packaging?

>I think that we have already established from people's comments on this list
>that there are many current Linux distributions that do not come with the
>latest autotools.  I know that I recently installed Mandrake PPC 9.1 and it
>had an older version.  My impression was that other major x86 linuxes were
>in the same boat.
>
>You cannot expect people to upgrade half a dozen different command-line
>tools to the latest versions just to be able to correctly install CSound.
>Too many people will simply not be able to do this.  Not everyone is a
>programmer.  Not everyone who uses Unix can sort out package dependency
>problems, understand why autoconf -i -f fails, etc.
>
>The solution is to find a reasonable version of autotools to work from.
>Find out what versions come installed by default on several popular Linux
>distributions maybe even going back several versions of those distros and
>use the oldest version you find for developing Csound.
>
>We need to start thinking about the Csound end users.
>  
>

Date2004-02-24 02:26
FromAnthony Kozar
Subject[CSOUND-DEV:4122] Re: autoreconf -i -f
Sorry, I guess that I had the impression that anyone trying to install
Csound from source would have to go through the same steps that were being
discussed on the list.  If running the configure script does not require
having autotools, then I guess that we are in good shape.

Thanks for the info Steven :)

Anthony Kozar
anthony.kozar@utoledo.edu


On 2/23/04 3:54 PM, steven yi etched in stone:

> End user shouldn't need the autotools to compile as they would get a src
> tarball that has all the auto-stuff predone, so will only need to do
> "./configure; make".  For most end users, they probably shouldn't need
> to compile either and just receive binaries (with installers, as Richard
> Dobson mentioned).