Re: [PATCH 1/7] Windows: Add workaround for MSYS' path conversion

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sonntag, 21. September 2008, Steffen Prohaska wrote:
> MSYS' automatic path conversion causes problems when passing paths as
> defines ('-D' arguments to the compiler).  MSYS tries to be smart and
> converts absolute paths to native Windows paths, e.g. if MSYS sees
> "/bin" it converts it to "c:/msysgit/bin".  But we want completely
> unmodified paths; e.g. if we set bindir in the Makefile to "/bin", the
> define BINDIR shall expand to "/bin".  Conversion to absolute Windows
> path will takes place later, during runtime.
>
> This commit adds a workaround by replacing "/" with its octal
> representation "\057", effectively hiding the path from MSYS' path
> conversion mechanism.  MSYS does no longer see the absolute path and
> therefore leaves it alone.

This is disgusting, don't you think so, too?

The reason that you need this patch is because you insist that paths in the 
Makefile remain defined as:

bindir = $(prefix)/bin
mandir = $(prefix)/share/man
infodir = $(prefix)/share/info
gitexecdir = $(prefix)/libexec/git-core
etc...

even if RUNTIME_PREFIX is enabled (and you seem to imply that $(prefix) is 
empty, but this is not enforced by any patch).

Wouldn't it be quite natural that enabling RUNTIME_PREFIX implies that the 
above paths are relative, and, therefore, the Makefile must define them as

bindir = bin
mandir = share/man
infodir = share/info
gitexecdir = libexec/git-core
etc...

because the prefix is ... determined at runtime? Now the paths should not be 
mangled anymore.

-- Hannes
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux