Guu... compiling X is just... x.x. First you cvs update. Then you have to compile a program in X manually, lndir. Then you use lndir to make a shadow directory of the whole source tree. Then you happily click compile and... it... fails.
Now, a little known fact of CVS is that if merging the differences between one file and its newer version fails, CVS will not leave the older file in its place. CVS will not replace it with the newer file. Instead CVS will forcibly merge both files like <<<<<<< new stuff ======= old stuff >>>>>>>1.4.34.2 this. You can imagine when your Makefile encounters a <<<<<<< it gets rather confused, say nothing of your shell script or C source code.
So you, the consumer, must manually edit every CVS file that has these revisions pasted into it, choosing whether to keep the old, or replace with the new. Not bad in concept, but when there are hundreds of files like this there's a problem. Or in the case of X when there are tens of thousands of files, and even though there are only a few like this, I haven't the slightest clue how to find them. (find | xargs grep takes too long.)
Good news is the old version is saved as .#filename.1.34.4.25 or something. So in theory you can just copy the .#filename.1.34.4.5 to filename. Unfortunately the numbers at the rear are the version of the file not the project as a whole. CVS is stupid because it revises each file independantly, ignoring the fact that it's part of a larger picture. So there's no way to predict, script-wise, what those numbers for a particular file are going to be. So if you have .#feep.1.1.5.4, should that be copied to feep, and is version 1.1.5.4? Should it be copied to feep.1, with version 1.5.4? feep.1.1, version 5.4? I did end up writing a script that can grok this problem. (if !exists feep.1.1.5.4, if !exists feep.1.1.5, if !exists feep.1.1 etc...)
Okay, so all the CVS garbage aside, then you read BUILD, copy xorgsite.def to host.def, and make World. What I love about their helpful suggestion to start with make World is that make World does a full clean of the entire source directory of object files first. And since you just downloaded the source there are no object files to clean. Making sure there are no object files to clean takes approximately 10 minutes, when they could have just overwritten object files with older modification times and not cleaned at all.
After that it generates all the Makefiles. Okay, that makes sense, gotta have custom builds for custom systems. But it is dumb about that too. Every instance of make World (or make Makefiles) will make every single Makefile, even ones that just got made without any modifications to the IMakefile from which they are generated. This is, in theory, so that when new revisions result in a changed Makefile, but leave the IMakefile the same, you won't be stuck with an old Makefile that isn't aware of the new dependencies. I can't imagine how this would happen, but theory is better than fact right? So 10 or 20 minutes later all the Makefiles are...made. The actual compiling starts.
Chances are, it fails. The reason it fails is that gcc complains that it can't find a header file: a header file that is part of the X.org source tree you're working with here. That's like a crime worthy of caning in programming circles: the X developers can't even keep track of their own header files.
So then you dig through the Documentation try make includes. Then make deps. (X relies on make includes symlinking includes in spidery redundancy all around the source tree.) Then you try make World again. Ooops, there went the last 3 hours! Full clean of the entire source directory, deleting all the lovely object files you just compiled, and then every single Makefile you made gets made again.
If you had read the Documentation (there's one line in BUILD that mentions this), then you'd know that to start up the build process again you should use make, not make World. They don't mention that make World will destroy everything you have done so far, but I suppose that's not worthy of putting in indented, underlined bold blinking text with several requests of "Are you sure you're sure?"
So after make World fails (again), you try make include, make deps, and then make. It still fails. Actually my problem was that the CVS version of the savage driver, which is for my video card, doesn't work. It's broken. There is a broken driver in X.org. How they expect to compile with broken software I'm not entirely sure...
So you go to the Internet. Google is our friend. Looking up of all things "savage BCI_ENABLE," you find a bunch of mysterious patches here and there. Apparantly other people with this problem have attempted to fix it before. If you really look carefully you'll find someone mention that X.org themselves is trying to fix it, behind the scenes. There is a -j flag or two you can use to enable the savage driver again, and joy of joys enable it with DRI! (DRI is another word for damn bloody fast in X.)
Of course when you do the cvs -j it somehow manages to produce conflicts. So you do the snarky thing and delete all the files in the programs/Xserver/hw/xfree86/drivers/savage/ directory and try the cvs merge again. Guess what, even with no files to conflict with, CVS still produces conflicts! Remember <<<<<<<? So that was what motivated me in the end to write a script that will, to be blunt, destroy the CVS revision files and replace them with the .#... files. The older versions, even though there were no older versions to begin with. c.c
So. DRI enabled savage compiled. An hour of kernel hacking to figure out where to enable DRI in the kernel. (It's next to multi-device RAID.) And then another hour or so of searching, trying to figure out where the stinking savage kernel DRI module code is. (It's not in the kernel, it's in X.org's source: extras/drm/linux) Apparantly DRM is utterly essential to DRI, even though their wacky Documentation wiki goes on for pages and pages of how essential DRM is to DRI, but doesn't actually say what DRM is. They do, but they say it using buzzwords that just don't cut it. Anyways...
So DRI is enabled in X. lspci tells me my AGP chipset is VIA, so via_agp and agpart modules are both loaded. The savage kernel module is loaded. X is compiled, and installed. I do startx. And..........
It works! It works beautifully I might add. X.org might not be able to grasp simple concepts such as proper dependencies, cohesive coding, or not allowing broken software into their tree, but they sure know how to make a great program. And with DRI, I can play movies again! Thank you S3, for releasing the savage class hardware specs so Linux gurus could make a DRI driver!
To Windows users, X is the program that displays graphics on the screen and makes windows. Also known as a GUI, or Graphical User Interface. X was once sometimes called XWindows. Microsoft happily stomped all over that calling their GUI Windows and confusing people. (Yes, X came before Windows.) And then Microsoft sued Lindows.com for sounding too much like Windows. Microsoft won. Why are you trusting this company again?
Comment
Index
Previous
(Discretely Fired)
Next
(My Socioacademic Life, Tabulated by Years.)