ariadne
/
pkgconf
3
6
Fork 4
Code Issues 6 Pull Requests 2 Projects Releases 2 Wiki Activity

Relocating paths from .pc files on Windows #72

New Issue
Closed
opened 2014-08-09 06:02:55 +00:00 by Alexpux · 14 comments
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?

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.

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?

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:

  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

@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.

It is declared.
ariadne commented 2017-01-24 05:18:31 +00:00

The requested change will be included in the 1.2.2 release.

The requested change will be included in the 1.2.2 release.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
master
stable/1.8.x
feature/tap-sh
pkgconf-2.2.0
pkgconf-2.1.1
pkgconf-2.1.0
pkgconf-2.0.3
pkgconf-2.0.2
pkgconf-2.0.1
pkgconf-2.0.0
pkgconf-1.9.5
pkgconf-1.8.1
pkgconf-1.9.4
pkgconf-1.9.3
pkgconf-1.9.2
pkgconf-1.9.1
pkgconf-1.9.0
pkgconf-1.8.0
pkgconf-1.7.4
pkgconf-1.7.3
pkgconf-1.7.2
pkgconf-1.7.1
pkgconf-1.7.0
pkgconf-1.6.3
pkgconf-1.6.2
pkgconf-1.6.1
pkgconf-1.6.0
pkgconf-1.5.4
pkgconf-1.5.3
pkgconf-1.5.2
pkgconf-1.5.1
pkgconf-1.4.2
pkgconf-1.4.1
pkgconf-1.4.0
pkgconf-1.3.90
pkgconf-1.3.12
pkgconf-1.3.11
pkgconf-1.3.10
pkgconf-1.3.9
pkgconf-1.3.8
pkgconf-1.3.7
pkgconf-1.3.6
pkgconf-1.3.5
pkgconf-1.3.4
pkgconf-1.3.3
pkgconf-1.3.2
pkgconf-1.3.1
pkgconf-1.3.0
pkgconf-1.2.2
pkgconf-1.2.1
pkgconf-1.2.0
pkgconf-1.1.1
pkgconf-1.1.0
pkgconf-1.0.2
pkgconf-1.0.1
pkgconf-1
pkgconf-0.9.12
pkgconf-0.9.11
pkgconf-0.9.10
pkgconf-0.9.9
pkgconf-0.9.8
pkgconf-0.9.7
pkgconf-0.9.6
pkgconf-0.9.5
pkgconf-0.9.4
pkgconf-0.9.3
pkgconf-0.9.2
pkgconf-0.9.1
pkgconf-0.9.0
pkgconf-0.8.12
pkgconf-0.8.11
pkgconf-0.8.10
pkgconf-0.8.9
pkgconf-0.8.8
pkgconf-0.8.7
pkgconf-0.8.6
pkgconf-0.8.5
pkgconf-0.8.4
pkgconf-0.8.3
pkgconf-0.8.2
pkgconf-0.8.1
pkgconf-0.8
pkgconf-0.7
pkgconf-0.6
pkgconf-0.5.3
pkgconf-0.5.2
pkgconf-0.5.1
pkgconf-0.5
pkgconf-0.4
pkgconf-0.3
pkgconf-0.2
pkgconf-0.1.1
pkgconf-0.1
Labels
Clear labels   
bug
   
duplicate
   
enhancement
   
invalid
   
question
   
wontfix
No Label
bug
duplicate
enhancement
invalid
question
wontfix
Milestone
Clear milestone
No items
No Milestone
pkgconf 1.2
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: ariadne/pkgconf#72
There is no content yet.
Delete Branch "%!s(<nil>)"

Deleting a branch is permanent. Although the deleted branch may exist for a short time before cleaning up, in most cases it CANNOT be undone. Continue?