Re: XFree86 host.def file questions
An unnamed Administration source, Kendall Bennett, wrote: % David Dawes [EMAIL PROTECTED] wrote: % % I guess you must have read something to even know about the existence % of a host.def file. I presume that it was misleading, and so should % be fixed. % % Yes, I have the file that I printed out sitting on my desk! As it turns % out, it appears to be rather outdated and antiquated and I am not sure % exactly where I found it now. % % I think that http://www.xfree86.org/current/BUILD.html is a % reasonable introduction to building XFree86, but suggestions for % improving that document are most welcome. [...] % To solve this problem it would be great if someone added a new section to % the primary XFree86 web site titled something like 'Building XFree86 for % the first time'. It could have a paragraph describing how easy it is to % build XFree86, and then have a link to the BUILD.html file. If that was % available when I started building it again a few months back I think it % would have saved me a lot of time ;-) How about: Special Edition Building XFree86 for the First Time for Compleat Morons in 24 Hours by Example Unleashed. ;-) Kurt -- If you push the extra ice button on the soft drink vending machine, you won't get any ice. If you push the no ice button, you'll get ice, but no cup. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 module compatibility?
Feigning erudition, Kendall Bennett wrote: % Marc Aurele La France [EMAIL PROTECTED] wrote: % % The binaries you provide for your driver should be generated against the % earliest (public) XFree86 version that provides the functionality your % driver depends on. If that means 4.1.0, then that means 4.1.0. This does % not absolve you of the responsibility to ensure the thus-generated binary % works with later core binary versions. % % Allow me to qualify that... % % The binaries you provide for your driver should be generated against the % earliest (public) XFree86 version that provides the functionality your % driver depends on and provides the suport base you are willing to live % % with. If that means 4.1.0, then that means 4.1.0. This does not absolve % % you of the responsibility to ensure the thus-generated binary works with % later core binary versions. % % Right, we plan to test with every version of XFree86 to ensure % compatibility (along with tons of Linux distros; ugh). We would like to % support all versions of XFree86 with our module, and we have no problem % building different modules as necessary to support those versions. What I % am trying to figure out is what the smallest set of module versions I can % build to ensure compatibility. We fight the tons of Linux distros; ugh battle at work. Rather, we quickly decided that we *couldn't* fight that battle and win, so we chose a double handful of distributions that: ° We believe represents significant shares of the installed Linux base ° Complements the strengths of our developers, QA personnel, writers, and in-house Linux users (we're a mixed Linux/Windows shop) Off the top of my head, we chose 2 recent Linux-Mandrake releases, the last 3 Red Hat Linux releases, the most recent SuSE release, and Debian Potato and Woody. I suppose we'd add your favorite distro here if a customer waved enough shekels at us to make the QA effort worthwhile. % It would be nice if I could build a 4.0.3 module and have it work with % 4.0.0-4.0.3, but it sounds like I need to build 4.0.0 to work with all % 4.0.x versions, right? I'd venture to say you just have to test against the N releases you think you can afford or have the resources to support. Kurt -- God may be subtle, but He isn't plain mean. -- Albert Einstein ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 module compatibility?
Feigning erudition, Kendall Bennett wrote: % Hi Guys, % % I know I have asked this before, but I can't seem to find my emails and % the mailing list archive does not seem to be responding. % % What sort of back/forward compatibility is there with the XFree86 driver % modules? From memory last time I tested this, if I compile a 4.2.0 module % it will work with any version of 4.2.x, but it will fail to load on 4.3.x % or 4.1.x. So right now we are thinking of building modules for 4.0.x, % 4.1.x, 4.2.x and 4.3.x and shipping all four modules with our installer % (which will auto choose which one to install). Hmm. I installed 4.3.0 on a crash test dummy at work today. I had the mga_hal.o module from Matrox for 4.2.mumble. Copied it into place, started X, and it seemed to load without incident - no untoward messages in the log files and neither the monitor nor the video card went up in smoke. ;-) More generally, where might I might information on determining binary compatibility, or lack thereof, between module version and XFree releases? Kurt -- With a gentleman I try to be a gentleman and a half, and with a fraud I try to be a fraud and a half. -- Otto von Bismark ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Problems compiling XFree86-4.3.0
Feigning erudition, David Dawes wrote: [evils of make -k] % We could change the default, and let those who like the current behaviour % run 'make WORLDOPTS=-k'. Since the original reasons for this are less % valid now (builds are much faster than they once were), and since it % catches a lot of people out, maybe now is a good time to change the % default. Would anyone object strongly to that? Heck, no. I object much more strongly to make -k and the attendant confusion. % I made a link to /usr/local/bin/cpp in /usr/bin/cpp and everything ran % fine! % % Maybe it'd be better to have cpp set to just 'cpp'? It used to have a % full path because it used to be set to /lib/cpp, which isn't likely to % be in anyone's search path. BTW, the /bin/cpp setting broke my RH 5.2 % test build until I set it to /lib/cpp in host.def. I don't remember % why it was changed from /lib/cpp, unless recent Linux distros don't have % that link anymore. /lib/cpp was removed because the FHS decrees something to the effect that /lib should contain only those libraries necessary to boot the system. /usr/bin has, likewise, been decreed the place to drop most user-visible binaries, such as cpp. Kurt -- Take it easy, we're in a hurry. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
