docu update

Geoff Thorpe geoff at geoffthorpe.net
Sat Jun 19 20:04:43 CDT 2004


On June 19, 2004 03:24 pm, Mike Hearn wrote:
> On Sat, 19 Jun 2004 15:01:31 -0400, Geoff Thorpe wrote:
> > Excellent, I'm glad this was said. One only has to look at the swing
> > away from binary-distributions as a case in point - people *want* to
> > eliminate unknown layers of patches, packaging, and divergence from
> > the "real" thing.
>
> The only popular source only distro is Gentoo, and if you saw the mess
> they made of the Wine ebuilds you would not say this. Binaries don't
> imply forking anyway.

I didn't mean with respect to Wine, I meant in general - and as it 
happens, I use gentoo and haven't even considered trying to invoke their 
wine ebuild :-) Also, I wasn't just referring to Linux - I know a number 
of people through work who've found the simple rigour of FreeBSD/ports a 
breath of fresh air after battling with fungal "enterprise" linux 
distributions and the bloated, untrackable, prepackaged messes they have 
become.

> > It is also the only way to know it tried to
> > adapt itself appropriately to your system.
>
> Why? Wine detects nearly everything at runtime, even very system
> specific things (ie things users basically cannot change) like which
> threading system is in use.

Well that won't necessarily help you if wine was built against 
headers/libs (X, sound, libc, ...) that have incompatibilities with 
what's on the host at run-time. I'm not saying this *is* a problem, but 
if you're using a prepackaged binary, you certainly can't rule it out 
when things go berzerk. If you configure, compile, install, and run all 
on the same system, this sort of thing is less likely - and moreover the 
configure script may actually have a chance to alert you to problems the 
easy way (eg. "I'm going no further until you upgrade that buggy <foo> 
crap"). I'm not saying this is a general rule for anything and everyone, 
far from it. For some people and some tools, prepatched / preconfigured / 
precompiled / prepackaged releases are a god-send. But as Alexandre 
intimated, I think Wine is (for now) one of those tools where it is very 
useful for people to be able to go directly to the source without having 
to learn screeds of obscure build cruft. Anyway, isn't this how people 
get interested in open source programmning anyway? ;-)

> > In this respect, I find the Wine build system extremely
> > impressive. autoconf et al are not the kindest of tools and Wine has
> > no shortage of environmental challenges, yet the source tree seems to
> > be very solid and clean base for people to work with.
>
> Yep, the Wine build system is one of the easiest ones I've encountered,
> probably because it only uses autoconf and not automake or libtool.

It's quite astonishing considering the breadth of crud that has to be 
covered; binary loading (16-bit, 32-bit, etc), sound, video, memory 
management, threading and locking models, signals, IPC, [etc]. And I 
think there's more to that than just avoiding automake/libtool :-)

Cheers,
Geoff
-- 
Geoff Thorpe
geoff at geoffthorpe.net
http://www.geoffthorpe.net/




More information about the wine-devel mailing list