Re: Build system cleanup

["Måns Rullgård" <mans@mansr.com>]

Jan Stary <hans@stare.cz> writes:

> Hi Måns,
>
> On Aug 19 21:40:36, mans@mansr.com wrote:
>> I have done some cleaning of the build system.
>
> thanks, the configure is much more readable now.

That was the general idea.  Those new macros are a bit opaque, though.

> (I would still like to get rid of auto* anyway :-)

Replacing it without losing anything is a huge amount of work.  The
results can be great, but I don't want to spend the next month that
right now.

>> The result is in the
>> 'new-build' git branch.  I'd appreciate if people, especially on BSD,
>> could give it a try and report any problems.
>
> Testing on OpenBSD 6.7-current/amd64.
> It eventually fails with lpc10.h not being found.
> Full log below, comments inline.
>
> 	Jan
>
> $ env AUTOCONF_VERSION=2.69 AUTOMAKE_VERSION=1.16 autoreconf -i
> $ env AUTOCONF_VERSION=2.69 AUTOMAKE_VERSION=1.16 ./configure --prefix=$HOME
> $ make
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> checking for a thread-safe mkdir -p... ./install-sh -c -d
> checking for gawk... no
> checking for mawk... no
> checking for nawk... no
> checking for awk... awk
>
> 	Why does the build process need awk?

I don't know how or why autofoo uses awk.  I didn't ask for a critique
of autoconf.  We all know it's a bit weird.

> checking whether make sets $(MAKE)... yes
> checking whether make supports nested variables... yes
> checking whether make supports nested variables... (cached) yes
> checking build system type... x86_64-unknown-openbsd6.7
> checking host system type... x86_64-unknown-openbsd6.7
> checking how to print strings... print -r
> checking whether make supports the include directive... yes (GNU style)
> checking for gcc... gcc
>
> 	That would be $ gcc --version
> 	gcc (GCC) 4.2.1 20070719

That's an OpenBSD problem, not a SoX problem.

> checking whether the C compiler works... yes
> checking for C compiler default output file name... a.out
> checking for suffix of executables...
> checking whether we are cross compiling... no
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... yes
> checking whether gcc accepts -g... yes
> checking for gcc option to accept ISO C89... none needed
> checking whether gcc understands -c and -o together... yes
> checking dependency style of gcc... gcc3
> checking for a sed that does not truncate output... /usr/bin/sed
> checking for grep that handles long lines and -e... /usr/bin/grep
> checking for egrep... /usr/bin/grep -E
> checking for fgrep... /usr/bin/grep -F
> checking for ld used by gcc... /usr/bin/ld
> checking if the linker (/usr/bin/ld) is GNU ld... yes
> checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
> checking the name lister (/usr/bin/nm -B) interface... BSD nm
> checking whether ln -s works... yes
> checking the maximum length of command line arguments... 393216
> checking whether the shell understands some XSI constructs... yes
> checking whether the shell understands "+="... no
> checking how to convert x86_64-unknown-openbsd6.7 file names to x86_64-unknown-openbsd6.7 format... func_convert_file_noop
> checking how to convert x86_64-unknown-openbsd6.7 file names to toolchain format... func_convert_file_noop
>
> 	Where does the build process 'convert names' and why?

Again, I'm not interested in a critique of autoconf.

> checking for /usr/bin/ld option to reload object files... -r
> checking for objdump... objdump
> checking how to recognize dependent libraries... match_pattern /lib[^/]+(\.so\.[0-9]+\.[0-9]+|\.so|_pic\.a)$
> checking for dlltool... no
> checking how to associate runtime and link libraries... print -r --
> checking for ar... ar
> checking for archiver @FILE support... @
> checking for strip... strip
> checking for ranlib... ranlib
> checking command to parse /usr/bin/nm -B output from gcc object... ok
> checking for sysroot... no
> checking for mt... mt
>
> 	LOL, what?
>
> checking if mt is a manifest tool... no
>
> 	That's a shame.

It's something some systems require when linking.  That's all I know.
Ask the autoconf authors if you must know more.

> checking how to run the C preprocessor... gcc -E
> checking for ANSI C header files... yes
> checking for sys/types.h... yes
> checking for sys/stat.h... yes
> checking for stdlib.h... yes
> checking for string.h... yes
> checking for memory.h... yes
>
> 	No source file seems to include memory.h

And we didn't ask for that check.  Bloody autoconf.

> checking for strings.h... yes
> checking for inttypes.h... yes
> checking for stdint.h... yes
>
> 	No source file seems to include stdint.h

util.h does.  It's where int32_t and friends are defined, so we
definitely need it.

>
> checking for unistd.h... yes
>
> checking for dlfcn.h... yes
>
> 	No source file seems to include dlfcn.h
>
> 	Also, this is not a complete list of the system include files
> 	SoX uses (there's <stdio.h> for example). So what exactly is
> 	the purpose of this list? What is configure supposed to do
> 	once it figures that e.g. unistd.h is not to be found?
> 	(Would that happen anywhere? Does windoes have unistd.h?
> 	Does any POSIX system fail to have any of those?)

Those tests are relics from ancient times when autoconf at least gave
the impression of pretending to support non-GNU systems.  In those days,
before C99 and POSIX, the names of headers and what they declared varied
between systems, even if ultimately the same functionality was often
present.  Features already present in K&R C, such as stdint.h, are
universally supported and have thus never needed a test.  Thanks to the
aforementioned standards, modern systems are much more alike, so many of
these checks are unnecessary now.  I wish autoconf didn't insist on
doing them anyway, but that's a battle I don't want to fight today.  The
current situation is harmless, if silly.

> checking for objdir... .libs
> checking if gcc supports -fno-rtti -fno-exceptions... no
> checking for gcc option to produce PIC... -fPIC -DPIC
> checking if gcc PIC flag -fPIC -DPIC works... yes
> checking if gcc static flag -static works... yes
> checking if gcc supports -c -o file.o... yes
> checking if gcc supports -c -o file.o... (cached) yes
> checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes
> checking whether -lc should be explicitly linked in... yes
> checking dynamic linker characteristics... openbsd6.7 ld.so
> checking how to hardcode library paths into programs... immediate
> checking whether stripping libraries is possible... yes
> checking if libtool supports shared libraries... yes
> checking whether to build shared libraries... yes
> checking whether to build static libraries... yes
> checking for gcc... (cached) gcc
> checking whether we are using the GNU C compiler... (cached) yes
> checking whether gcc accepts -g... (cached) yes
> checking for gcc option to accept ISO C89... (cached) none needed
> checking whether gcc understands -c and -o together... (cached) yes
> checking dependency style of gcc... (cached) gcc3
> checking whether ln -s works... yes
> checking for pkg-config... /usr/bin/pkg-config
> checking pkg-config is at least version 0.9.0... yes
>
> 	Reading configure.ac, it's currently
> 	oggvorbis, opus and flac that get detected via pkg-config;
> 	for other formats, it checks for the header and the lib.
> 	Is this distinction intentional?

Those libraries are sometimes installed in ways that _require_ unusual
-I flags that we can't detect any other way (other than trying half a
dozen variants until something works).  pkg-config provides the
necessary information.  On the flip side, pkg-config can sometimes
tell lies too, so I prefer to avoid it when possible.

> checking whether C compiler accepts -fstack-protector-strong... yes
> checking whether the linker accepts -fstack-protector-strong... yes
> checking whether C compiler accepts -Wall... yes
> checking whether C compiler accepts -Wmissing-prototypes... yes
> checking whether C compiler accepts -Wstrict-prototypes... yes
> checking whether the linker accepts -Wl,-z,defs... yes
> checking whether the linker accepts -Wl,--as-needed... yes
> checking whether byte ordering is bigendian... no
> checking for inline... inline
> checking for ANSI C header files... (cached) yes
>
> checking fcntl.h usability... yes
> checking fcntl.h presence... yes
> checking for fcntl.h... yes
>
> 	So fcntl.h is 'usable'; it is also 'present'; and it exists.
> 	What are these _three_ tests?

There's some kind of explanation in the autoconf manual.

> checking for unistd.h... (cached) yes
> checking byteswap.h usability... no
> checking byteswap.h presence... no
> checking for byteswap.h... no
> checking sys/ioctl.h usability... yes
> checking sys/ioctl.h presence... yes
> checking for sys/ioctl.h... yes
> checking for sys/stat.h... (cached) yes
> checking sys/time.h usability... yes
> checking sys/time.h presence... yes
> checking for sys/time.h... yes
> checking sys/timeb.h usability... no
> checking sys/timeb.h presence... no
> checking for sys/timeb.h... no
> checking for sys/types.h... (cached) yes
> checking sys/utsname.h usability... yes
> checking sys/utsname.h presence... yes
> checking for sys/utsname.h... yes
> checking termios.h usability... yes
> checking termios.h presence... yes
> checking for termios.h... yes
> checking glob.h usability... yes
> checking glob.h presence... yes
> checking for glob.h... yes
> checking fenv.h usability... yes
> checking fenv.h presence... yes
> checking for fenv.h... yes
> checking for strcasecmp... yes
> checking for strdup... yes
> checking for popen... yes
> checking for vsnprintf... yes
> checking for gettimeofday... yes
> checking for mkstemp... yes
> checking for fmemopen... yes
> checking for sigaction... yes
> checking for library containing pow... -lm
> checking for library containing lrint... none required
>
> 	$ nm /usr/lib/libc.so.* | grep -Fw lrint 
> 	$ nm /usr/lib/libm.so.* | grep -Fw lrint
> 	00004a10 T lrint
> 	00017980 T lrint
>
> 	So -lm _is_ required for lrint. Maybe it works by accident,
> 	because -lm is pulled in for pow() anyway.
>
> checking for lrint... yes
>
> 	Yes, in libm.

On some systems it's all libc without a separate libm.  That said, those
checks can probably be cut down a bit.

Bear in mind that SoX predates many interfaces that are now standard.
Much of the cruft was once necessary, or at least warranted.

> checking for special C compiler options needed for large files... no
> checking for _FILE_OFFSET_BITS value needed for large files... no
> checking for _LARGEFILE_SOURCE value needed for large files... no
> checking for gcc option to support OpenMP... unsupported
> checking for ltdl.h... no
> checking for magic.h... no
> checking for zlib.h... yes
> checking for uncompress in -lz... yes
> checking for png.h... no
> checking for mad.h... no
> checking for id3tag.h... no
> checking for lame/lame.h... no
> checking for lame.h... no
>
> 	$ pkg_info -L lame | grep .h$    
> 	/usr/local/include/lame/lame.h
>
> 	OpenBSD installs third-party packages into /usr/local/,
> 	but the configure script does not look there; it porbably
> 	only searches in /usr, because that's where linux distributions
> 	install their packages. (I'm not saying it should
> 	-- I will test the same with -I added to the CPPFLAGS,
> 	as the OpenBSD port of SoX does.)

If your system puts things outside the compiler's default search path,
it is your responsibility to provide the information necessary to use
them.  Setting CFLAGS or CPPFLAGS with the appropriate -I options is one
way.  Depending on the compiler, setting C_INCLUDE_PATH might be another.

> checking for twolame.h... no
> checking for gsm/gsm.h... no
> checking for gsm.h... no
>
> 	This is the same case as above.
>
> checking for lpc10.h... no
>
> 	So why does it try to build lpc support later,
> 	#including the lpc10.h that was not found?

I made a mistake.

> checking for OGGVORBIS... yes
> checking for OPUS... yes
> checking for FLAC... yes
> checking for opencore-amrwb/dec_if.h... no
> checking for vo-amrwbenc/enc_if.h... no
> checking for opencore-amrnb/interf_dec.h... no
> checking for wavpack/wavpack.h... no
> checking for sndio.h... yes
> checking for sio_open in -lsndio... yes
> checking for CoreAudio/CoreAudio.h... no
> checking for alsa/asoundlib.h... no
> checking for ao/ao.h... no
> checking for pulse/simple.h... no
> checking for mmsystem.h... no
> checking for sndfile.h... no
> checking for sys/soundcard.h... no
> checking for sys/audioio.h... no
> checking for sun/audioio.h... no
>
> 	Ha, I didn't have to --disable-sunaudio as before.

Odd, I didn't intentionally change anything.

> checking that generated files are newer than configure... done
> configure: creating ./config.status
> config.status: creating Makefile
> config.status: creating src/Makefile
> config.status: creating lpc10/Makefile
>
> 	Can we please also get rid of the subdirectories,
> 	have eveyrthing in sox-x.y.z, and get rid of the
> 	recursive Makefiles? Currently, it's SUBDIRS = lpc10 src
> 	- src does not need to be separate, and lpc should go
> 	the way of gsm.

I detest recursive make as much as anyone, but for now it's not in the
way of fixing actual bugs.

> config.status: creating sox.pc
> config.status: creating src/soxconfig.h
> config.status: src/soxconfig.h is unchanged
> config.status: executing depfiles commands
> config.status: executing libtool commands
>
> Build options:
>   distro name		  unspecified
>
> 	The only place this is used is to set info->distro
> 	and print it as "issue: %s\n", info->distro.
> 	Because linux has "distros" (and calls them issues?)

I have no idea what that is for.  Regardless, removing it doesn't belong
in this cleanup operation.

>   symlinks		  soxi play rec
>
> Optional libraries:
>   id3tag		  no
>   lame			  no
>   libgsm		  no
>   libltdl		  no
>   libsndfile		  no
>   mad			  no
>   magic			  no
>   opencore-amrnb	  no
>   opencore-amrwb	  no
>   png			  no
>   twolame		  no
>   vo-amrwbenc		  no
>
>   	As mentioned above, many of these are present here,
> 	but ./confogure needs to be told where to look.

So tell it.  That's your job, not mine.

> 	I will send a separate report.
>
> Audio devices:
>   alsa			  no
>   ao			  no
>   coreaudio		  no
>   oss			  no
>   pulseaudio		  no
>   sndio			  yes
>   sunaudio		  no
>   waveaudio		  no
>
>   	Yes.
>
> Optional formats:
>   amrnb			  no
>   amrwb			  no
>   flac			  yes
>   gsm			  no
>   lpc10			  yes
>   mp3			  no
>   oggvorbis		  yes
>   opus			  yes
>   sndfile		  no
>   wavpack		  no
>
> 	This is precisely the pkgconf-detected ones
> 	plus the lpc in tree.
>
> Other options:
>   OpenMP		  no
>   LADSPA effect plugins	  no
>
> Configure finished.  Run 'make' to compile SoX.
>
> hans@box:sox$ make
> Making all in lpc10
> Making all in src
>   CC	   sox.o
> In file included from sox.c:25:
> sox.h:1159: warning: 'cdecl' attribute ignored

As I said in another mail, I'll deal with it.

-- 
Måns Rullgård


_______________________________________________
SoX-devel mailing list
SoX-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-devel