Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
find attached a patch that adds support for running
`make install DESTDIR=/some/temp/install/location/`
make install DESTDIR
Logged In: YES
Thank you for your patch; however...
As a concept, I am not really enthusiastic about DESTDIR. I see little benefit from it, in general, but on Win32 in particular, it is entirely broken:
Configure with prefix=C:/mingw
Install with DESTDIR=D:/sandbox/
Result: you fail to install in D:/sandbox/C:/mingw, because the path name is invalid.
The *only* way to reliably achieve an effect similar to DESTDIR, following a correct configuration for Win32, is:
make install prefix=D:/sandbox
and, since this is equally effective on every platform, that's how I prefer to keep it for w32api.
Besides, there are more serious problems with the configure/Makefile set up for w32api than lack of DESTDIR support; they require a complete review and overhaul to resolve them.
Logged In: YES
i'm not building/installing on win32, i'm doing a cross-compiler setup on *nix ... on these systems, DESTDIR works perfectly
prefix also fails to work properly if you run configure with other options ... then you have to override every path you tweaked when doing the install step which can quickly grow to be a huge pita
Logged In: YES
But if you were DESTDIR doesn't work so therefore isn't portable. Since the w32api is native on win32 then having things that don't work on win32 available doesn't make since. You can configure with --prefix=/anything/you/want/it/to/be and then make install prefix=/anywhere/else/you/want/it/to/be without needing to specify DESTDIR. I support Keith in his decision and I don't foresee you changing our minds on the issue.
Logged In: YES
I will file a minority report here.
1) Your patch works for me, building and installing on win32.
2) The use of DESTDIR also works for me building and installing binutils and gcc on win32.
In fact I usually do
configure --prefix=/mingw ...
make DESTDIR=/develop/test install
then do my testing with installed package in /develop/test/mingw
and, when I'm happy, package it for others and install in /mingw for myself
That is the only sane way I can figure to do it with gcc.
Newlib uses DESTDIR.
I think it would be useful to do this for w32api and mingw runtime (and rest of winsup?) as well.
Just my 2 dissents.
like i said, i already know the current recommended procedures and how to use them ... telling me how to use prefix again is pointless
as for having DESTDIR support available doesnt make sense, i dont really understand what you're talking about. building/installing w32api on non-win32 systems makes a ton of sense when you're cross-compiling ... i do all my development in linux and rarely tread into native windows unless needed. "go use wine" also doesnt make sense as my typical development machine happens to be a quad ppc64 g5 machine (4 x 2.5ghz ppc64 is a ton faster than 1 x 2.4ghz amd64).
the point of having DESTDIR is to keep the logic between configuring and installing completely separate ... you specify all your fun funky paths when running ./configure and then you only specify DESTDIR when doing `make install`
as for "DESTDIR being portable", that's a silly argument ... there's no way you can have a drive-absolute setup in configure and then expect to use other values in changing the root
as for "DESTDIR being portable", that's a silly argument ... there's no
way you can have a drive-absolute setup in configure and then expect to
use other values in changing the root
Based on the GNU Coding Standards supplying a prefix value during make install is not allowed to alter the already built package. If it does the package is broken. IMO the DESTDIR solution came about to try to resolve broken packages incorrectly. The correct method to install into a different directory for package release is to use ``make install prefix=/my/release/directory''. I often use ``make install prefix=`pwd`/release'' to install the release into the build directory. I refuse to use the DESTDIR workaround to broken packages.
i dont really see how DESTDIR here is used to work around broken packages ... like i said in the previous comment, it allows you to cleanly break up the "configure" steps from the "install" steps ... as for the original design decisions, there isnt much value in going back and trying to find out why it was originally introduced
in older autotool packages, if you wanted to specify a custom prefix/bindir/configdir/libdir, you would have to pass each one to configure and then when installing, pass each one again to make ... with DESTDIR, you need only to specify your custom values once during configure and then utilize DESTDIR to create a fake root
your correct method looks like:
./configure --prefix=/foo/prefix --bindir=/bar/bin --libdir=/moo/lib
make install prefix=/tmp-install-dir/foo/prefix bindir=/tmp-install-dir/bar/bin libdir=/tmp-install-dir/moo/lib
in other words, your correct method gets to be a pita pretty quickly anytime you try to do anything beyond changing the prefix ... and responding with "dont do that" is pretty lame considering how easy it is to support DESTDIR in the non-intrusive patch i posted
> i'm not building/installing on win32, i'm doing a cross-compiler setup on
> *nix ... on these systems, DESTDIR works perfectly
You and me both, then. Whether DESTDIR works there or not is irrelevant; IMO, it simply isn't needed; certainly, I've never found a need for it.
> prefix also fails to work properly if you run configure with other options
> ... then you have to override every path you tweaked when doing the install
> step which can quickly grow to be a huge pita
So? The defaults set by the GNU Coding Standards are perfectly acceptable, AFAIAC. If you refuse to embrace the normative standards, then you've made the rod for your own back; you will find no sympathy here. If you adhere to the standards, then you do not need DESTDIR.
I've heard all of your arguments in support of this nasty DESTDIR kludge before; I remain completely unconvinced. Danny has suggested that DESTDIR may be useful to him, for building the MinGW standard releases. If he feels sufficiently strongly about it, and can offer a really convincing argument, then I may reconsider, but I will not be swayed by the same tired old arguments that have been offered in the past. In the absence of any more convincing argument, I stand by my decision to reject this patch.
> your correct method looks like:
> ./configure --prefix=/foo/prefix --bindir=/bar/bin --libdir=/moo/lib
> make install prefix=/tmp-install-dir/foo/prefix \
> bindir=/tmp-install-dir/bar/bin libdir=/tmp-install-dir/moo/lib
Your rod; your back! Your bed; you made it; lie in it!
> in other words, your correct method gets to be a pita pretty quickly
> anytime you try to do anything beyond changing the prefix ... and
> responding with "dont do that" is pretty lame considering how easy it is
> to support DESTDIR in the non-intrusive patch i posted
Your patch breaks the requirement that `make install' should fail, if the path specified for `prefix' doesn't pre-exist; in that respect, it certainly is *not* `non-intrusive'. (I'm not actually sure if our existing Makefiles enforce that requirement. I'm reviewing them at present, and if they don't satisfy it, then I will fix them, so that they do).