Relocating paths from .pc files on Windows #72

New Issue

ariadne · 2014-08-09T06:02:55Z

Alexpux commented

2014-08-09 06:02:55 +00:00

(Migrated from github.com)

Hi!

I'm developer of MSYS2 project. Builded software have always UNIX paths in .pc files. Under MSYS in most cases it's ok because it convert paths where spawn native Win32 process but sometimes we have problems. For example using cmake or building python modules.
In this case cmake/python call pkgconf and get UNIX paths. As cmake and python is native win32 programs converting paths not happen when, for example, python distutils spawn GCC.
To resolve this issue I try to expand paths reading from .pc file in pkgconf itself:
https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-pkgconf/0002-relocate.patch

It work in general ok but only for packages without dependencies:
c:\msys64\mingw64\bin>pkg-config --cflags-only-I harfbuzz
-Ic:/msys64/mingw64/include/harfbuzz

But for packages with dependencies not all paths are relocated:
c:\msys64\mingw64\bin>pkg-config --cflags-only-I gtk+-3.0
-Ic:/msys64/mingw64/include/gtk-3.0 -Ic:/msys64/mingw64/include/harfbuzz -Ic:/msys64/mingw64/include/pango-1.0 -Ic:/msys64/mingw64/include/cairo -Ic:/msys64/mingw64/include/pixman-1 -I/mingw64/include/libpng16 -I/mingw64/include/harfbuzz -Ic:/msys64/mingw64/include -I/mingw64/include/freetype2 -Ic:/msys64/mingw64/include/gdk-pixbuf-2.0 -Ic:/msys64/mingw64/include/libpng16 -IC:/msys64/mingw64/include/atk-1.0 -Ic:/msys64/mingw64/include/glib-2.0 -Ic:/msys64/mingw64/lib/glib-2.0/include

Can any one help with this?

Regards,
Alexey.

Hi! I'm developer of MSYS2 project. Builded software have always UNIX paths in .pc files. Under MSYS in most cases it's ok because it convert paths where spawn native Win32 process but sometimes we have problems. For example using cmake or building python modules. In this case cmake/python call pkgconf and get UNIX paths. As cmake and python is native win32 programs converting paths not happen when, for example, python distutils spawn GCC. To resolve this issue I try to expand paths reading from .pc file in pkgconf itself: https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-pkgconf/0002-relocate.patch It work in general ok but only for packages without dependencies: c:\msys64\mingw64\bin>pkg-config --cflags-only-I harfbuzz -Ic:/msys64/mingw64/include/harfbuzz But for packages with dependencies not all paths are relocated: c:\msys64\mingw64\bin>pkg-config --cflags-only-I gtk+-3.0 -Ic:/msys64/mingw64/include/gtk-3.0 -Ic:/msys64/mingw64/include/harfbuzz -Ic:/msys64/mingw64/include/pango-1.0 -Ic:/msys64/mingw64/include/cairo -Ic:/msys64/mingw64/include/pixman-1 -I/mingw64/include/libpng16 -I/mingw64/include/harfbuzz -Ic:/msys64/mingw64/include -I/mingw64/include/freetype2 -Ic:/msys64/mingw64/include/gdk-pixbuf-2.0 -Ic:/msys64/mingw64/include/libpng16 -IC:/msys64/mingw64/include/atk-1.0 -Ic:/msys64/mingw64/include/glib-2.0 -Ic:/msys64/mingw64/lib/glib-2.0/include Can any one help with this? Regards, Alexey.

ariadne commented

2014-08-15 03:14:49 +00:00

can you explain exactly what the goal is? you want the ability to use DOS-style paths?

Alexpux commented

2014-08-15 05:48:33 +00:00

(Migrated from github.com)

There are several problems using UNIX paths. Native Win32 applications don't understand UNIX style paths. In most cases there are no worry as MSYS* convert paths to windows during execute win32 processes. But this is true only for situations when Win32 process is spawned by MSYS process.
I want to get windows paths from pkgconf when in .pc files present UNIX paths. My patch for paths expanding/relocating mostly work but in some cases I get mixed paths as you see in my previous post.

There are several problems using UNIX paths. Native Win32 applications don't understand UNIX style paths. In most cases there are no worry as MSYS\* convert paths to windows during execute win32 processes. But this is true only for situations when Win32 process is spawned by MSYS process. I want to get windows paths from pkgconf when in .pc files present UNIX paths. My patch for paths expanding/relocating mostly work but in some cases I get mixed paths as you see in my previous post.

ariadne commented

2014-08-15 08:27:44 +00:00

two points:

1 - that patch introduces a large amount of bloat for this functionality, I argue that it could be done much more easily than that. i'm also not so keen on merging things licensed as CC0 because it strays from licensing schemes that most people are familiar with, so i'd prefer to see that code carry the same license as the rest of pkgconf.

2 - i would do the actual rewrite in the fragment handling. if fragment type is I or L, do the relocation in pkg_fragment_add(). it will catch all cases.

two points: 1 - that patch introduces a large amount of bloat for this functionality, I argue that it could be done much more easily than that. i'm also not so keen on merging things licensed as CC0 because it strays from licensing schemes that most people are familiar with, so i'd prefer to see that code carry the same license as the rest of pkgconf. 2 - i would do the actual rewrite in the fragment handling. if fragment type is I or L, do the relocation in pkg_fragment_add(). it will catch all cases.

ariadne commented

2014-08-15 08:31:51 +00:00

another point: this behaviour should probably be explicitly requested somehow. i would prefer to keep using posix-style paths when we are in the posix environment, even on windows.

Alexpux commented

2014-08-15 16:51:42 +00:00

(Migrated from github.com)

I'm add our universal procedures without writing separate peaces of code to simplify my work that is why patch is large (https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-pathtools). I understand that this patch can't be merged and I don't create pull request for it.
Also this is Windows specific issue and not many peoples use it.
We have some issues using posix-style paths with our environment and we decide that patching one program (pkgconf) is more simply than patching hundreds packages.
Thanks, I will try to see pkg_fragment_add procedure.

I'm add our universal procedures without writing separate peaces of code to simplify my work that is why patch is large (https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-pathtools). I understand that this patch can't be merged and I don't create pull request for it. Also this is Windows specific issue and not many peoples use it. We have some issues using posix-style paths with our environment and we decide that patching one program (pkgconf) is more simply than patching hundreds packages. Thanks, I will try to see pkg_fragment_add procedure.

ariadne commented

2015-05-26 09:06:18 +00:00

I'd like to solve this cleanly for 0.10. Can you explain how the pathtools work?

Alexpux commented

2015-05-26 09:22:37 +00:00

(Migrated from github.com)

@kaniini, hi!
Pathtools is just set of procedures that can create proper paths for application if it hardcoded.
For example:

We configure application with --prefix=/usr.
Automake system provide
BINDIR=/usr/bin and LIBDIR=/usr/lib
Application use BINDIR and LIBDIR that is hardcoded after building.

Our pathtools try to relocate this paths by create new valid path basing on hardcoded values (for example, BINDIR and LIBDIR).

We get current path of executable (our new BINDIR)
Create relative path from hardcoded BINDIR and LIBDIR.
Merge new BINDIR with relative path
Simplify path.

There are some patches that we done for relocating applications:
https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-p11-kit/0006-p11-kit-relocation.patch
https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-openssl/openssl-1.0.1i-relocation.patch
https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-imagemagick/001-relocate.patch
https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-pkgconf/0002-relocate.patch

P.S.: For nowadays we back to use original pkg-config utility as pkgconf have some issues that we can't solve ourselves

@kaniini, hi! Pathtools is just set of procedures that can create proper paths for application if it hardcoded. For example: 1. We configure application with `--prefix=/usr`. 2. Automake system provide `BINDIR=/usr/bin` and `LIBDIR=/usr/lib` 3. Application use `BINDIR` and `LIBDIR` that is hardcoded after building. Our pathtools try to relocate this paths by create new valid path basing on hardcoded values (for example, BINDIR and LIBDIR). 1. We get current path of executable (our new BINDIR) 2. Create relative path from hardcoded BINDIR and LIBDIR. 3. Merge new BINDIR with relative path 4. Simplify path. There are some patches that we done for relocating applications: https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-p11-kit/0006-p11-kit-relocation.patch https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-openssl/openssl-1.0.1i-relocation.patch https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-imagemagick/001-relocate.patch https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-pkgconf/0002-relocate.patch P.S.: For nowadays we back to use original `pkg-config` utility as `pkgconf` have some issues that we can't solve ourselves

ariadne commented

2017-01-03 19:50:03 +00:00

So a problem with this approach is, if you have a MSYS on C:\msys2\ for example, and your pkg-config modules are in /d/blah/blah then your patch does not convert to D:\blah\blah.

I am looking into a solution.

So a problem with this approach is, if you have a MSYS on `C:\msys2\` for example, and your pkg-config modules are in `/d/blah/blah` then your patch does not convert to `D:\blah\blah`. I am looking into a solution.

ariadne commented

2017-01-14 02:14:34 +00:00

The new pkgconf_path_relocate() API handles this on cygwin derivatives, including MSYS2.

The new `pkgconf_path_relocate()` API handles this on cygwin derivatives, including MSYS2.

yselkowitz commented

2017-01-24 02:27:59 +00:00

(Migrated from github.com)

We do not want to use Windows paths on Cygwin itself (on which *NIX paths should be used), only on MSYS. Please change the HAVE_CYGWIN_CONV_PATH conditionals to __MSYS__.

We do **not** want to use Windows paths on Cygwin itself (on which *NIX paths should be used), only on MSYS. Please change the `HAVE_CYGWIN_CONV_PATH` conditionals to `__MSYS__`.

ariadne commented

2017-01-24 04:37:21 +00:00

@yselkowitz out of curiosity is CYGWIN declared on msys?

@yselkowitz out of curiosity is __CYGWIN__ declared on msys?

ariadne commented

2017-01-24 04:38:25 +00:00

argh i meant __CYGWIN__

argh i meant `__CYGWIN__`

Alexpux commented

2017-01-24 04:46:33 +00:00

(Migrated from github.com)

It is declared.