• Ray Donnelly's avatar
    Revert "Windows port: Work arount MSYS weirdness where it changes --libtool=... · 799a8117
    Ray Donnelly authored
    Revert "Windows port: Work arount MSYS weirdness where it changes --libtool= command line arguments."
    A very old version of MSYS performed normalization during path conversion
    so "/bin/sh ../../libtool" became "c:/opt/msys/1.0/bin/libtool" ("sh .."
    was considered a single folder), it doesn't do this any more; nor does
    Also, the old comment was incorrect. It claimed:
    "This continues to reuse the LIBTOOL variable from automake if it's set,
    but works around some MSYS weirdness: When running g-ir-scanner, MSYS
    changes a command-line argument --libtool="/bin/sh ../../libtool" into
    --libtool=c:/opt/msys/1.0/bin/libtool. So just use sh.exe without path
    because we already "know" where the libtool configure produced is."
    .. yet the actual code was changed to:
    _gir_libtool = $(if $(findstring MINGW,$(shell uname -s)),--libtool="$(top_builddir)/libtool",$(if $(LIBTOOL),--libtool="$(LIBTOOL)"))
    .. so in fact, if $(uname -s) contained "MINGW", then --libtool ignored
    the LIBTOOL variable from automake and used $(top_builddir)/libtool
    instead, at the very least, removing all trace of $(SHELL) from it.
    Now that $(SHELL) has been re-introduced into libtool, it must not
    doubly appear in resolve_windows_libs in ccompiler.py, as otherwise
    sh.exe will try to execute sh.exe and that clearly will not work.
    I've left some MSYS-specific hacks in dumper.py, some of which could
    probaly be removed safely now (execution through a temporary shell
    script), but I've opted to leave it as is for now.
    This reverts commit 33bbdce1.
Makefile.introspection 7.01 KB