Modularization mailing list and initial strawman proposal

[John McCutchan]

On Fri, Mar 18, 2005 at 09:39:32PM +0100, Roland Mainz wrote:
 >     The cons
> > 
> >      * The autotools are a new build technology, which throws away
> >        existing knowledge of the current imake build system. People that
> >        are not already familiar with the autotools will need to learn a
> >        new build system. That could slow some developers down for a
> >        while.
> 
> Additionally there is the question whether all platforms supported by
> Imake are supported or can be supported by design (OpenVMS and QNX come
> in mind where "autoconf" support can only be described as poor ...).
> What should we do here ? The worst case would be that X.org quickly
> becomes "upstream" for autoconf support on these platforms... =:-)

Why don't developers for these platforms take on this responsability?
and is autoconf really that bad on those systems?

> 
> >      * To address this issue, we need people who understand both imake
> >        and autotools well to write a transition guide for the benefit of
> >        all.
> > 
> >    Some platforms may not "come along" if there are no maintainers.
> >      * This should be treated as an opportunity for us to contact the old
> >        maintainers and see if they are interested joining the community,
> >        or for us to encourage to new maintainers to step forward to
> >        support platforms if the old maintainer is no longer interested or
> >        available.
> 
> What happens if the maintainers of these platforms do not have the
> resources (e.g. time) to do the transition ? The Imake and Imakefiles
> exist since many many years and it is VERY unlikely that we can expect
> to pull over all changes to all platforms within just ... say... three
> months (assuming the X11R7 release should appear in summer 2005). That's
> pretty much impossible.

Those ports go away until someone picks them up. Xorg can't keep
supporting platforms without support from that platforms community.
Take the gcc project for example, they draw a line and say if no one
is willing to support these platforms, they will be removed. This is
something that Xorg needs to do. Xorg progress shouldn't be held hostage
because of some fringe platforms that don't have enough resources to
adapt to a new build strategy.

> 
> The alternative reaction by such maintainers may be to ignore the
> existance of the modular tree and move over to other development
> platforms which are still compatible with their OSes (such as Xfree86)
> ...
> 

Good. Progress can't be held back because some developer's can't handle
change.

> >    With the imake build system, you can build and test in place with the
> >    link directory inside the tree. Building self-contained user
> >    environments are more difficult with autotools.
> >      * jhbuild solves this since it runs a self-contained environment.
> >        Other solutions using chroot, LD_LIBRARY_PATH, etc. are also in
> >        use today with autotools.
> 
> "chroot" is no option. It MUST be possible to build and test the tree
> without having "root" (or similar) priviledges. Otherwise it will be
> impossible to do testing on systems like "compile farms" (such as
> sourceforge's compile farm) as they (usually) NEVER grant "root" access.

jhbuild can be used by non-root users.