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

Close

#408 Makefile.in respecting DESTDIR (patches attached)

closed-rejected
nobody
2009-04-27
2009-02-24
Sjors Gielen
No

I noticed Cygwin's Makefile.in does not respect DESTDIR in its install process. I already sent a patch to the Cygwin team. Christopher Faylor of the Cygwin project said I should ask the mingw team if they think the changes are OK. Therefore, I'm reporting this bug here and applying the two patches: one for winsup/mingw and one for winsup/w32api.

Discussion

  • Sjors Gielen
    Sjors Gielen
    2009-02-24

    Patch for winsup/mingw

     
    Attachments
  • Sjors Gielen
    Sjors Gielen
    2009-02-24

    Patch for winsup/w32api

     
    Attachments
  • Earnie Boyd
    Earnie Boyd
    2009-02-24

    • labels: --> MinGW runtime
     
  • Earnie Boyd
    Earnie Boyd
    2009-02-24

    Your patch makes no sense for MinGW.

    <code>
    + $(mkinstalldirs) $(DESTDIR)$(inst_libdir)
    </code>

    Would translate to c:/my/destdirc:/my/inst_libdir which doesn't work. I'm thinking that we don't want this patch. We instruct those who complain of DESTDIR not working to use instead the proper syntax of make prefix=/my/destdir install. The DESTDIR syntax was an add on to autoconf or automake (I forget which) to serve one host OS brand. It should have never become a standard.

     
  • Sjors Gielen
    Sjors Gielen
    2009-02-24

    Thanks for your reply, earnie.
    It has, however, become a standard. Windows is not the only platform mingw is being used on. make prefix=/... install may conflict in some situations with the build instructions. $PREFIX may be embedded in applications - it is legal for an application to depend on the value of PREFIX during build and install.

    What about this solution:
    # WINVOL="C:" on Windows, "" on Unix-like
    WINVOL="$(awk ...)"
    # inst_libdir="/mingw/include", "/usr/include" on Unix-like
    inst_libdir="${PREFIX}/include"
    # DESTDIR="" or "/packaging/install", as an example
    DESTDIR="/packaging/install"

    $(mkinstalldirs) $(WINVOL)$(DESTDIR)$(inst_libdir)
    # results in C:/packaging/install/mingw/include on Windows, and
    # /packaging/install/usr/include on Unix.

    If you accept this solution, I will create a new patch.

     
  • Keith Marshall
    Keith Marshall
    2009-04-27

    > [DESTDIR] has, however, become a standard.

    Nope. It has become an OPTIONAL FEATURE, (therefore, omitting it is *not* a bug), through its inclusion in the GNU Coding Standards. However,

    a) MinGW is not a GNU project, and is not bound by GCS.

    b) MinGW's target platform, for mingwrt-mingw32 and for w32api, (mingw64 is currently an unsanctioned fork, not supported here), is MS-win32, and subject to the strictures of the win32 file system. For that file system, DESTDIR is a broken kludge; we have always rejected, and will continue to reject, patches which attempt to add it.

    > $PREFIX may be embedded in applications

    If it is, then it should be defined as a win32 path.

    > it is legal for an application to depend on the value of PREFIX
    > during build and install.

    Yes, but it does not need to have the same definition at install time, as it does at build time; indeed, the GNU Coding Standards *require* that a prefix change is permitted at install time, *without* changing the state of the build.

    > What about this solution:
    > # WINVOL="C:" on Windows, "" on Unix-like
    > ...
    > If you accept this solution, I will create a new patch.

    Forget it. I agree with Earnie. DESTDIR is a nasty kludge, which we have no desire to support; much less so an even nastier, and completely non-standardised $(WINVOL)$(DESTDIR) kludge.

     
  • Keith Marshall
    Keith Marshall
    2009-04-27

    • status: open --> closed-rejected