[vorbis-dev] build process patches

[Jack Moffitt]

> - Patch 1: Allowing the user to set CFLAGS/LDFLAGS before running
> configure in all four modules.  All these patches do is essentially:
> Yes, there's other ways of doing it, but this was low-cost, easy to
> understand, and modified very little configure.in code that is already
> there.

That seems reasonable.

> - Patch 2: Allow --prefix to specify where libao, libogg, and libvorbis
> live.  It's a real pain to have to specify --with-ogg-prefix=foo (etc.) on
> all those configure lines.  The most common case is that they're all
> installed in the same place anyway.  Hence, the --prefix directory should
> be checked for libogg (and the rest) as well.

Also reasonable.

> - Patch 3: Allows vorbis-tools packages to be linked statically.  The
> linker flags are in the wrong order for static linking (regardless of your
> compiler), and the wrong automake keyword suffix is used (LDFLAGS instead
> of LDADD).  If you configure vorbis-tools with "--enable-static
> --disable-shared" (these are legal options), oggenc and ogg123 will fail
> to link properly if libao, libogg, or libvorbis were compiled statically
> (which is also legal).

libao cannot be compiled statically can it?  I'm fairly sure the plugins
require it to be dynamic.  They are loaded at runtime with
dlopen/dlsym.  The others could be, except for things which use
libao.  And in fact, the win32 tools which use vorbis and ogg are linked
statically.  I'll fix the mistakes though...

> - Patch 4: The Makefile dependency stuff in automake is ***BROKEN***.  It
> adds CFLAGS that simply are gcc-specific (the automake manual clearly
> states this).  As such, you can't compile with native (i.e., non-gcc)
> compilers (where you can get a substantial performance boost).  To a)
> remove the automake dependency stuff and b) make it portable to other
> compilers, you have to add "no-dependencies" to the AUTOMAKE_OPTIONS line
> in every Makefile.am.
> 
> Yes, this sucks, and yes, dependencies are important for developers.  But
> there are other ways of doing it [yes, they also suck, but they're
> portable].

I don't know what your point is here.  Yes this is a known issue, but
automake is not meant to be used when compiling builds for systems with
proprietary cmpilers.  That's what the tarball from a 'make dist' is for,
and automake should specifically ensure that that tarball is generic.

Are you saying that there's a bug and that 'make dist' is not
buildable?  Or are you trying to use CVS snapshots on foreign
systems?

I think not having dependency tracking for all the code is quite
unacceptable, unless no-dependencies only turns it off for Makefile.in
dependencies (those don't change so often, so it's not that
inconvienient).

Automake is for developers working with CVS code.  If your regularly
working with vorbis in non gcc unix environments (like Solaris or Digital
UNIX) then it should be easy to turn this stuff off on your local
copies.  If you're just building vorbis for weird platforms, you should be
using 'make dist', since that's what it's for.

I'll see if I can't get this stuff committed this weekend.  Trying to get
some updated beta3 stuff out the door.

jack.

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.