Subject: RE: [linux-audio-dev] packaging
From: Tom Newton (tom.newton_AT_convergys.com)
Date: Fri Jul 20 2001 - 12:55:07 EEST
Hello,
I've been a bit of a lurker on this list for a while. I'm both a developer
(mostly at the moment of closed source billing software..) and a user of
midi software (got a small midi rig at home - Akai sampler, couple of synths
and an ageing Atari ST).
Anyway, a similar packaging issue was brought up on lwn recently with
regards to GNUcash and it's (long) list of dependencies. The article claims
it depends on up to 60 libraries and is at http://lwn.net/2001/0614/. I
didn't look into the truth or otherwise of the claims, but it _is_ an issue
that has come up before. I also believe it will be an issue that will come
up more and more frequently as time goes on because Linux applications are
becoming _much_ more functionally rich, which inevitably means they have
more dependencies.
Abiword (www.abiword.com) is another project that has the same problem
(although right now to a lesser extent). Like you suggested, they approach
it by maintaining (in CVS modules) the sources to the things they depend
upon. They also tack on a bit of makefile magic to make it relatively easy
to do:
% cvs co abiword dependency1 dependency2 etc...
% make
And have the thing build with reasonable ease. The downside (a big one) is
that it does mean (if the libraries are used in other projects) that you
have to maintain two sets of source trees which is horrid. Another thing
that lots of projects do that helps a lot is have an automated build system
that once a day checks out clean source and does a full rebuild and presents
the results on a web page. This will not show you runtime problems, but at
least it gives developers the confidence that they will be able to compile
the thing and get then get their gdb wellies on.
Having said all this, I don't know how well this applies to your situation
since I've never tried to build ardour, so I'll shut up until then. One day
I will try to build Ardour. I reckon I'll need to get rid of my Atari and
get a soundcard for my PC first though ;)
Tom (habitual lurker)
> -----Original Message-----
> From: Paul Davis [mailto:pbd_AT_Op.Net]
> Sent: 20 July 2001 04:00
> To: linux-audio-dev_AT_music.columbia.edu
> Subject: Re: [linux-audio-dev] packaging
>
>
> > Can anyone name for me a widely-used Open Source
> application that
> >(1) is only available from CVS and (2) requires compiliation
> of all of its
> >supporting libraries from scratch?
>
> widely used is not fair. ardour is not widely used. sourceforge
> contains many such projects.
>
> also, can anyone name a open source application that uses:
>
> libguile
> libxml
> libxml++
> libsndfile
> libsigc++
> libltdl
> libgmodule
> libgtkmm
> libgtk
> libgdk
> libasound
> + 5 further libraries from the same author?
>
> or even any comparable list of libraries? just to list those that
> might not be already present on your system ...
>
> > Ardour isn't the first Open Source application to use external
> >libraries. Look at some other Open Source projects. What do they do?
>
> i have spent days, perhaps even weeks looking at this.
>
> i have not been able to find any comparable project.
>
> Reasons:
>
> 1) Ardour uses libraries from quasimodo.org that are used by
> other applications, but are not available as binary packages
> at this time. Thus, it is an application not available
> in binary that depends on libraries that are not available
> in binary.
>
> 2) C++. C++ libraries can be very sensitive to the build
> environment, making prebuilt binaries much more likely
> to be a source of run-time errors than with C.
>
> 3) the additional libraries written by me are not specific
> to this application. life would get somewhat simpler
> if i pretended that libmidi++, libpbd, libgtkmmext
> and so forth were all specific to Ardour. Then I could
> (1) package them into the same source tree and (2) not
> bother to install them before compiling ardour itself.
>
> many other applications that come with libraries do this;
> they include the library source as a subdir, build it,
> then link to it "locally".
>
> but i've tried that, and it was a real pain in the ass
> for me as well as anyone trying to compile (say) Ardour
> *and* SoftWerk.
>
> 4) the dependencies on libraries with rapidly changing APIs.
> ALSA is the principal culprit here, but libxml++ and
> others have caused problems in this area.
>
> and of course, work on Ardour quite frequently prompts
> changes in libaudioengine, libgtkmmext and so forth.
> so the idea that you can "preinstall" these libraries
> and then just "forget about them" isn't really
> possible.
>
> If someone has an actual, real-world, working example of how to do all
> this stuff better, bring it on. The library stuff is a total
> hassle. But I've been hacking Unix systems and open source for 13 or
> 14 years now, and I don't see any good solutions for what is at heart
> caused by a bunch of moving goalposts. It would be great to find one.
>
> --p
>
--NOTICE: The information contained in this electronic mail transmission is intended by Convergys Corporation for the use of the named individual or entity to which it is directed and may contain information that is privileged or otherwise confidential. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email or by telephone (collect), so that the sender's address records can be corrected.
This archive was generated by hypermail 2b28 : Fri Jul 20 2001 - 12:56:25 EEST