[Ardour-Dev] build system, libs, cmdline
paul at linuxaudiosystems.com
Mon Jan 26 01:45:37 PST 2009
On Mon, 2009-01-26 at 10:18 +0100, Jérémy Zurcher wrote:
> I'm using ardour with my band to record some ideas while we are on
> rehersal. It's great to have such a software running on linux.
> This week-end I wanted to add cmdline options like:
> -t default_template_file
> -d working_directory
> and add something like a textual description field in the project,
> being able to read it before opening the project would be a plus.
patches to add command line argument to ardour stand a very good chance
of not being accepted. if you want to discuss why, find me on IRC. i'm
not going to do it via email.
> but I've been asking myself questions about the *mm libs :
> - why are they embended in the source tree
because we have had many, many problems during ardour's history caused
by people building ardour with a different version of the C++ compiler,
or in some cases, just different compiler flags, than were used to build
the libraries. gcc/g++ have had an incredibly bad record of keeping the
C++ ABI stable, and the resulting problems are often subtle and hard to
if you don't like it, compile with SYSLIBS=0 as an scons option. and
kiss any support help goodbye.
> - are they modified versions
not in any substantive way.
> - are we tied to a specific version
the one in the source tree.
> - if so, can't we perform version check in the configure process
we're not interested in the version. we're interested in which compiler,
with what flags, was used to build it. this information cannot be
determined. since we cannot determine it, we control the compilation of
all C++ libraries that ardour links against.
> 50 minutes to build libs that are already installed on my box is a great
> loss of time.
50 mins? what kind of machine do you have?
> working within the source tree was a pain for me
> - I update a file, then scons goes trough the configure process,
> walks the uptodate dirs, 1-2 minutes later gcc tells me
> that i have a semantic error, ... I felt asleep in the mean time
> - is there a way to work with scons that I don't know, except
> writting right code only ...
scons has problems, it is true. it is focused on making sure that every
build is reliably repeatable and is optimized for always doing complete
builds. it is not so good at partial builds.
> so what about going to cmake ? If it's ok for you I'll do it with
we do not intend to move to cmake. waf is a much more likely option,
which is a fork of scons that fixes several of its most problematic
More information about the Ardour-Dev