Bernhard Rosenkraenzer bero@redhat.de writes:
wine currently doesn't support the DESTDIR flag commonly used by packagers. The patch I've attached fixes this.
Could you explain this a bit more? Why can't you use the existing $prefix to do the same thing?
On Thu, 31 Jan 2002 13:09:28 -0800, Alexandre Julliard wrote:
Bernhard Rosenkraenzer bero@redhat.de writes:
wine currently doesn't support the DESTDIR flag commonly used by packagers. The patch I've attached fixes this.
Could you explain this a bit more? Why can't you use the existing $prefix to do the same thing?
$prefix changes the code, e.g. winelauncher sets it's directories based on $prefix. DESTDIR puts the files somewhere esle but writes the code like it was going in $prefix.
So you could have $prefix=/usr and DESTDIR=/tmp/winepackage
On Thu, Jan 31, 2002 at 01:09:28PM -0800, Alexandre Julliard wrote:
wine currently doesn't support the DESTDIR flag commonly used by packagers. The patch I've attached fixes this.
Could you explain this a bit more? Why can't you use the existing $prefix to do the same thing?
When creating a spec file for rpms, you basically prepare the source (unpack, apply patches), then run configure, make and --->make install Because the result is intended not to be run but to be packaged, you don't install into e.g. /usr/local directly, but into something like /home/myaccount/rpms/tmp/usr/local. Later, when you *install* the package, you want the binaries to be installed into /usr/local and all paths compiled into the binaries to point to /usr/local/... too. So changing prefix is not the way to go. DESTDIR allows to do the install via "DESTDIR=/home/myaccount/rpms/tmp make install" instead of doing all the steps from "make install" manually.
Ciao Jörg
-- Joerg Mayer jmayer@loplof.de I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.
Joerg Mayer jmayer@loplof.de writes:
So changing prefix is not the way to go. DESTDIR allows to do the install via "DESTDIR=/home/myaccount/rpms/tmp make install" instead of doing all the steps from "make install" manually.
But "make install prefix=/home/myaccount/rpms/tmp" should do exactly the same thing, unless I missed something. You can run make with one prefix and make install with another one, that's a feature.
On Thu, Jan 31, 2002 at 02:33:53PM -0800, Alexandre Julliard wrote:
But "make install prefix=/home/myaccount/rpms/tmp" should do exactly the same thing, unless I missed something. You can run make with one prefix and make install with another one, that's a feature.
I didn't know about this feature, but it works fine :) Thanks!
Ciao Jörg
-- Joerg Mayer jmayer@loplof.de I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.
On 2002.01.31 17:52 Joerg Mayer wrote:
On Thu, Jan 31, 2002 at 02:33:53PM -0800, Alexandre Julliard wrote:
But "make install prefix=/home/myaccount/rpms/tmp" should do exactly the same thing, unless I missed something. You can run make with one prefix and make install with another one, that's a feature.
I didn't know about this feature, but it works fine :) Thanks!
Ciao Jörg
You're still missing out on even more features though.
The newer versions of RPM have configure and make install macros.
When you use the configure macro it calls ./configure with a bunch of predefined parameters like the prefix and the etc directory and the manpages and info directories and so on.
You then run make (usually wouldn't need any parameters.. although in wine's case don't forget to make depend before a make).
Then when that is all said and done you use the makeinstall macro which runs make install with those parameters from the configure macro set with the RPM BuildRoot before them all.
I believe Wine's makefiles should already be well behaved enough to handle that.
Only issue I can remember is that a few weeks ago I grabbed wine out of CVS and compiled it on my work box and I could have sworn that when I did a make install that it compiled wineconsole again during that. I think that only happened during the first build of the tree (which is always going to be the case for an RPM). So you might want to look into that. Fortunately, this was not for an RPM, simply build as myself and install as myself into the /opt/wine-cvs directory which I own.
-Dave