Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#310 add support for `make install DESTDIR` to w32api

closed-rejected
nobody
w32api (251)
2006-11-20
2006-09-17
Mike Frysinger
No

find attached a patch that adds support for running
`make install DESTDIR=/some/temp/install/location/`

Discussion

  • Mike Frysinger
    Mike Frysinger
    2006-09-17

    w32api-3.7-DESTDIR.patch

     
  • Mike Frysinger
    Mike Frysinger
    2006-09-17

    • summary: add support for make install DESTDIR --> add support for make install DESTDIR to w32api
     
  • Keith Marshall
    Keith Marshall
    2006-11-20

    Logged In: YES
    user_id=823908
    Originator: NO

    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.

    Regards,
    Keith.

     
  • Keith Marshall
    Keith Marshall
    2006-11-20

    • status: open --> closed-rejected
     
  • Mike Frysinger
    Mike Frysinger
    2006-11-25

    Logged In: YES
    user_id=114429
    Originator: 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

     
  • Earnie Boyd
    Earnie Boyd
    2006-11-26

    Logged In: YES
    user_id=15438
    Originator: NO

    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.

     
  • Danny Smith
    Danny Smith
    2006-11-26

    Logged In: YES
    user_id=11494
    Originator: NO

    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 ...
    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.

    Danny

     
  • Mike Frysinger
    Mike Frysinger
    2006-11-26

    Logged In: YES
    user_id=114429
    Originator: YES

    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

     
  • Earnie Boyd
    Earnie Boyd
    2006-11-26

    Logged In: YES
    user_id=15438
    Originator: NO

    <quote>
    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
    </quote>

    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.

     
  • Mike Frysinger
    Mike Frysinger
    2006-11-26

    Logged In: YES
    user_id=114429
    Originator: YES

    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
    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

     
  • Keith Marshall
    Keith Marshall
    2006-11-30

    Logged In: YES
    user_id=823908
    Originator: NO

    > 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
    > 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).