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: configure; make 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 configure; make no problem. The above is by no means complicated.