Bug #96132 for Perl-Dist-Strawberry: upgrading PkgConfig breakds pkg-config

Show quoted text
this upgrade should work: cpanm PkgConfig --configure-args=--script=pkg-config Show quoted text
I'll try to keep as close as possible to upstream PkgConfig; however I need pkg-config in strawberry perl so upgrading troubles by simply running "cpanm PkgConfig" (without --configure-args=--script=pkg-config) will last. -- kmx

On Mon Jun 02 07:53:55 2014, kmx@volny.cz wrote: Show quoted text
This is pretty inconvenient if PkgConfig is a prereq for something else that pulls it in automatically. This can break PkgConfig and thus ExtUtils::PkgConfig without the user having and inkling that he has upgraded PkgConfig or even what PkgConfig is. I'm not exactly sure why you need this change. PkgConfig installs fine in windows with the symlinks in the tarball. When you made your PR you made no attempt to explain what exactly was breaking, though I went out of my way to maintain a dialog. Perhaps if we worked together we could keep both PkgConfig and Strawberry Perl working properly?

On Mon Jun 02 08:57:52 2014, kmx@volny.cz wrote: Show quoted text
So we probably need one of two things: 1) A way to persist the configuration (a general case) 2) If it finds pkg-config in $Config::Config{sitebin} or $Config::Config{vendorbin} from a previous installation, it continues to use it. (the specific case) I think the problem KMX was trying to solve is that a non-specially-configured Win32 system with perl will not know to use pkg-config.pl or ppkg-config when 'pkg-config' is requested on the command line, and that's what most modules depending on the pkg-config interface do, I understand (either through ExtUtils::PkgConfig or by calling it itself.) I remember running into that problem when I was building it. So Strawberry uses the --configure-args=--script=pkg-config option when it installs the module in order to work around this problem in the version it installed, but cpan/cpanm/cpanp doesn't know to KEEP doing that, and what about manual installations outside those programs?

Not to belabor the point, but for clarity, I am totally 100% on board and agree and am excited about the goal of making PkgConfig THE pkg-config for strawberry Perl since the alternative is basically to not have pkg-config in Strawberry. This can be accomplished with this commit, which is part of the upstream version of PkgConfig: https://github.com/mnunberg/perl-PkgConfig/commit/427e7b8bbff2f53f502c5f03d1e1f5cc8a3022a4 I just don't see how this goal has anything to do with this commit: https://github.com/StrawberryPerl/perl-PkgConfig/commit/2d4146b8815a88b72257a3f5b10948f92772f916

Show quoted text
This commit (as stated in commit message) is about "no symlinks" - which you have rejected and I accept your decision although my opinion is different. PkgConfig is simply yours. -- kmx

On 2.6.2014 20:18, Graham Ollis via RT wrote: Show quoted text
relocation.pl.bat can patch .pc files (providing that I first change all /mingw occurrences to c:/strawberry/c) but it does not solve portable version of strawberry perl. Show quoted text
I understand. However PkgConfig is not the only one patched/forked module bundled with strawberry perl. Show quoted text
The commit in question has message "improved Win32 compatibility - no symlinks" and this message is true. I have never claimed that this commit is necessary to have pkg-config in strawberry. You have responded "Feel free to open a new issue if you want to discuss the symlinks." - which I do not want and thus have not open a new issue. Show quoted text
Perhaps making "pkg-config" a default name in case strawberry perl is detected would do the trick. -- kmx

On 2.6.2014 22:17, Graham Ollis via RT wrote: Show quoted text
Well, actually we do not have anything like portable perl detection. There are some special hacks implemented via Portable module (it handles Config values, CPAN::Config values + something else). Detecting portable perl root is the same problem as detecting strawberry perl root e.g. my $root = $^X =~ s|\\perl\\bin\\perl.exe||r; Show quoted text
It was really nothing against you personally. During last approx. 10 weeks I have spent nearly all my free time on preparing strawberry perl 5.20.0.1 release which has new gcc toolchain + new mingw-w64 C-runtime (which I have to build from sources - twice 32/64bit), approx 30 external libraries (which I have to build from sources - twice 32/64bit) and approx 400 perl modules (all built 3 times - 64bit, 32bit_with_64bit_int, 32bit_without_64bit_int) + bunch of fixed issues. At some point I found PkgConfig to be an easy way for having working pkg-config and I simply included my patched/forked version which was "good enough" and I stayed with it even after you have released newer version (it would required another time - which I was short of - to take your newer version and back port my extra hacks). The same kind of "fork of a bit older version" we have for example with ExtUtils::Depends. That's it, nothing less, nothing more. I know that for you PkgConfig is THE module. But for me it is just one from four hundred. Knowing that it will start such a hot discussion I would rather not include PkgConfig at all or include it as a Alt::PkgConfig to clearly indicate it is a fork (which we have already done for example with Crypt::RSA vs. Alt::Crypt::RSA::BigInt - which was however not forked by me). Perhaps we should rather move on. Show quoted text
I am fine with having both ppkg-config and pkg-config -- kmx

On 2.6.2014 23:47, Graham Ollis via RT wrote: Show quoted text
This can work and it is for me quite easy to implement. But obviously it will work only with future strawberry perl releases that will have properly patched .pc files. Show quoted text
Patched version is http://strawberryperl.com/package/kmx/perl-modules-patched/PkgConfig-0.07220_99.tar.gz The only remaining important thing is /mingw patching which can be handled via ${pcfiledir} Some minor issues might pop up later. -- kmx

On Tue Jun 03 08:03:29 2014, PLICEASE wrote: Show quoted text
$Config::Config{'uname'} is worth testing for some of this. When we build, we jump through hoops to make identifying Strawberry, and the release, accessible there. Unfortunately, it doesn't include the fact that it is a 'portable' build or not there, but there are specific modules that help implement the portability that could be tested for. KMX can help you out there. C:\Users\Curtis>perl -V Summary of my perl5 (revision 5 version 18 subversion 0) configuration: ... uname='Win32 strawberry-perl 5.18.0.1 #1 Sat May 18 19:40:33 2013 x64' ...

Here is a newer dev version which I believe gets the exclusions correct: http://cpan.metacpan.org/authors/id/P/PL/PLICEASE/PkgConfig-0.07520_04.tar.gz I am going to let it do the rounds on cpantesters for a few days and then I will cut a production release. If you have any concerns, please let me know. By the time you do the next release of Strawberry, this should have made it to production. On Wed Jun 04 04:14:45 2014, kmx@volny.cz wrote: Show quoted text
Exactly what I wanted to see, thanks. Show quoted text
This is the way I did it: 1. on Strawberry Perl 5.20.0.1 or better (but not MSWin32 generally) both ppkg-config and pkg-config will be installed by default when installed by the user from CPAN 2. on Strawberry Perl 5.18.* and earlier (and MSWin32 generally) only ppkg-config will be installed when installed by the user from CPAN. My recommendation is that Strawberry use the --script=pkg-config option and ONLY install pkg-config for its bundled version. I feel that someone who is used to PkgConfig and ppkg-config can reasonably expect ppkg-config to be there if they manually install it from CPAN, but the vast majority of users will not expect or need ppkg-config. I guess you also get it with an upgrade which might be part of an automated process. My rationale for not installing pkg-config by default on older Strawberries is that the .pc files aren't going to be right for things like freetype2, and it also sort of changes the behavior of Strawberry after 5.18/16.* have been in production for a long time. I have included instructions and a script for manually patching the .pc files and installing pkg-config on older Strawberries. If the user does need this capability they can proactively choose to make the changes themselves, but I feel it shouldn't happen automatically. If you have any concerns with this strategy, please let me know. Show quoted text
I would kind of like to see an API for this sort of thing, but this is adequate. Are these special configuration items documented anywhere? When I was looking for Strawberry detection I did eventually stumble on a stack overflow with the myuname suggestion, but I didn't feel totally confident about its permanence since I couldn't find any documentation on it. Show quoted text
Definitely portable entry would be useful for diagnostics. Maybe make it 0 or 1, and undef can be for older Strawberries which do not include have the value at all? Show quoted text
As above I feel that installing pkg-config on pre-5.20 should be part of an active choice the user makes. Show quoted text
So I hesitate to do this since I am not totally confident that I won't accidentally override another working pkg-config. I feel as though if there is a pkg-config there already then it is either because 1. The user has used --script option previously to force its inclusion, and thus probably knows enough about PkgConfig to use it again 2. They are using 5.20, in which case PkgConfig will install pkg-config anyway 3. They have the C version of pkg-config.exe Show quoted text
This sounds fine to me, I don't think this issue by itself is urgent enough for a new Strawberry release. Show quoted text
Enjoy your time on other pursuits :)