[vorbis-dev] build process patches

[Jack Moffitt]

> Since static linking ao doesn't work (as you point out, they are loaded
> with dlopen/dlsym), this should either not be allowed, or the docs should
> tell the user not to do this.
> 
> The latter is probably much easier, since both the --enable-static and
> --disable-shared options are built-in to libtool/automake; I don't know if
> you can disable them.

I thought this was disabled, with the no-static option that I supplied?

> 
> Actually, you can build libao statically as long as you build it
> dynamically as well.  i.e., "./configure --enable-static" such that .a
> *and* .so files are built.  This allows you to build a binary that
> statically links to libao.a, but dynamically links to the pluging .so's at
> runtime.

That sounds kinda icky :)

> I think it would be more accurate to say that the
> ao/ogg/vorbis/vorbis-tools/etc. CVS trees are not meant to be used with
> non-gcc compilers.  There are many projects that use automake in
> development trees that allow the use of non-gcc compilers.  For example,
> automake itself includes many m4 macros to test for characteristics that
> are not specific to gcc.

And how are these projects dealing with no dependency information?  Is
there a way to use an AM_CONDITIONAL to turn on and off dependency
stuff?  That might be a good comprimise in the situation.

> But you make a good point; I was not looking at the xiph.org's CVS build
> process as gcc-only (yes, I'm building at the CVS head with the Solaris
> native compilers, not gcc).

It's gcc only because almost everyone developing code is doing so with
gcc.  It's not done that way for a reason, other than convinience.  Losing
dependency stuff is too far into 'inconvinient' though, unless there's a
whole lot of native cc solaris developers out there to justify it.

> Is it documented anywhere that the CVS tree is meant to be gcc-only
> (and/or Linux-only)?  More specifically, what's the definition of a
> "foreign system"?  This would probably be a good factoid to put on the web
> page that describes anonymous CVS access.

When I said foreign system I was thinking specifically of native cc on
solaris and on digital unix.  Both cases wehre gcc is inferior to the
native compiler (so much so that native compiles should be the
norm).  That is definately a note for documentation.  This mostly stems
from the fact that we tend to do all the code in linux/gcc and then build
on other platforms at the end (even win32) with the native compilers.  It
seems to work well, but doesn't accomodate the native compiler developers
like yourself.

> No -- make dist seems to work fine.  The resulting tarballs can be built
> with native compilers with no problems.

Good, at least I wasn't totally ruining some people's day :)

> 1. Native compilers tend to give better performance than gcc on their own
> platforms.  This not only speeds up development (because your runs are
> just faster), native development/debugging tools can be more powerful than
> gdb (once you start using a memory-checking debugger, you'll never go
> back!).

Agreed.

> 3. Basing a distribution upon gcc-only testing is dangerous.  I'm not
> saying that ogg/vorbis is doing this, but it makes it a bit more annoying
> to test when you have to either edit your Makefile.am's, or:

It's generally been well tested across different platforms.  Remember that
we regularly test on several chips (ppc, intel, sparc) and I do MSVC and
linux/gcc work (along with several others).  So we're getting other native
compilers in the mix.  It is annoying right now for people regularly
working with CVS code on native unix compilers (win32 ones seem fine, as
does BeOS, etc).  

> As I mentioned before, we have developed a portable "make depend" script
> for our software projects that use automake with gcc or native compilers.
> I'd be happy to share it.

Send it to me privately, maybe with a short explanation.  If it's easy,
why not.  The only reason for a build system is convinience, and it has
been convinient for everyone (i think) up until now :)

> It's up to you guys if you want to support this or not.  Given Jack's
> response, you probably don't, so this will be the last time that I
> complain about it.  :-)  But documenting this decision somewhere would be
> good...

We want to support the developers.  We'll lean heavy on the linux/gcc side
though, because that's how 90% of the code is developed.  There's no
reason not to try and reach a good solution though.  I just wasn't going
to commit something like that without a little bit more discussion :)

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.