Subject: Re: [linux-audio-dev] User Interface
From: Adam Zygmunt (azygmun_AT_bgnet.bgsu.edu)
Date: Sun Jul 29 2001 - 23:45:42 EEST
On Sat, 28 Jul 2001, Paul Davis wrote:
> 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...
> [ ... Adam's problems trying to build ardour ]
>
> >1. sourceforge CVS page never says which module (ardour) to download
> >Seems obvious, but without it ever being mentioned on the page...
>
> I'll fix that. Since there is only 1 module, I tend to assume that
> those conversant with CVS will identify it and download it. But the
> docs should be corrected.
Granted, this is a minor point, and I never had a problem with it.
However, even a user being conversant with CVS doesn't automatically
mean that the developer has chosen sensible names for the modules,
or that there aren't extra modules floating around (and with the
extra libs this program needs, it isn't an unreasonable assumption).
>
> >2. Had to download quasimodo from CVS to get libs, directions
> >buried in README
> >I wouldn't mind the extra download time at all if these were
> >duplicated in the ardour CVS.
>
> Something that you might not fully grasp is that these libraries, with
> the exception of libardour, are *not* part of Ardour. They are used by
> Ardour, and also by 4 public and 2 private applications of my own, as
> well as one other application by another LAD reader. I had to decide
> where the CVS repository for them should be and at that time, Ardour
> did not exist. At one time, Nicola B. hosted them in Italy, but I then
> moved them Sourceforge. Since moving CVS trees on Sourceforge is a
> complete PITA, after Ardour started and became my main focus, I left
> them where they were, and added libardour there as well to be
> "consistent". The only thing you get from "ardour CVS" is the
> application (well, applications, since ksi-ardour is there too).
I realize that the libraries are used for other projects. That is,
after all, the advantage of making them libraries. However, in my
opinion, a little redundancy isn't always a bad thing, especially
since this program is currently your main focus. I've never worked
with Sourceforge, though, so I don't know how much of a PITA
moving/copying stuff is. It's just a thought about how ardour might
be made easier to compile.
>
> >3. script in Quasimodo README for lib compilation needed
> >This is just ugly, IMHO. If you need the script to make the libs,
> >why not put it in the source tree? Making the libs manually wouldn't
> >be too difficult, except that there are some irrelevant directories
> >(for ardour, anyway) in the source tree.
>
> If you only downloaded what you were (not) told to download, there would be
> no irrelevant directories :)
>
Actually, I did just get the quasimodo/libs module as per the README.
CVS still copies the whole quasimodo tree, though, so what I called
"irrelevant" directories are in fact empty, but you still need to
pick through them to find the library sources. The script in the
README does help.
> The script is not there because I don't use it, and because it becomes
> completely irrelevant once you've built them :) More seriously, I was
> never certain that the script was the right approach. Since nobody has
> suggested a better solution to the "how do I build a tree of
> interdependent libraries in a single step" question, I guess I should
> now go ahead and make the script into a real one.
>
This seems to me to be the easiest way to do this.
> >4. script in README for lib compilation very broken - no preexisting
> >configure files in the lib directories, and the script doesn't
> >create them.
>
> The README says:
>
> ----------------------------------------------------------------------
> Compiling from CVS
> ------------------
> ...
>
> 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.
Besides, my whole point here is that the script doesn't work, mostly
since it looks for the non-existent configure files. In addition to
the stuff in the README about autogen.sh and the aclocal directory
link (haven't had to mess with for anything else I've ever compiled),
which I did read and follow, the README says to run the script to
get the libs to compile. So I guess what I'm saying is to either fix
the script or the README.
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. 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,
do the configuring, compiling, and installing individually, then
back out and run configure in the main lib directory.
> >5. install-sh missing from all lib directories
>
> Not if you had run autogen.sh as the READ told you to ...
>
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'.
aclocal: configure.in: 82: macro `AM_PATH_SIGC' not found in library
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. 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. Which set of options is most
appropriate for the most applications and which cause the least
damage by being set a certain way? For example, if most of the apps
use a gui, then I would make --enable-gui the default, and if you
want to compile ksi-ardour, you would use --disable-gui. Not only
that, if --enable-gui is left on, I would imagine everything would
still compile and run fine, which I don't think would be the case
with --disable-gui set by default.
>
> >7. configure quits with syntax errors (e.g. ./configure: line 697:
> >syntax error near unexpected token
> >AM_INIT_AUTOMAKE(libpbd,${LIBPBD_VERSION})')
> >in all lib directories (and ardour, for that matter) early in the
> >process. For whatever reason, all the new configure files appear to
> >be very broken, quitting before they can do any checks except
> >system type.
>
> They are not broken. You've either got a broken auto* installation, or
> you failed to correctly follow one of the steps in the README. No
> "configure" script contains those lines unless it has not been
> processed with autoconf. That is the kind of input you'd expect to see
> from running "./configure.in" which is the precursor to configure.
>
> And about that README. Over on ardour-dev, there have been dozens of
> questions that are answered quite plainly in that document. Many
> people assume that because they've built many things using
> "./configure && make && make install", and they've noticed that Ardour
> and the libraries use this system, that they don't need to read and
> understand the whole document *carefully*. Thats not true here. You
> are building several libraries and installing them. There are lots of
> small details to be paid attention. The same is true during the
> application building process.
>
> --p
>
>
I did read the README *carefully* first (and the INSTALL file as
well, which normally contains the brief, step-by-step compilation
instructions. This INSTALL file currently instructs the user to
./configure;make;make install without any extra information specific
to the program, which you may want to reconcile with the README. But
I digress.) I also didn't try anything foolish like running
./configure.in by itself.
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
download from CVS if you don't believe me. Granted, I expect my
version of gcc is going to be the fatal link if I get any farther
in the configuration. I also realize that most of the stuff above
aren't bugs in the program, they're just one person's view of what
can be annoying and what can be streamlined when having to compile
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.
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. As it is, the autogen.sh files in the
quasimodo lib directories don't seem to work for me at all, as I
haven't gotten a single working configure file from them (or in most
cases in the lib directories, any configure files at all). If I were
to get the libs compiled, I'd probably have much better luck with
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. I'm not an autoconf/automake expert, so I'm
sure there are issues involved that I'm not aware of, and would be
pleased to get any explanations/suggestions/excuses that might be
relevant to why this isn't working. I'm also not sure that putting
pre-made configure scripts in CVS is the best answer, as long as
I've got some way to get working configure files.
Thanks for any suggestions anyone might have.
This archive was generated by hypermail 2b28 : Sun Jul 29 2001 - 23:47:57 EEST