Splitting X11

Hi,

On Sun, 23 Mar 2003 at 13:35:24 -0500, Havoc Pennington wrote:
> Based on my experience, to make it easier for people who already know
> something about X to contribute, the most useful thing would be build
> system cleanup so e.g. build dependencies work (I wasted noticeable
> time on "bugs" where I didn't rebuild something after changing one of
> its deps). And all the exports/ stuff - there has got to be a better
> way to do that. ;-) And the .cf thing is fairly confusing.

I think first step could be to get iMake and other build tools out
of X11 package. I would imagine them to be stable enough for that
by now... :-)


> After that, I'd concur with something a lot of people have mentioned,
> break the distribution up into smaller modules. Server, core libs
> (possibly subdivided), deprecated/stupid libs, clients (possibly
> subdivided), docs, fonts, etc.
> 
> The easiest way to address the build stuff may well be to slowly move
> things out of the current build into their own module, revamping how
> they are built as they move. And of course use autotools, not
> because autotools don't suck (sure they do), but they suck less

Autotools is harder to make cross-compilation friendly because it's
designed for situation where developer doesn't know the environment
where the software is compiled -> When cross-compiling, most autotools
provided 'configure' scripts cross-compile their tests and then (of
course) the tests fail.

There's a way how all Autotools using sofware can be gotten
cross-compilable at least on Linux. It needs target device only for
running the cross-compiled tests but that can be done transparently to
the 'configure' using a bit of /proc/sys/fs/binfmt_misc trickery.


> and in well-known ways. ;-)

A standard SW build system API is important for distributions. Fixing
every software's homegrown build system for cross-compilation is
annoying when it can be done fixing cross-compilation for Autotools.


	- Eero