Depending on external libraries

[Egbert Eich]

Keith Packard writes:
 > 
 > Around 13 o'clock on Mar 11, Egbert Eich wrote:
 > 
 > > This may be a feasable way, also I find the idea to have a tool that
 > > automagically pulls sources of SW from the internet without me explicitely
 > > saying so a little bit scary.
 > 
 > It depends on how the jhbuild dependencies are structured; you can point
 > the dependencies at known good versions of the software within your
 > control, or even direct the code to use pre-installed versions of the
 > libraries where appropriate.  

OK.

 > 
 > How the default jhbuild rules are constructed is a careful balancing act --
 > gnome (I think) steps over the line a bit in building known versions of
 > Xft, fontconfig and Render instead of relying on the system verisons.  I
 > simply reconfigured my jhbuild script to use the existing versions of those
 > libraries and things worked better (for me).

Using 'known versions' instead of the system installed ones is probably
done pretty much for the same reason that people like libs being included
in a monolithic tree: It keeps the bug noise coming outside bugs down.
 > 
 > > This only happens because the monolithic build has the wrong
 > > 'convenience default', namely to use the libs in extra/ unless
 > > explicitely told not to.
 > 
 > We can change which fontconfig/freetype is used by default, but we can't
 > use external versions of Xft, Xrender, Xcursor (et al) in the monolithic
 > tree.  All we can do is to avoid installing them, but that will lead to 
 > troubles for users who simply download the X bits and build them only to 
 > discover that they won't run without additional software...

In the current monolithic tree you can disable building each of these.
The only problem I see is that this doesn't give one the opportunity
to exchange a single library with a different version separately.

For most people this is an issue as they cannot get bugfix updates
(unless they get the full tree from cvs build it and then do a 
'make install' from somewhere inside the tree.

 > 
 > > If we employ a notion of 'external' and 'internal' dependencies
 > > ('internal' means dependencies which we have control over),
 > > document the external ones well and keep the internal ones simple
 > > jhbuild may be a huge overhead. Most people probably want to get
 > > 'everything' that we provide internally for bootstrapping and just
 > > updated pieces to fix problems. 
 > 
 > jhbuild is just a meta-tool, and not a large one at that.  It is the 
 > "normal" way gnome developers create working environments that are 
 > insulated from changes by other projects.  I suggest we work to make that 
 > a good environment for us as well.
 > 

I guess I don't want to see the dependencies be hidden inside a tool.
If we require a tool to keep track or those we clearly do something 
wrong. It's fine if it makes things easy for people. But the goal
shouldn't be to require a tool it should be to make dependencies simple.

Egbert.