Depending on external libraries

[Daniel Stone]

--gLcqQrOcczDba7nC
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Mar 11, 2004 at 01:24:16PM +0100, Egbert Eich wrote:
> Keith Packard writes:
>  > Around 17 o'clock on Mar 10, "Kendall Bennett" wrote:
>  > > But for some poor schmo who loves X and just wants to get his feet w=
et
>  > > building the latest code from X.org or whatever, it can be a really =
serious
>  > > problem if the code won't build or even work if that developer has o=
utdated
>  > > libraries.
>  >=20
>  > The correct solution here is a meta build-tool like jhbuild which ensu=
res=20
>  > that the correct dependent versions of each service is built by fetchi=
ng=20
>  > bits directly from upstream during the build process.
>=20
> 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.

I'm sure James would be receptive to a patch that allowed for
confirmation, if the facility doesn't already exist.

>  > We've got that working for the modular build and it's really quite usa=
ble;=20
>  > far better than accidentally installing ancient stale garbage into you=
r=20
>  > system and wondering why your fonts are completely screwed up.
>=20
> This only happens because the monolithic build has the wrong
> 'convenience default', namely to use the libs in extra/ unless
> explicitely told not to.

But why are they there in the first place, then? If you're going to
default to the external ones, then why have extra/ at all? It just makes
things even more confusing than they already are, which is actually
quite an achievement.

>  > If you accept that we plan to move to the modular environment for the=
=20
>  > majority of development, then starting now by eliminating pieces which=
 can=20
>  > easily be built independently will only help make that migration easie=
r=20
>  > and less painful.
>=20
> Well, for this to work painlessly and the way it is intended the
> autotooled build system needs some polishing.

Sure - if you have any suggestions, I'd be happy to hear and/or
implement them (or allay your fears). Apologies if they came up in
another thread.

>  > Whether we should create a jhbuild configuration for the monolithic tr=
ee=20
>  > and its dependencies is another issue; it would be trivial and perhaps=
=20
>  > would help poor schmos...
>=20
> 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.=20

Look at XFree86/XOrg - FreeType, Expat, libxml (I think), zlib, Mesa,
what else? That's a metric crapload of dependencies in and of itself.

--=20
Daniel Stone                                            <daniel@freedesktop=
.org>
freedesktop.org: powering your desktop                http://www.freedeskto=
p.org

--gLcqQrOcczDba7nC
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAUHAIcPClnTztfv0RAm1iAJ0bJRmoQ3nRtSyItx9VK/JTzKruIgCdHiq6
uqs9wcbPLUsAOOHfkTS+Law=
=zm9a
-----END PGP SIGNATURE-----

--gLcqQrOcczDba7nC--