Subject: Re: [linux-audio-dev] User Interface
From: Paul Davis (pbd_AT_Op.Net)
Date: Sat Jul 28 2001 - 22:47:29 EEST
The ardour-dev list would really be the right place for this, but
since its been raised here ...
[ ... 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.
>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).
>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 :)
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.
>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
----------------------------------------------------------------------
This is standard CVS practice. "configure" *NEVER* lives in CVS -
its generated by the autoconf tools, and generated files do not belong
in CVS. Thats why autogen.sh exists, and this is the standard
technique used by all CVS+autoconf packages I have seen. autogen.sh
also builds many other files needed by the autoconf/automake tools.
>5. install-sh missing from all lib directories
Not if you had run autogen.sh as the READ told you to ...
>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:
--disable-static : turns off the building of static libs,
which cuts compile time in half. but
as a result, you can never build a static
linkage version of any program that
uses the libraries.
--enable-for-ardour: builds the right libraries for ardour.
if you were building softwerk or quasimodo
or my icube interface, this option might
be problematic, or redundant, or something else.
--enable-for-gui: you may not realize this, but ksi-ardour
is a 2nd complete non-GUI interface to libardour.
it was written for blind/vision impaired
users, and is still under active development.
if you were building that version of
ardour, you could save yourself the hassle
of installing the whole GTK+/Gtk-- suite,
plus my libgtkmmext library, which is
quite a considerable savings.
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 ....
>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
This archive was generated by hypermail 2b28 : Sat Jul 28 2001 - 22:45:21 EEST