xorg/ ModularizationDevelPlan

Modularization Development Plan

Kevin E. Martin

  1. Platform support
  2. Development steps
    1. Module creation
    2. Autotooling the modules
  3. Dependencies
  4. Documents
  5. Success Criteria
  6. Open Questions

Platform support

We need to find out who will be working on modularization so that we can get an idea of the platform coverage. For the 6.8 release, I created a wiki page for the platforms that we wanted to test, and I would like to do the same for modularization. Below is the list of those platforms that people signed up to test from the previous release and the current one:

  • AIX (no arch listed)
  • Cygwin (IA-32)
  • DragonFly/BSD
  • FreeBSD (Alpha, AMD64, IA-32, IA-64)
  • HP-UX (PA-RISC)
  • IRIX (MIPS)
  • Linux (Alpha, AMD64, ARM, IA-32, IA-64, M68k, MIPS, PPC, PPC64, PA-RISC, S/390, Sparc)
  • MacOS (PPC)
  • MacOS/Darwin (IA-32, PPC)
  • NetBSD (IA-32)
  • OpenBSD (AMD64, IA-32)
  • SCO (no arch listed)
  • Solaris (AMD64, IA-32, Sparc)
  • UnixWare (no arch listed)

Other platforms that were listed, but didn't have anyone signed up to test were:

  • LynxOS
  • OS/2

Ideally, we would like to see at least one person and preferably more signed up to work on each of these platforms; however, it is more likely that we will get fairly good coverage on a subset of them. I expect good coverage on Linux, but we need much more than that. So, if you are interested in working on a platform and have the hardware available, please speak up now so that we can get an idea of where we stand.

Development steps

The Architecture Working group has given their approval, and we are now in the process of working out the development plan described here. Once we answer the remaining questions (see below) and agree to the plan outlined here, we can begin work.

There are two parts to this project: dividing the tree into separate modules, and then autotooling those modules. These are described in the next two sections below.

Module creation

Here are the steps that for creating the modules:

  1. Determine where each piece of code from the monolithic tree will go in the modular tree.
  2. Create the top level modules (i.e., app, lib, proto, xserver, driver, font, doc and util) as peers to xc.
  3. Create the directory hierarchy for the modularization within each module based on the breakdown determined in step #1.
  4. Write a script that creates a symlink tree on the developer's local system from a checked out monolithic CVS tree.

Steps #2 and #3 should fall directly out of #1. The directory hierarchy can be filled in as modules are created in the dependency order (see below). Another developer has already started working on #4.

Autotooling the modules

We have a few people that have worked on previous autotooling efforts and many more that have not. Based on feedback from those previous efforts, much of the work will become routine once everyone understands exactly what needs to be done and how to do it. The question is how to fill this knowledge gap so that everyone can be productive initially (i.e., how do we bootstrap ourselves).

My initial thought is that we should learn from the past efforts by having those involved explain the autotooling process that they used. We can then discuss it here on the list, make suggestions and come to consensus on how we want to proceed for our project. By discussing it openly, I think that many more developers will be able to become involved at an earlier stage since they will understand what is involved and how to make it happen. Also, this discussion will form the basis for part of the guide described in the proposal (see documents section below for more info).

What I have in mind here is a simple brain dump of the process used to autotool in the xapps, xlibs, xserver and Debrix projects. I'd also like to see us discuss any common conventions that everyone should follow so that we have a consistent build system and config options name space.

I expect as more people become involved in the modularization effort, the information here will be written and included in the developer's guide.

Dependencies

Note that while there are some dependencies that we need to follow for certain modules to work (lib, xserver, driver), others can be developed independently by using the monolithic tree for bootstrapping (app, font, doc, util). Here's the dependencies:

  • proto: no dependencies
  • lib: depends on proto
  • xserver: depends on proto and lib, but the lib dependency can be bootstrapped from the monolithic tree
  • driver: depends on the xserver module headers
  • app: depends on lib, but can be bootstrapped
  • font: depends on app, which will contain the tools that build fonts, but can be bootstrapped
  • doc: depends on (external?) tools to build docs
  • util: no dependencies?

In order for bootstrapping to work, we need to have the capability to install and use missing pieces from a monolithic build. However, many libraries in the monolithic tree do not have pkg-config metadata files, which will make this difficult. Therefore, we recommend creating the modules in the dependency order listed above.

Documents

In the Modularization Proposal, we committed to create the following documents:

  • Building the X Window System:
    • Required tools (Partially complete)
    • Building and using the new modular tree (TBD)
    • Standardized configuration options (TBD)
    • Guidelines for module components (mostly complete)
    • Converting code from Imake to Autotools (TBD)
  • Component dependencies (included within component -- see developer's guide)
  • Licenses (documented within component in COPYING -- see developer's guide)

Note that in the proposal, this guide was called the "Transition Guide", but it should have been called the a "Developer's Guide" instead since that is a better description of the doc. Using "transition" implies that the guide is only useful during the transition period, which does not reflect the life of this document. This doc is the place where new developers go to find out how to use and develop within the modular tree and will be kept up to date with the latest information.

The initial outline for the developer's guide has been written. During development, we can fill in any new or missing information. To enable it to be easily updated, the developer's guide was placed in the wiki (see link above).

Success Criteria

Ideally, we should be able to build the exact same binaries and install them in the exact same place from either the monolithic and modular trees on the same system, but in reality the compiler options will probably differ and produce slightly different code.

The next best solution would be to run through the same set of tests on both installed trees. The testing procedure used in for the 6.8 release is a good starting point for the set of tests used for the combined 6.9/7.0 release. These test should be updated to use the latest X Test Suite available (see the Test Working Group's wiki page for more info). Here's a link describing the procedure:

In addition, we should make sure that the installed trees look very similar and provide reasons for any discrepancies.

Other success criteria would be the coverage we get on the platforms we support in the initial release. As noted above, Linux will most likely be the best supported, but we need others to make this a successful project. I agree with ajax that we should support at least Linux, Solaris, one of the BSDs, Darwin and Cygwin initially since we have active participation by people working on these platforms. However, my hope is that we will have several others supported as well.

Open Questions

None at this time.