Re: "Monolithic" vs. "modular" build / was: Re: [Xorg] DocBook SGML/XML manual pages...

Roland Mainz wrote:
> I am not sure whether a "modular build" is something Xorg really wants.
> Other projects tried to split itself into "modules" and FAILED HORRIBLY
> with that (even mozilla.org tries to avoid adding such complex
> dependicies - right now all products (Mozilla/Seamonkey, FireFox,
> ThunderBird, SunBird, etc.) are build from ONE tree, even NSPR (Netscape
> Portable Runtime library), libPNG, libJPEG, etc are part of the tree).
> The release management and syncronisation between the single parts will
> be much more difficult and you have to deal with the interactions
> between the modules. Did anyone actually thought about the consequences
> of introducing a "modular" build ? And a modular build will requires a
> very well working project management (and I think Xorg is currently
> still far away from having a similar good communication tools as
> Mozilla.org had during the Netscape times) ... and if different people
> owning different modules disagree with some decisions all hell will
> break loose.

There has been great debate here, and it's obvious a modular breakup of the
tree can only work if all modules are "owned" by people who can work together.
Presumably all modules will remain under the control of X.Org so that conflicts
can be resolved by the Architecture Group, and failing that, the X.Org Board.

Splitting some things out into separate modules is trivial (most of the client
apps, many of the libraries) - but splitting out the core (server, libX11,
libXext, libfont) is where it gets hard, especially with all the 
cross-dependencies
and having to keep the protocols/headers in sync between the client and server
sides.

> Autotools have the disadvantage of being a PAIN if you have many build
> options. And right now the Xorg tree has a few hundred build options.
> How do you want to deal with that ? Pass everything as arguments to
> "configure" or what ? The Mozilla "configure" script does that... which
> results very often in broken builds or confusion about which "configure"
> options were used. And the people who are qualified to build Mozilla
> dropped significantly... it's now something like "black magic" to get a
> working Mozilla binary without shooting yourself into the feet with the
> wrong "configure" options. All these "issues" thanks to the "superiour"
> autotools stuff... fun... ;-(((((

The biggest advantage I see to autotools over imake is simplifying some
of the configuration logic - it looks like many of the current build problems
in X11R6.7.0 & the CVS head are caused by people not having the version of
freetype installed that the static imake configuration expects for their OS.
With autotools we could detect at build time if the external dependencies are
correctly met - though that could be something as simple as having a configure
script generate xc/config/cf/autoconf-settings.cf for imake.

--
        -Alan Coopersmith-           
alan.coopersmith-xsfywfwIY+M@xxxxxxxxxxxxxxxx
         Sun Microsystems, Inc. - X Window System Engineering