Modularization mailing list and initial strawman proposal

[Daniel Stone]

On Fri, Mar 25, 2005 at 01:01:35AM +0100, Roland Mainz wrote:
> 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)).

Then all the autotools usages you've looked at are terrible, to be
blunt.  If you write them properly, you offer the user three options:
force enabling (and error out if you don't find it and the user
doesn't specify a particular prefix); force disabling (in which you
don't even check for it, you just disable it flat out); and
autodetect and use if it's there, which is the default.

So this argument makes no sense.

> 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.

*sigh*, no.  I can't be bothered explaining to you why we have to build
FreeType in statically (it has to do with the module loader), but it's
nothing to do with what you said.  Again.

> > 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))).

When did anyone ever talk about requiring Perl?

I get the feeling that you're just saying these things to try to shoot
down autotools, even when you know they have no basis in reality.

I ask you again -- go look at something that uses autotools today,
educate yourself, and then come back.  My patience for rebutting
completely untrue arguments on lists is thinning.

> > > "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 ?

Python, but dude, as I said before -- you do NOT need root OR python to
solve this problem.  You simply install into a prefix of ~/x (or
whatever), and set LD_LIBRARY_PATH and such accordingly.

I know I've said this before.

> > > 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).

If Xinerama v2 actually ever exists, then it can bump the major
soversion of the library -- simple as that.

Look, other projects have already solved all these problems just fine.
X is not a special case here, as you make it out to be.  Libraries are
not impossible to solve; they just require patience and a little bit of
specific knowledge.

As a distributor, I don't know of any pain to do with shared libraries
(which comes after having explicitly enabled shared builds of several
libraries, such as libXau, that are for some reason still static-only
upstream), and I assure you that I am the first one to know of any pain
whatsoever.

> > > 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.

It likely won't.

> > > 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/ ...

Why under drivers/?  If i'm working on the Radeon driver, why do I even
want to think about print drivers, or whatever?

> > 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...

The internal machinations of the loader are irrelevant.  Right now, we
can throw away about 12,500 lines of the 13,300 lines of code (I know
because I've done it), and still have a pretty much functionally
equivalent loader.  Most of its functionality can be mapped to libdl's
with nothing more than basic reordering of arguments; unless you've
spent the entire night doing coke and drinking Hennessy by the bottle,
there is only one way to design a module loader.

I don't know if I'm not communicating well or you simply aren't
bothering to read my mails, but trying to explain this all to you
repeatedly is getting really boring.  Please, go look at some
autotooled projects out there (including, god forbid, xlibs, xserver
and debrix -- xapps as well), and find out for yourself, instead of
having the entire list explain everything to you several times.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.x.org/archives/xorg-modular/attachments/20050325/5c9858fd/attachment-0001.pgp