Subject: Re: [linux-audio-dev] User Interface
From: Paul Davis (pbd_AT_Op.Net)
Date: Mon Jul 30 2001 - 16:02:29 EEST
>> The ardour-dev list would really be the right place for this, but
>> since its been raised here ...
>>
>
>Not on the list because I've never gotten the thing close to
>running...
Such conversations dominate the list, most of the time.
>> First, you need to generate the autoconf scripts and Makefiles, since
>> these are not stored in CVS:
>>
>> cd $AD/quasimodo/libs
>> sh autogen.sh
>> ----------------------------------------------------------------------
>
>
>Did this. The problem is that it only creates the configure file for
>the root quasimodo/libs directory, not any of the configure files in
>any of the subdirectories. This particular configure file checks for
>all the other Quasimodo libs first, as well, so the whole procedure
>is a little out of order, to say the least.
autogen.sh does this:
------------------------------------------------------------------------
#!/bin/sh
dirs=.
here=`pwd`
acdir=`aclocal --print-ac-dir`
for subdir in pbd midi++ audioengine guileconfig gtkmmext ardour quasimodo languages soundfile
do
if [ -d $subdir ] ; then
if [ ! -f $acdir/${subdir}.m4 ] ; then
acargs="$acargs -I $here/$subdir"
fi
dirs="$dirs $subdir"
fi
done
if [ $# -gt 0 ] ; then
dirs="."
fi
for d in $dirs
do
cd $d
echo "Building autoconf files for $d ..."
aclocal $ACLOCAL_FLAGS $acargs && autoheader && automake --add-missing --foreign && autoconf
cd $here
done
exit 0
------------------------------------------------------------------------
can you explain to me how that fails to build configure files for
the subdirectories? it specifically iterates over the subdirectories
and does the necessary stuff for each one. the only instance in which
it would fail is if you already had, for example $acdir/midi++.m4
installed - in those cases, it infers that you already libmidi++ built
and installed and doesn't bother to build the autoconf files for it.
that said, your questions have prompted me to notice an error in
autogen.sh that i will fix ASAP. it doesn't run libtoolize in any of
the subdirs, and that could be a genuine problem. i'm not sure why
neither i nor anyone else has noted this - probably because once the
files were generated from the per-subdirectory autogen.sh scripts, it
was never a problem.
>Of course, ideally the user would be able to simply type
>
>sh ./autogen.sh
>configure;make;make install
>
>and have the libraries compile and install. Most other programs seem
>to work fine this way.
********************************************
Ardour *the application* does work this way.
********************************************
But if you can find me an example of a set of *libraries* that are
packaged together and have interdependencies and can be installed like
this, I'd love to see how they do it. I don't know of one, and nobody
in the many discussions about this on ardour-dev has come up with
one. The standard procedure is (1) fetch the most antecedent library
(2) configure && make && make install (3) repeat for each dependent
library, in the correct order.
Because we're still in the quasimodo/libs
>directory, the code for the quasimodo app shouldn't get in the way.
>Currently, the user has to poke through the subdirectories (the
>ones from the frustratingly broken script) to find the libraries,
Would you prefer that I list the 5 CVS commands to get just the
libraries you need, rather than the single one that gets the entire
set? Previously, people complained "why can't I get the libs with one
command?", so I changed the README. You seem to disagree with the
claim there that this single step "will make your life easier".
>do the configuring, compiling, and installing individually, then
>back out and run configure in the main lib directory.
There would be no configure in the main directory at that point.
Anyway, the README says:
----------------------------------------------------------------------
At this point, you could build the libraries one at a time by hand
(though obviously, you'll run into problems if the required
"precursor" libraries are not installed yet). But this script will
take care of all that:
#!/bin/sh
for i in pbd midi++ guileconfig gtkmmext audioengine ardour
do
(cd $i &&
rm -f config.cache &&
./configure --disable-static --enable-for-ardour --enable-for-gui &&
make &&
make install) || exit 1
done
----------------------------------------------------------------------
Are you telling me that you were not able to infer from that how you
would go about building each necessary library by hand?
>Sorry. autogen.sh is broken for me too. In all the lib
>subdirectories, I get an error similar to:
>
>You should add the contents of `/usr/share/aclocal/libtool.m4' to
>`aclocal.m4'.
This message from autoconf is a mistake on their part. I must add a
note to this effect to the README. It is not a real error at all.
Though it may be related to the missing libtoolize that I mentioned
above.
>aclocal: configure.in: 82: macro `AM_PATH_SIGC' not found in library
There are many possible reasons for this, many of which have been
discussed on ardour-dev. I would suggest that you join that list,
where a number of people can help you out with their own experiences.
>and no configure or install-sh file. Running autoconf;automake by
>itself makes a configure file, but it's worthless, and still no
>install-sh file.
>
>
>> >6. configure needs extra args by default (--disable-static
>> >--enable-for-ardour --enable-for-gui)
>> >This is just a personal annoyance, especially with library sources.
>> >Will the libs work with ardour if compiled without these options?
>> >Anyway, sensible defaults are good so the user doesn't have to worry
>> >about this sort of thing.
>>
>> As I said above, these libraries are NOT part of ardour, and it would
>> be quite inappropriate for them to come with options set up for a
>> particular program by default. Let me explain what the options are
>> for:
>>
>> So, which of these should be "a sensible default" for a directory
>> containing libs that are not tied to a particular application? You
>> tell me ....
>
>But you have to come up with defaults by default.
No, I came up with a set of flags needed for ardour.
Not only that,
>you shouldn't have to recompile the libs to use them with different
>apps (or worse yet, having one set of libmidi++ with one set of
>options for one app, another with other options for another app, all
>with the same filenames), so you should be able to find a best set of
>defaults across applications.
The options don't change the suitability of the libraries for
different applications other than the case where some want to be
statically linked. If you read the configure script they are about
*which* libraries to build.
>Quite simply, the CVS code for ardour and quasimodo/libs does not
>come close to compiling on a stock Red Hat 7.1 system. Try a fresh
I doubt that it ever will, though Steve Harris has partially proven me
wrong. RH7.1 has several broken RPMs within it. RH totally f*cked over
the entire C++ development community with RH7.0 and 7.1: very few C++
applications that use any but the most trivial features of the
language will work on these distributions (and not at all on stock
7.0) without the user reinstalling (after compiling from scratch)
several libraries.
Steve has managed to get Ardour built and running on RH7.1, and the
primary tactic was to build almost every library it uses from source.
By contrast, a lot more people have it working under RH6.X and other
distributions that did not go down the disastrous gcc 2.96 route.
These problems exist for many C++ applications, particularly those
using the same feature set of the language as Gtk--.
>from source. However, if I weren't REALLY interested in this program
>(I'm working on building a Delta-1010 based Linux audio system for
>our local University recording/technology studio), I'd have given up
>long ago.
Well, its my part of my intent right now that the people using Ardour
be able to offer suggestions and fixes and alternate ways of doing
things in order to improve exactly the kind of issues you've raised
here. Thats why I'm not really interested in appealing to people who
want to be able to use it "out of the box" at this point.
>That being said, this source won't compile for me, and it's not just
>that the procedure is unusually difficult or I'm a moron that doesn't
>understand the README file.
I didn't wish to suggest that. Sorry if my words were read that way.
>ardour. My version of autoconf is 2.13, and I can't believe it's
>completely broken because it's never given me a problem with any
>other source packages.
Actually, it is broken in an important way. There is a bug to do with
recursive handling of something or other. I reported this earlier last
year, and the fix appeared in 2.14.
Its also worth noting that the current release is 2.52; not all the
intermediate versions were simple feature extensions. I use 2.14.1
currently.
--p
This archive was generated by hypermail 2b28 : Mon Jul 30 2001 - 16:00:30 EEST