Depending on external libraries

[Daniel Stone]

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

On Sun, Mar 14, 2004 at 10:07:35AM +0100, Egbert Eich wrote:
> Daniel Stone writes:
>  > You said 'you guys that are pro-modular-tree', and tried to stuff
>  > arguments into our mouth. BTW, running 'jhbuild install xorg', or
>  > whatever the single command is, is far easier than hunting down the
>  > X.Org tarball, untarring it, working out how the hell you configure
>  > host.def/et al, then making it.
>=20
> Oh, thank you for bringing this up. I would like to take this right back=
=20
> to the autotool advocates.
> Imake at least offers a nice uniform way of configuration of the
> entire X suite. In the modular environment every piece will have its=20
> own configure options (which you cannot put into a file but have to
> specify on the command line!) - largely depending on the maintainers=20
> preference.

Sure. Unix provides us with scripting ability for a reason. Put it into
a file - just one that gets run by zsh/Python/whatever, rather than cpp.

> In the past I found the configuration of autotooled projects rather
> cumbersome: on quite a few the options changed from version to version.

Sure, but that's a problem of process, not a failure of the entire
system. All that means is that a couple of people need to get their act
together and standardise options.

I've found Imake to be pretty inconsistent in some respects, BTW -
sometimes it's BuildFoo NO, sometimes it's HasFoo YES, sometimes you
need to specify a path, sometimes it's any combination of the 3.

> What is more: as I developer I have been able to more freely among the
> different pieces of X without being plagued by the 'boundaries' of the
> build system: I had a uniform set of build rules. Now every piece will
> be created according to the author's preferences. Some will use automake,
> others will create their Makefile.ins directly.

Sure. Not everyone needs automake.

> A lot of packages will have the same problem solved in many different
> ways. The centralized structure of Imake provided a uniform way of doing
> things. If you discovered the way was broken you fixed it in one single
> place.

Which problems do you refer to? Most Makefile.am's are this simple:
lib_LTLIBRARIES =3D foo.la
foo_la_SOURCES =3D foo.cpp
bin_PROGRAMS =3D bar
bin_SOURCES =3D bar.cpp
bin_LIBADD =3D foo.la

>  > > Yes, it requires the builder to made a simple edit to their site.def=
=20
>  > > file. In the grand scheme of things, not very complicated at all.
>  >=20
>  > You need to make the right ones, and working out what those right ones
>  > are is often difficult.
>=20
> I think this is a myth. xf86site.def contained a list with a detailed
> discription of the most importand ones. People who felt that options=20
> were missing could have spoken up.

I honestly didn't feel it was worth it. My personal belief is that the
XFree86 Imake-based build system is so crufty and disgusting it's
completely unworkable. I've spent too much time chasing up its random
nuances to like it.

The modular system does have this in its favour: with smaller modules,
it's impossible to get a build system as unusable as XFree86's.

This is me speaking as a distributor, as a developer, as an end user, as
someone who's watched helpless, hopeless, end users try to build it to
no avail many a time.

>  > > There is no jhbuild on the boxes I cited. Telling me I've got to go =
get=20
>  > > it before I can build is a lot more complicated than it needs to be.
>  >=20
>  > Yes, but for the benefits jhbuild with a modular tree provides, it's I=
MO
>  > worth it. jhbuild is also far more flexible, and provies you with a way
>  > to build many, many, many components (such as, oh, GNOME), if you want
>  > to. It's a common build tool, not an X-specific one.
>=20
> Looks to me this depends very much on the environemnt somebody is
> working in. On Linux people are used to huge chains of tools which
> themselves require more meta tools.

Not always - look at the kernel, et al.

> I myself find it rather cumbersome to track down problems to the
> part of the tool chain that's responsible - especially in an environment
> that attempts to do everything automagically.

I found this with Imake - I guess it's what you're used to. I think it's
fair to say there are far more people used to autotools than there are
imake, no?

> I feel I'm there to do development not to learn and debug huge build
> environments and make them suite my purposes. And I don't want to be
> hampered by those problems an blocked from doing my work until I've
> convinced some toolchain guru to look into my problem.

Yeah, and this is what frustrated the crap out of me with imake. :) I'm
used to autotools, you're used to imake. Whenever there's a change,
people are going to have to adapt, and imake is a bastard of a thing to
adapt to. I had the same problems you did when I moved over from KDE
(autotools) to XFree86.

> To me it looks like we are abandoning the KISS principle here.

KISS is nice, sure, but to me it's losing sight of the ultimate goal a
little. KISS was put in place as a mechanism to ensure software was good
and didn't hobble you, right? But what happens when your software
becomes so simple it's hobbling you? Haven't you blindly followed a
means to an end so far that you're no longer going towards the end at
all?

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

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

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

iD8DBQFAVDuncPClnTztfv0RAnKcAKCCv/E1STwcMLL7+yb78Xxp6/5/3ACfY6T3
oP8tU/Qa4q6jZejpsKoSxJQ=
=awbF
-----END PGP SIGNATURE-----

--P4TvzqIqx9lYUNHl--