Dimitrie O. Paun
dpaun at rogers.com
Sat Jun 19 13:14:35 CDT 2004
On Sat, Jun 19, 2004 at 10:37:54AM -0700, Alexandre Julliard wrote:
> users build without having to fight the autoconf tools. It's for the
> same reason that we have wineinstall. Of course I'm all for improving
> the binary packages, but it doesn't avoid the need to also support
> source builds.
Supporting source builds, and making them easy, is a worthy goal,
and we all understand that. We're not arguing to not support them.
Virtually every package out there works with the standard:
We're arguing that wine should work just like that, without
requiring addition wrapper scripts.
Now, you've pointed out some uses cases (namely newbies that need
to build a most recent version), where a wrapper script is useful
to avoid some potential problems. For this use case, it seems to
us that a prepackaged binary would be double useful:
-- it's easier on the user (let's face it, even if it's only one
command, compiling Wine is not that fun, it used to take me
1h and a lot of HD space). In fact, compiling is not the
problem. The user needs to get the latest CVS tree, install
devel packages, etc. all of which is a lot more complicated
then configure; make. Installing a binary package on the
other hand, is a lot faster, which means that the user will
more likely go through with the operation.
-- it's better for us, because we have a controlled build that
we understand. We can build it so it has all the extensions
enabled, and do it properly, on a known tool chain. This is
an important attribute when dealing with a completely clueless
user, and is in fact important on it's own, apart from the
current wineinstall discussion.
The rest of source users will be able to deal with the
no problem. The above is by no means complicated.
More information about the wine-devel