Re: add configure options to control support of misc packages
Mike Frysinger wrote:
this patch adds a bunch of --without-FOO options to configure ... some are very simple (like the sane/xml checks) while some others are slightly more involved
What's the point of crippling Wine like this? Mike
On Saturday 18 February 2006 08:46, Mike McCormack wrote:
Mike Frysinger wrote:
this patch adds a bunch of --without-FOO options to configure ... some are very simple (like the sane/xml checks) while some others are slightly more involved
What's the point of crippling Wine like this?
the default behavior is not changed in any way ... and the point isnt to cripple, but to offer control the point of the patch is to allow people to have finer control over the featureset of wine ... for example, you wish to build on one machine but deploy on others, you cannot be sure what features wine will require if the build env has many more packages than the target host env another example would be what i do with my machine ... i sometimes keep some packages like ldap and jack installed on my box in case i need to test them, but i generally never want anything else using them in case i happen to punt them ... atm i would need to analyze the configure script and export some cache vars in order to prevent ldap/jack support from being enabled, but with the patch all i would need to do is `./configure --without-ldap --without-jack` -mike
Mike Frysinger wrote:
the point of the patch is to allow people to have finer control over the featureset of wine ... for example, you wish to build on one machine but deploy on others, you cannot be sure what features wine will require if the build env has many more packages than the target host env
Building on one machine and running on others works with Wine because we mostly use soft dependencies. For example, the OpenGL libraries are dlopen'ed where they're not strictly necessary (ddraw.dll), but dynamically linked when there's no point to a dll that works without them (opengl32.dll). The core dlls (libwine.so, ntdll.dll and kernel32.dll) have dependency on libc and not much else. It's good for people to build Wine without switching off features so that as much of the build as possible is tested on each machine. Mike
On Saturday 18 February 2006 22:27, Mike McCormack wrote:
It's good for people to build Wine without switching off features so that as much of the build as possible is tested on each machine.
so we're clear, it sounds like you wouldnt accept any patch for this regardless of how it was written ? imo, the guy building the package knows more about the target features than anyone else, and they should have the power to control what is and isnt enabled ... forcing everyone to build everything they can and hoping that people will report bugs seems like a hack -mike
Mike Frysinger wrote:
so we're clear, it sounds like you wouldnt accept any patch for this regardless of how it was written ?
I'm not the one who accepts or rejects patches, so it's not me you have to convince. I'm just reviewing your patch.
imo, the guy building the package knows more about the target features than anyone else, and they should have the power to control what is and isnt enabled ... forcing everyone to build everything they can and hoping that people will report bugs seems like a hack
By adding these options it looks like you're just needlessly complicating Wine's build system, and adding a way to hide problems that probably don't belong to Wine in the first place. Mike
On Sunday 19 February 2006 04:48, Mike McCormack wrote:
Mike Frysinger wrote:
imo, the guy building the package knows more about the target features than anyone else, and they should have the power to control what is and isnt enabled ... forcing everyone to build everything they can and hoping that people will report bugs seems like a hack
By adding these options it looks like you're just needlessly complicating Wine's build system,
adding this stuff usually seems pointless to the people who dont use it :)
and adding a way to hide problems that probably don't belong to Wine in the first place.
i dont understand what you mean here at all ... -mike
Mike Frysinger wrote:
and adding a way to hide problems that probably don't belong to Wine in the first place.
i dont understand what you mean here at all ...
Perhaps give me an example of what doesn't work when you configure Wine the normal way, then we can talk about the solution to specific problems. Mike
On Sunday 19 February 2006 05:06, Mike McCormack wrote:
Mike Frysinger wrote:
and adding a way to hide problems that probably don't belong to Wine in the first place.
i dont understand what you mean here at all ...
Perhaps give me an example of what doesn't work when you configure Wine the normal way, then we can talk about the solution to specific problems.
i'm not saying anything is "broken" in the current source tree, i'm just saying that there is no way for a package builder to disable code from being compiled into wine this may be ok for most users who download and build themselves, but this isnt useful for distro package maintainers -mike
Mike Frysinger wrote:
this may be ok for most users who download and build themselves, but this isnt useful for distro package maintainers
So, what is it that doesn't work in your packages when you configure Wine the normal way? Mike
participants (2)
-
Mike Frysinger -
Mike McCormack