[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xfree86-forum
Subject:    Re: [forum] XFree86 modularization
From:       Egbert Eich <eich () XFree86 ! Org>
Date:       2003-06-02 14:27:35
[Download RAW message or body]

David Dawes writes:
 > On Fri, May 09, 2003 at 07:51:00AM -0700, Jim.Gettys@hp.com wrote:
 > >David,
 > >
 > >My point wasn't that a version of Freetype shouldn't be included in the
 > >distribution, but that building and installing it by default on platforms
 > >where it is inappropriate causes trouble.  Having a version available known
 > 
 > That's a build-time configuration issue.  I've been advocating on
 > and off for a while now an "auto-generated platform.cf" enhancement
 > to the existing build system, which if done correctly would deal
 > with the vast majority of issues like this (and others) without
 > the level of work that would be required to replace the entire
 > build/config system.
 > 

This idea is not exactly new. Years ago RMS proposed a similar idea.
His idea was to use autoconf and some scripts around it to generate 
a platform dependent config file for imake.
I even discussed this briefly with him. After he saw some interest on
the side of XFree86 he was even willing to sponsor the implementation
and find somebody to do the work. Unfortunately this never happened. 

[Related but slightly off topic]
Recently I've heared voices talking about replacing the imake
based config system of XFree86 and the build system with 
autoconf/automake. One argument in favor of this was the better 
modularizability of autoconf-configured systems while imake either 
requires a system global config directory or a completely
self-contained build. While this works well for X-applications 
neither one is suitable for the independend development/update 
of a 'module' like a shared library.
As David I would expect that a system to generate a platform.cf
would be by far easier to implement than doing a full transition
to another config/build system. Furthermore this step would have to
be carefully evaluated. 
Currently we control our own configuration environment. Fixes can
be included quite easily as we can add them to our source tree. 
If we discover a problem in an external config system - especially
on a less commonly used and tested platform - there may be a
considerable delay until the problem is fixed in the next release.

Egbert.

[prev in list] [next in list] [prev in thread] [next in thread]