Depending on external libraries

[Keith Packard]

--==_Exmh_1020498076P
Content-Type: text/plain; charset=us-ascii


Around 12 o'clock on Mar 11, Egbert Eich wrote:

> Right. However people here are mentioning the 'distributor's point of
> view' a little bit too often and neglect the 'developer's point of
> view'. I as a developer like a stable environment around me. One where
> I don't have to worry about all kinds of dependecies when I update
> the tree I'm working in to a later version.

That's why jhbuild is so valuable -- it provides mechanisms to pull known 
stable bits into a private build environment so that you needn't deal with 
upstream (or even downstream from your distribution vendor) changes.

> Now I have discovered that the API stability has not been an issue for some
> of the modular lib packages: When upgrading Xft a newer version of
> fontconfig was required.

That was a bug introduced by Owen when he added the FC_HINT_STYLE bits to 
Xft a short time ago.  And, it was fixed with a new Xft release.  The goal 
is to have the APIs stable, problems with that should be treated as bugs 
and fixed.  Note that because things are distributed separately, we were 
able to develop and test a fix.

> Therefore, if we still need to grab the latest pices of everything
> when we want to update one single piece we are better of shipping
> a giant tarball. Then the user deosn't have to worry which pieces
> belong together.

No, if the tree didn't include Xft, fontconfig and FreeType2, there 
wouldn't have been any problem -- whatever versions of those libraries 
included by the distribution would have worked just fine with the 
X.org distribution.  The problem is that the monolithic environment does 
not allow us to ship Xft separately.

I suggested just leaving the versions of these libraries alone in the X.org
tree and not installing them or any other bits maintained outside of the
X.org tree.  Because ABI stability is ensured by .so version numbers, we
wouldn't have had any issues using the system supplied versions of those
libraries with applications compiled against whatever stale stuff was left
lying around the X.org tree.

> Not really. I'm comparing the arguments brought up in favor of the modular
> build with the reality I'm seeing. Other than that I don't understand what
> you are trying to say in the previous paragraph.

You haven't used a modular build yet; the problems here are entirely the 
result of the monolithic tree not allowing the use of an external Xft 
library.

> Did you ever get a system for testing with a OS preinstalled of which you
> didn't know much more that it contains some basic build tools? And did you
> ever have to build and test an X environment on such a system? With the
> monolithic tree this is easy! With the autotooled modular tree this can be
> a PITA!

If you'd given jhbuild a try, you'd see that the modular environment is 
just as easy to build; I build gnome using that tool without any problems.
That tool provides dependency graphs so that you aren't left wondering why 
the configure script fails to work or what packages you need to download.

> In principle these libs (xc/extra) are provided for convenience only -
> nobody seems to realize this.

The problem is that the default build rules for the tree *install* these 
stale libraries into your system, wreaking havoc as they end up overriding 
the distribution provided versions.  If these libraries were provided 
simply to ensure the correct ABI was used to build the X bits and then 
*never installed*, they'd be a lot less damaging.

-keith



--==_Exmh_1020498076P
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Exmh version 2.3.1 11/28/2001

iD8DBQFAUI38Qp8BWwlsTdMRApalAKDJ5wkAm2U3q64mT3a1vBMk5iLnEACgxBtN
BiB6Lqt5i9om30E5Ox8Z8A4=
=J8W4
-----END PGP SIGNATURE-----

--==_Exmh_1020498076P--