[vorbis-dev] ogg123 / Solaris

[Jeff Squyres]

On Sat, 30 Dec 2000, Jack Moffitt wrote:

> > Thanks for bringing this up again. Yes it can be fixed, with an
> > oggenc-style approach: local copies of getopt. I have come up with
> > several ways of sharing the source files between the two programs, but
> > none are completely satisfactory with automake expecting things to be
> > certain ways ... can somebody figure this out (Jack?)
>
> We don't ever modify getopt.  This then could fall into the same
> category as the COPYING file, and we could just have multiple copies.
> Not elegant, but CVS doesn't do symlinks.  And any other automake
> stuff to get around it might be more trouble than its worth.

One less-than-elegant-but-functional trick that we use with MPI when we
need the same .c files to be compiled a second time (with different
#define's -- don't ask, there really is a good reason for it!) is to
manually create sym links from the Makefile itself (since CVS can't do
it).

This is important to us, because we have upwards of 200 .c files that need
to be compiled multiple times (again, don't ask :-).  Having copies of
200+ files not only significantly increases the size of the distribution,
it's damn near impossible to maintain properly.  Hence, sym links are the
natural answer.

Here's a snipit from our Makefile.am in the directory share/pmpi.  It is
sym linking all the .c files from share/mpi to make the libtool library
libpmpi.la.

-----
$(libpmpi_la_SOURCES):
        for file in $(top_srcdir)/share/mpi/*.c; do \
                base="`basename $$file`" ; \
                if test ! -r $$base ; then \
                        ln -s $$file $$base ; \
                fi ; \
        done
-----

Note that libpmpi_la_SOURCES has already been defined in the usual way,
and lists all the same .c files that are in share/mpi.  This has the side
effect that you have to list all the .c/.h files in each Makefile.am,
which is somewhat of a bummer.  However, you could get tricky about it an
have a third file "Makefile.libmpi_sources" that goes something like:

-----
mpi_sources = foo.c bar.c baz.c .....etc.
-----

And simply include that file in both Makefile.am's, and set
libmpi_la_SOURCES and libpmpi_la_SOURCES equal to $(mpi_sources).
automake will do all the substitutions before it creates Makefile.in, so
there's no compatibility issues with different versions of make.  This
would allow you to have a single list of source files (which is probably
nicer).  Indeed, the for loop in the above makefile target could be
modified to traverse that file instead of share/mpi/*.c.

I digress.

Note the use of $(top_srcdir), which allows for VPATH builds, although the
sym links will be created relative to the build directory, not the source
directory.  We figured that this was ok.

Automake: the least of all evils.

...er... I just realized that this won't work in Windoze (right?).  Or do
the project files in VC++/whatever IDE just magically do the Right Things
if you tell it that a given .c file is a source for multiple targets?
Hence, anything in the Makefile.am's won't matter...?

{+} Jeff Squyres
{+} squyres at cse.nd.edu
{+} Perpetual Obsessive Notre Dame Student Craving Utter Madness
{+} "I came to ND for 4 years and ended up staying for a decade"

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