Re: [Msys2-users] Problem with Unix-style paths being translated to Windows-style

[Paul M. <p.f...@gm...>]

On 15 April 2015 at 15:17, David Macek <dav...@gm...> wrote:
> On 15. 4. 2015 15:16, Paul Moore wrote:
>> I'm having a problem building gawk for mingw64. I'm not using
>> configure, as that assumes a POSIX-like environment such as msys or
>> cygwin). Rather, gawk has a customised build process for PC/mingw. You
>> copy some customised files from the pc subdirectory, including a
>> makefile and a config.h, and then run make.
>
> Why not use configure? makepkg-mingw depends on the POSIX part of MSYS2 anyway. There are no expectations that mingw packages can be built just using mingw tools and the specialized makefiles are often problematic as they're inflexible and sometimes even call Windows shell commands, which is undesirable in MSYS2.

It's possible that I could make that work. But when I tried, I got a
lot of build errors, as far as I can see caused by an assumption in
the source that if you're building with configure, you'll be running
the built executable on a POSIX-based system (which isn't true when
building mingw executables with msys). Also, there was a PC-based
build process provided, so it seemed reasonable to use it (it *is*
much simpler to do that if you just manually edit stuff to match your
preferred install location, etc - it's only when you try to make the
build configurable that it becomes messy :-()

I may have another go at getting configure to work. Given how messy
the custom PC build is becoming, it may be less work in the long run.

>> What I'm trying to do is to modify this build process to allow it to
>> be packaged. So I've made the code get its paths relative to the exe
>> (using the msys2 pathtools library), and modified how the default path
>> is set. I'm setting a prefix=/mingw64 argument to make, which I'm then
>> using to set defines -DBINDIR="\"$(prefix)/bin\"" and a default path,
>> in the CFLAGS. Then I make the default path relative (using BINDIR as
>> the root). It's not the most straightforward process, but it's
>> relatively clean.
>>
>> The problem is that it appears that by the time the BINDIR and DEFPATH
>> macros are seen in the source code, their values are Windows-style
>> paths (C:\Work\Scratch\msys2\...), which completely breaks the path
>> correction code which expects Unix-style paths.
>
> Only problem I see are the slashes (`get_executable_path` returns Windows paths with forward slashes). If you're able to tweak the build process in the right place, you can use `cygpath -m` to convert the path. If not, use `sanitise_path` at runtime.

I'm just not sure what changed the paths on me. If I do

CFLAGS="-DBINDIR="\"/mingw64/bin\"" (plus other stuff)

in the makefile, I find that in my C code, "char *path = BINDIR"
results in path having a value of "C:\Work\Scratch\msys2\mingw64\bin".
The C preprocessor should simply do text substitution - so *something*
changed the arguments supplied to cpp, or to gcc, or something, to
change that value. I'm unsure what that was, or why it did that. And
more importantly I don't know how to tell it *not* to do that.

The big problem is that because I'm confused about what value ends up
in my variable, I don't know how to write the code to process it...

>> I'm guessing that this is caused by some part of the msys
>> infrastructure "helpfully" converting paths. But I've no idea where,
>> nor how to stop it doing so. Can anyone help?
>>
>> I could hard-code the values in the source, but if I do that, I can't
>> make a viable PKGBUILD spec, as that requires the ability to specify
>> the install directory at build time. (Hmm, actually I could - the
>> relocation code doesn't care if the arguments to
>> get_relocated_path_list are *accurate*, just that they are consistent.
>> But it's horribly ugly, and I'd still like to know what's going on
>> with the path translation code anyway).
>
> I'm not sure I understand what you mean, but I'd say that baking in paths like "C:\msys64\mingw64\share\gawk" and "C:\msys64\mingw64\bin" is okay, as long as they're never actually accessed and the runtime-computed path is correct.

I'd actually be baking in Unix-format paths rather than Windows-format
ones as you show, but yes the runtime-computed path is correct, so I
guess it doesn't matter in practice. It does leave me with a sour
taste, though... (The fact that the hard coded default library could
be "/this/is/a/broken/default/share/awk" as long as I supply a bindir
of "/this/is/a/broken/default/bin" just feels meh).

Paul