Subject: Re: [linux-audio-dev] Ardour : features page
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Fri Oct 27 2000 - 02:08:04 EEST
>For the libraries within your package, you *know* that they're
>there, and what versions they are. The job of dependencies (to
>ensure their built in the right order) is a job for the Makefiles
>only.
Actually, its not true that I know that they are there. This is the
whole point of this change. Because I have 5 or more apps that all use
some or all of the libraries that emerged from Quasimodo, my plan to
date has been to require that the libraries be already installed on
the machine. This has been a total nightmare for most people.
The new plan includes the library source in a tarball distribution,
and so if you get things that way, yes, you'll know they are
there. From CVS, you won't get the libraries. But the configure file
has to handle both situations - in some cases, the libraries will be
present as subdirs, and in some cases they may not be.
>If a target in a Makefile depends on an ardour library, give the
>relative path to where the library should be built as a dependency.
>If you're using libtool to build the libraries, you'll need to
>depend on eg. ../.libs/libfoo.a not ../libs/libfoo.a.
^^^^
oo.la, right ?
>At least, that's how I understand to do this the way that automake
>generated Makefiles operate -- people expect one pass for 'make' and
>one for 'make install'. You could put extra steps in between in the
>toplevel Makefile ('make libs' / 'make install-libs' or something)
>but it's probably not necessary.
No, the install is necessary. This occurs because when running "sanity
tests" during configure for the later libraries, you need to be able
to find
(1) the *-config scripts for the earlier libraries
(2) the earlier libraries themselves
(3) header files associated with the earlier libraries
If these don't end up in a standard place, then PATH and
LD_LIBRARY_PATH and the default include path will fail to locate
things, and configure will fail. If the install is not done, then you
have to set PATH and LD_LIBRARY_PATH to include every library
subdirectory. Yuck. I think :)
So, instead, you just use --prefix to rename the install dir, right ?
Well, thats OK for the subdirs, but its not appropriate at the top
level, since you might actually want to install ardour in a 'system
wide' location as statically linked binary. So you can't use --prefix
at the top level, since the --prefix setting for the subdirs could be
different.
Anyway, to the point: I have more or less solved this problem is a
slightly kludgy way for now. I will slowly migrate all my apps over to
this new scheme. Here's how it works. Lets assume we are talking about
ardour. When you get a tarball release, you'll unpack it and get:
.../ardour
.../ardour/libs/build
.../ardour/libs/src
.../ardour/libs/Makefile
.../ardour/libs/configure (an empty file, more or less)
Makefile is NOT an automake file, its a regular makefile that does
this, conceptually:
foreach lib in pbd gtkmmext midi++ guileconfig soundfile gtkwaveform
do
(cd build/$lib; ../../src/$lib/configure --prefix=../../ && \
make && make install)
done
Once this process is complete, we end up with
.../ardour/{bin,lib,include,share}
populated with the appropriate libraries, headers, *-config scripts
and .m4 files. meanwhile
.../ardour/configure.in
sets LD_LIBRARY_PATH to ./libs:$LD_LIBRARY_PATH, PATH to ./bin:$PATH,
LIBS to "-L./lib $LIBS" and CXXFLAGS to "-I./include $CXXFLAGS".
The net result is that we've done a completely *local* installation of
the libraries etc. under the ardour tree. The build of ardour then
proceeds, using this local installation.
This works well because the VPATH build of the libraries leaves the
original source directories untouched - this is *very* important for
me, since on my machine, these are symbolic links back to the real
CVS-controlled directories for the Quasimodo libs (i don't want
multiple copies of these on my machine).
At the same time, the ardour configure.in file is written so that if
the .../ardour/libs directory does NOT exist, then it will just look
for everything in the normal places dictated by the user's existing
PATH, LD_LIBRARY_PATH and so forth. Thus, if I choose to have my
machine set up with a single system-wide install of the various
libraries, I can simply nuke or rename the .../ardour/libs directory,
and the build will use the system wide stuff instead.
This took me a *long* time to figure out, and I am still not totally
sure its the optimum solution. In particular, we don't get automated
remakes of the libraries if their source changes but we are just
building ardour itself. Suggestions are welcome. The key point is that
you can't just do "make" for each library without a "make install" of
the earlier (depended-upon) ones.
Phew. Something is wrong when the software build process is at least
as tricky as getting EDL's to work :)
--p
This archive was generated by hypermail 2b28 : Fri Oct 27 2000 - 02:33:02 EEST