modular -> monolithic

Egbert Eich eich at suse.de
Wed Jan 23 02:34:22 PST 2008


Dave Airlie writes:
 > > This whole "partial" remonolithicalisation seems to not address the real
 > > issue, which is a wrong general mindset, and instead this equals
 > > sticking ones head in the sand and hoping that things magically go
 > > away.
 > >
 > > There is no advantage to this as opposed to having a build test system
 > > placing blame all the time. Each choice incurs pain, but one choice has
 > > only pain and no undesired (or desired) sideeffects.
 > 
 > So the problem with tinderbox is it is an out of line solution, the
 > turnaround from tinderbox breakage to user caring
 > is too low, also if tinderbox is broken by one person, subsequent
 > breakages will go un-noticed so its a pain to get useful feedback for
 > us out of it, we had a mostly working tinderbox, it went red, it
 > stayed red nobody kicked anyone.
 > 
 > The thing is we ship a server + drivers with a default config with
 > everything that should build at this point, people check this out and
 > try and build it, if it fails everything to fix is there in front of
 > you on the machine you already have checked it out. I know personally
 > i would never check all the drivers out from git as it is now, and I
 > think a lot of people are the same, it is a royal pita to do this
 > (typing 30 git commands or hacking build.sh). Like Mesa does the same
 > thing with shipping drivers and rarely do drivers stop building or
 > break even for hw nobody cares about like trident...


Dave,

please bear with me, I still don't get this.

We are talking about developers who by doing work on X 
(accidentally) break the API, right?
Those developers have already managed to build the Xserver 
and have takled the biggest hurdle, right?
What keeps anyone from using a simple script like the
one below to buildtest the drivers before they push
a patch that (potentially) breaks the API?
If we put a script like this in a convenient place and 
strongly encourage people to do this, why shouldn't this 
work?
Sure it takes some time to run, but most developers do
lunch at some time, don't they?

My point here is: we are trying to solve a social problem
by demodularization, not a technical one. The technical
problem is easy to solve (30 lines of script code and 
80 lines of driver list).
This is simple at least for the drivers. As Matthias has
pointed out API breakages happen elsewhere, too. Building
this dependecy chain is a lot harder and more time consuming.
Still we don't propose to demodularize the entire X.Org tree.

Cheers,
	Egbert.

#! /bin/sh

DRIVERS="xf86-input-acecad \
         xf86-input-aiptek \
         xf86-input-calcomp \
         xf86-input-citron \
         xf86-input-dmc \
         xf86-input-dynapro \
         xf86-input-elo2300 \
         xf86-input-elographics \
         xf86-input-evdev \
         xf86-input-fpit \
         xf86-input-hyperpen \
         xf86-input-jamstudio \
         xf86-input-joystick \
         xf86-input-keyboard \
         xf86-input-magellan \
         xf86-input-magictouch \
         xf86-input-microtouch \
         xf86-input-mouse \
         xf86-input-mutouchx \
         xf86-input-palmax \
         xf86-input-penmount \
         xf86-input-sample \
         xf86-input-spaceorb \
         xf86-input-summa \
         xf86-input-tek4957 \
         xf86-input-ur98 \
         xf86-input-vmmouse \
         xf86-input-void \
         xf86-video-amd \
         xf86-video-apm \
         xf86-video-ark \
         xf86-video-ast \
         xf86-video-ati \
         xf86-video-chips \
         xf86-video-cirrus \
         xf86-video-cyrix \
         xf86-video-dummy \
         xf86-video-fbdev \
         xf86-video-glide \
         xf86-video-glint \
         xf86-video-i128 \
         xf86-video-i740 \
         xf86-video-impact \
         xf86-video-imstt \
         xf86-video-intel \
         xf86-video-mga \
         xf86-video-neomagic \
         xf86-video-newport \
         xf86-video-nsc \
         xf86-video-nv \
         xf86-video-radeonhd \
         xf86-video-rendition \
         xf86-video-s3 \
         xf86-video-s3virge \
         xf86-video-savage \
         xf86-video-siliconmotion \
         xf86-video-sis \
         xf86-video-sisusb \
         xf86-video-sunbw2 \
         xf86-video-suncg14 \
         xf86-video-suncg3 \
         xf86-video-suncg6 \
         xf86-video-sunffb \
         xf86-video-sunleo \
         xf86-video-suntcx \
         xf86-video-tdfx \
         xf86-video-tga \
         xf86-video-trident \
         xf86-video-tseng \
         xf86-video-v4l \
         xf86-video-vermilion \
         xf86-video-vesa \
         xf86-video-vga \
         xf86-video-via \
         xf86-video-vmware \
         xf86-video-voodoo \
         xf86-video-wsfb \
         xf86-video-xgi \
         xf86-video-xgixp \
         x-input-evdev"

REMOTE=git://anongit.freedesktop.org/git/xorg/driver
SDK= # /path/to/whereever/the/X-tree/lives
CONFIGUREOPTS=
INSTALL=
LIB=lib64 # lib 

if [ "z$SDK" != "z" ]; then
    PKG_CONFIG_PATH=$SDK/$LIB/pkgconfig:$PKG_CONFIG_PATH; export PKG_CONFIG_PATH
    LD_LIBRARY_PATH=$SDK/$LIB:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH
    ACLOCAL_LOCALDIR=$SDK/share/aclocal; export ACLOCAL_LOCALDIR
    ACLOCAL="aclocal -I $ACLOCAL_LOCALDIR"; export ACLOCAL
    PATH="$SDK/bin":$PATH; export PATH;
fi
Cache=`pwd`/.cache;

test "z$Cache" != "z" -a -d $Cache && rm -f $Cache;
test -d driver ||  mkdir driver;
cd driver;

for driver in $DRIVERS; do
    if [ -d $driver/.git ]; then
       	 cd $driver;  git-fetch; git-pull .;
    else
	rm -rf $driver; git-clone $REMOTE/$driver; cd $driver
     fi;
    test -e Makefile && make distclean;
    ./autogen.sh $CONFIGUREOPTS ${SDK:+--prefix=${SDK}} ${Cache:+--cache-file=${Cache}}
    make $INSTALL || echo "driver $driver failed to build";
    cd ..;
done;



More information about the xorg mailing list