Modularization mailing list and initial strawman proposal

[Roland Mainz]

Kevin E Martin wrote:
> > [snip]
> > >    Autodetection can add dependencies that you didn't intend. For
> > >    example, a developer may have a library on their build system that
> > >    isn't available on the target system.
> > >      * Dependencies will be explicitly listed and documented. Configure
> > >        options will be used to control which dependencies are enabled or
> > >        disabled.
> >
> > How many "configure" options will that be ? 50... 100... 200 ? It may be
> > better to look into a way of a config file a lá xc/config/cf/host.def to
> > avoid having giant command lines which call "configure" (mozilla has a
> > non-standard solution which may be adoptable in this case).
> 
> There are currently hundreds of options in the xc/config/cf/* files.
> Some options will no longer be needed as they will be automatically
> handled by the autotools. 

This is the part which I fear a lot: The autotools pick up dependices to
things they find on the system regardless whether this is usefull or
not. I have VERY bad experiences with this kind of autodetection and
it's one of the things which forced people to have seperate, clean build
machines just to make release builds of Mozilla/Firefox/etc. on some
platforms (or use an chroot'ed environment (which was a pain in the past
as some stuff as the license manager stuff in the Sun Workshop 5 days
was very allergic against chroot'ed environments when you had a
node-specific license)).

Another nightmare are external libraries vs. the copies of them
currently hold in xc/extras/. Debian is a good example here which forced
us to build the freetype2 font code statically into the xprt-xprintorg
package because the shared library version of freetype2 in Debian was
simply not useable. And this means we have to keep a way to do two
things: Allow people to use the library copies in the xc/ tree and maybe
add platform-profiles which define the normal (or better: "common")
config for each platform/distribution.

[snip]
> As you say above, these could also be handled in other ways to automate
> the build process.  We should investigate those and other solutions
> during the initial development cycle.

BTW: Which tools should be allowed as "minimum set" to build the tree ?
IMO the requirements shouldn't be far higher than the current
requirements (otherrwise porting may even be harder) and some of the
ugly things should only be optional (for example I really do not want
anyone to be forced to use GNU make (plain POSIX make should be
suffcient) and perl should be optional, too (and forcing people to use
bash isn't an option either (IMO POSIX sh or ksh93 are the recommended
minimum level))).

> > [snip]
> > >    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.
> 
> Sure, chroot requires superuser privileges on many OSes;
> however, that
> does not invalidate its ability to solve this problem.

Requiring "root"/Admin/superuser privileges to build the tree
invalidates it's ability to solve a problem. Point. Otherwise we will
lock out all those developers who only have normal user accounts and are
not allowed to run stuff as super user.

> Also, jhbuild
> solves this problem very nicely without requiring any root privileges.

What are the exact requirements to use jhbuild ?

[snip]
> > [snip]
> > >    Note that some platforms only have 1 or 2 component revisions for
> > >    their libraries. On these systems, either the second component (y)
> > >    could be bumped, or symbol versioning could be used by vendors who
> > >    package the libraries.
> > >
> > >
> > >
> > >    By default, all libraries are built as shared objects; however, with
> > >    other build options, static, profiled and debug versions can be built.
> >
> > What about libraries which "unstable" APIs which are currently build as
> > "static" versions for that reason (XprintUtils comes in mind from my
> > side) ? And what about helper libraries which are currently used to
> > build the Xserver ?
> 
> It would be nice if libraries were all built as shared objects;

Yes, I know... but I do not want to run into the same disaster as the
libXinerama chaos where Xfree86 started to ship a shared library for a
non-standard version of the extension (which itself now causes much pain
for XineramaV2).

> however,
> modularization and autotooling do not preclude building static versions
> of libraries, if they are needed.

OK.
 
> > >      * As noted above, some DDXs require different built options, which
> > >        implies that not all DDXs will be able to use the same dix, os,
> > >        mi, etc. compile.
> >
> > Why is this a problem for the modular build ? Right now all servers
> > (Xorg, Xnest, Xdmx, Xprt, Xvfb) can be build in one "make World" step.
> > The same should be possible in the "modular" world.
> >
> > >        However, they can and should share the same
> > >        source code. For example, the kdrive server does not support
> > >        XINPUT whereas the Xorg server does, so dix (and other subdirs)
> > >        will need to be built differently for each server. Note that these
> > >        conflicts can be detected at configure time.
> >
> > See above. There should be no such seperation - the "monolithic" Xorg
> > tree didn't need it so why should the modular build system introduce
> > such a pain (currently stub functions and *.a files are used to avoid
> > this and the same could be done for the modular build) ?
> 
> We are being forward looking: There will be DDXs that require different
> build options in the future.

It would be nice if this could be avoided as this will even lead to more
"my-driver-does-not-work-with-my-Xserver"-pain at the user side.

[snip]
> > >      * The basic tree structure in the xserver module will look similar
> > >        to the one used in the monolithic tree under xc/programs/Xserver.
> > >        Notable exceptions include the drivers that will be moved to their
> > >        own module (see below), and support programs that could be moved
> > >        to the app module.
> > >
> > >    The XFree86 drivers module: xfree86-driver
> >
> > Why can't it be named "drivers" (yes, I know, "Xfree86" should be
> > referenced but that can be done in the docs) ? I don't like to have
> > giant-overlong-pathnames and the drivers/ subdir will likely host other
> > kinds of drivers like the kdrive, Sun DDX or the Xprint ones...
> 
> Currently, the plan is to not have a hierarchy under xfree86-driver so
> that each driver can be built independently,

Uhm... my point was more to have all drivers (video, print, input,
multimedia etc.) under drivers/, regardless whether they are loadable or
not or whether they are for kaa or xaa or something different (as one
driver may be build for xaa or kaa depending on build-time switches).
Just all stuff from xc/programs/Xserver/hw/ and
xc/programs/Xserver/Xprint/*/ (=Xprint drivers, not the glue) should
live under drivers/ ...

> and the interfaces for this
> module are the XFree86 XAA and input driver interfaces.  However, we
> could expand this module to include other interfaces and even have a
> driver hierarchy.  What do other people think about this idea?  I don't
> have strong feelings here.

I would prefer a hierarchy for driver types if possible and get rid of
the xfree86-* prefix as future loader designs may or may not be related
to the original Xfree86 design...

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz at nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 7950090
 (;O/ \/ \O;)