xc/programs considered harmful

[Egbert Eich]

Roland Mainz writes:
 > 
 > AFAIK the plans for modularisation have the label X11R7.x - why the
 > hurry now ?

I applaud Daniel's move to give the modularization effords some additional
momentum.
A good start would be to graudally move parts of the tree over to a modular
environment. This is best done with those parts that can be most easily
be moved. 
Many subdirectories in xc/programs belong to this cathegory: They contain 
sample and test applications which can be build separately and no complicated
backward and forward dependencies exist. 

There are two 'prerequisites' that ought to be addressed before we make
the final move:
1. Establish a policy of 'no user left behind':
   That means it needs to be made sure that we don't break any build 
   environment until we know that our new system works sufficiently 
   well for all of the X.Org customers.
   With the applications that Daniel has nominated this can be easily 
   achieved:
   The modification to their Imake environment to make them build outside
   the tree should be minimal. This would give those users who experience
   problems with autotools on their target platforms a temporary workaround.

2. Make the transition experience a pleasant one:
   Our costomer base is used to build all pieces of X with basically 
   one command.
   While this is something that probably many users don't need or want
   it would be disturbing for them if they now had to download and build
   every single bit individually.
   Furthermore the overhead produced by runnig 'configure' in an 
   autotooled environment is signifficant. 
   Most commercial vendors can parallelize builds of modular 
   pieces in their sophisticated automated build systems and 
   distribute them to many different machines. 
   Individual users on the other hand are facing a time burdeon 
   that is hard to neglect if they want to (re)build their 
   X environment.
   We should have a build system that supports and aids buildling of 
   groups of modules:
   - Allow downloading  groups of modules
   - Support building and installing/updating groups of modules with
     a single command.
   - Allow sharing of configuration information between modules to
     reduce the load of 'configure' runs.
   - Provide documentation to make 'converting' to the modular 
     environment easy anld pleasant for the customer.

   Before we begin moving any directories away from the monolithic
   tree these issues need to be addressed. The modular tree is 
   sufficiently well populated to set up and test this.
     
Egbert.