Skip Menu |
 

This queue is for tickets about the Perl-Dist-Strawberry CPAN distribution.

Report information
The Basics
Id: 96132
Status: resolved
Priority: 0/
Queue: Perl-Dist-Strawberry

People
Owner: Nobody in particular
Requestors: PLICEASE [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: upgrading PkgConfig breakds pkg-config
Download (untitled) / with headers
text/plain 1.1k
Hi there, It's great that you've included PkgConfig with strawberry perl and are using it for pkg-config. Unfortunately, you've included parts of this PR to PkgConfig which were not merged: https://github.com/mnunberg/perl-PkgConfig/pull/10 and now upgrading PkgConfig breaks pkg-config: N:\>pkg-config Must specify at least one library at N:/lang/perl/strawberry/x86/5.20.0/perl/vendor/lib/PkgConfig.pm line 906. N:\>cpanm PkgConfig --> Working on PkgConfig Fetching http://mirror.sydney.wdlabs.com/cpan/authors/id/P/PL/PLICEASE/PkgConfig-0.07420.tar.gz ... OK Configuring PkgConfig-0.07420 ... OK Building and testing PkgConfig-0.07420 ... OK Successfully installed PkgConfig-0.07420 (upgraded from 0.07220_99) 1 distribution installed N:\>pkg-config Undefined subroutine &PkgConfig::Script::run called at N:\lang\perl\strawberry\x86\5.20.0\perl\bin/pkg-config line 5. I would appreciate it if you could integrate PkgConfig and ppkg-config in such a way that it can work seamlessly with the upstream variant. I am open to possibly making changes to PkgConfig, although my goal is to respect the wishes of the original author.
Subject: Re: [rt.cpan.org #96132] upgrading PkgConfig breakds pkg-config
Date: Mon, 02 Jun 2014 13:53:42 +0200
To: bug-Perl-Dist-Strawberry [...] rt.cpan.org
From: kmx <kmx [...] volny.cz>
Download (untitled) / with headers
text/plain 733b
Show quoted text
> N:\>pkg-config > Must specify at least one library at N:/lang/perl/strawberry/x86/5.20.0/perl/vendor/lib/PkgConfig.pm line 906. > > N:\>cpanm PkgConfig
this upgrade should work: cpanm PkgConfig --configure-args=--script=pkg-config Show quoted text
> I would appreciate it if you could integrate PkgConfig and ppkg-config in such a way that it can work seamlessly with the upstream variant. I am open to possibly making changes to PkgConfig, although my goal is to respect the wishes of the original author.
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
Download (untitled) / with headers
text/plain 737b
On Mon Jun 02 07:53:55 2014, kmx@volny.cz wrote: Show quoted text
> this upgrade should work: > > cpanm PkgConfig --configure-args=--script=pkg-config
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?
Subject: Re: [rt.cpan.org #96132] upgrading PkgConfig breakds pkg-config
Date: Mon, 02 Jun 2014 14:57:40 +0200
To: bug-Perl-Dist-Strawberry [...] rt.cpan.org
From: kmx <kmx [...] volny.cz>
Download (untitled) / with headers
text/plain 1.3k
Show quoted text
>
>> this upgrade should work: >> >> cpanm PkgConfig --configure-args=--script=pkg-config
> 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 simply need a working command "pkg-config" (neither "ppkg-config" nor "pkg-config.pl" is enough) therefore I install PkgConfig via: cpanm PkgConfig --configure-args=--script=pkg-config Show quoted text
> 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?
Troubles with symlinks are mostly during development if you want to clone github repo and play with some changes as I did. But keep in mind that at install time on Win32 all symlinks are turned into file copies. Therefore if I initially install: cpanm PkgConfig --configure-args=--script=pkg-config and later do upgrade via: cpanm PkgConfig the file "pkg-config" (or "pkg-config.bat" in case on MSWin32) will still be the copy of the old version. -- kmx
Download (untitled) / with headers
text/plain 2.3k
On Mon Jun 02 08:57:52 2014, kmx@volny.cz wrote: Show quoted text
>
> >
> >> this upgrade should work: > >> > >> cpanm PkgConfig --configure-args=--script=pkg-config
> > 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 simply need a working command "pkg-config" (neither "ppkg-config" > nor > "pkg-config.pl" is enough) therefore I install PkgConfig via: > > cpanm PkgConfig --configure-args=--script=pkg-config > > >
> > 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?
> > Troubles with symlinks are mostly during development if you want to > clone > github repo and play with some changes as I did. But keep in mind that > at > install time on Win32 all symlinks are turned into file copies. > > Therefore if I initially install: > cpanm PkgConfig --configure-args=--script=pkg-config > > and later do upgrade via: > cpanm PkgConfig > > the file "pkg-config" (or "pkg-config.bat" in case on MSWin32) will > still > be the copy of the old version.
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?
Download (untitled) / with headers
text/plain 1.7k
On Mon Jun 02 08:57:52 2014, kmx@volny.cz wrote: Show quoted text
> I simply need a working command "pkg-config" (neither "ppkg-config" > nor > "pkg-config.pl" is enough) therefore I install PkgConfig via: > > cpanm PkgConfig --configure-args=--script=pkg-config
I merged that change, since it was obviously useful. Show quoted text
> Troubles with symlinks are mostly during development if you want to > clone > github repo and play with some changes as I did. But keep in mind that > at > install time on Win32 all symlinks are turned into file copies.
I find the use of symlinks a little inconvenient when working on Windows but I managed to hold my nose enough to get things working there since I do most of my development on Linux. To make things a little easier, I've just added a script win32/fixlinks.pl which replaces the git symlinks with real windows symlinks (the only drawback is that it requires admin priv). This seems to work pretty well at the cost of a little extra effort for windows developers. Show quoted text
> the file "pkg-config" (or "pkg-config.bat" in case on MSWin32) will > still > be the copy of the old version.
I think we can agree though that having an older working version is better than having one that doesn't work? As a compromise, I've added a PkgConfig::Script::run function which should allow pkg-config to continue working after an upgrade to PkgConfig. I think you have a couple of other changes in your version, that may be useful if incorporated upstream, and I'd welcome any PR that you have. The paths seem to be translated from /mingw to the appropriate Strawberry Perl paths for example, which my version does not do. Although since gcc already knows about those paths, I think the more appropriate approach would be to include /mingw paths in the DEFAULT_EXCLUDE_{CFLAGS,LFLAGS} lists.
Download (untitled) / with headers
text/plain 592b
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
Subject: Re: [rt.cpan.org #96132] upgrading PkgConfig breakds pkg-config
Date: Mon, 02 Jun 2014 19:39:38 +0200
To: bug-Perl-Dist-Strawberry [...] rt.cpan.org
From: kmx <kmx [...] volny.cz>
Download (untitled) / with headers
text/plain 1.2k
Show quoted text
> I think we can agree though that having an older working version is better than having one that doesn't work?
Sure. Show quoted text
> I think you have a couple of other changes in your version, that may be useful if incorporated upstream, and I'd welcome any PR that you have. The paths seem to be translated from /mingw to the appropriate Strawberry Perl paths for example, which my version does not do. Although since gcc already knows about those paths, I think the more appropriate approach would be to include /mingw paths in the DEFAULT_EXCLUDE_{CFLAGS,LFLAGS} lists.
This part is kind of an dirty hack which I am not sure about and considering the ugliness I am not sure if I want to propose it as a patch upstream. The trouble with /mingw is that it might be ignored (skipped) when used like: -L/mingw/lib or -I/mingw/include but not in case -I/mingw/include/freetype2 Patching /mingw like I do now is one possibility (which I do not like) the other is to force PkgConfig to somehow override variables: - prefix="c:/strawberry/c" - exec_prefix="c:/strawberry/c" - libdir="c:/strawberry/c/lib" - includedir="c:/strawberry/c/include" NOTE1: I am not sure about back/forward slashes here NOTE2: some of the *.pc files in strawberry perl are not correct and will still return bogus values -- kmx
Subject: Re: [rt.cpan.org #96132] upgrading PkgConfig breakds pkg-config
Date: Mon, 02 Jun 2014 19:43:55 +0200
To: bug-Perl-Dist-Strawberry [...] rt.cpan.org
From: kmx <kmx [...] volny.cz>
Download (untitled) / with headers
text/plain 362b
Show quoted text
> I just don't see how this goal has anything to do with this commit: > > https://github.com/StrawberryPerl/perl-PkgConfig/commit/2d4146b8815a88b72257a3f5b10948f92772f916
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
Download (untitled) / with headers
text/plain 2.1k
On Mon Jun 02 13:39:53 2014, kmx@volny.cz wrote: Show quoted text
> This part is kind of an dirty hack which I am not sure about and > considering the ugliness I am not sure if I want to propose it as a > patch > upstream. > > The trouble with /mingw is that it might be ignored (skipped) when > used > like: -L/mingw/lib or -I/mingw/include but not in case > -I/mingw/include/freetype2 > > Patching /mingw like I do now is one possibility (which I do not like) > the > other is to force PkgConfig to somehow override variables: > - prefix="c:/strawberry/c" > - exec_prefix="c:/strawberry/c" > - libdir="c:/strawberry/c/lib" > - includedir="c:/strawberry/c/include" > NOTE1: I am not sure about back/forward slashes here > NOTE2: some of the *.pc files in strawberry perl are not correct and > will > still return bogus values
Would it be possible for relocation.pl.bat update the .pc files? That way they would work even in the unlikely event someone had the real c version of pkg-config installed. I see the point about include/freetype2. I think the exclude lists don't exclude subdirectories though I will have to check. Show quoted text
>> I just don't see how this goal has anything to do with this commit: >> >> https://github.com/StrawberryPerl/perl-PkgConfig/commit/2d4146b8815a88b72257a3f5b10948f92772f916
> > 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.
Can you understand my frustration though when you say you have accepted this, but bundle the forked version anyway? I bring this commit up because the response to this ticket seems to be "we need this in order to have pkg-config in strawberry", but it doesn't seem to me that you have demonstrated this. I am open to having some smarts to the PkgConfig Makefile.PL, to have it install pkg-config if Strawberry Perl 5.20.0 or better is detected (I don't want to do this automatically for a MSVC or other non-Strawberry Perl on MSWin32). That would solve the issue of having an old version of pkg-config. Most people will not be using the --script option for the Makefile.PL and those that do can be expected to deal with the caveats associated with it.
Subject: Re: [rt.cpan.org #96132] upgrading PkgConfig breakds pkg-config
Date: Mon, 02 Jun 2014 20:51:02 +0200
To: bug-Perl-Dist-Strawberry [...] rt.cpan.org
From: kmx <kmx [...] volny.cz>
Download (untitled) / with headers
text/plain 2.8k
On 2.6.2014 20:18, Graham Ollis via RT wrote: Show quoted text
> Queue: Perl-Dist-Strawberry > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=96132 > > > On Mon Jun 02 13:39:53 2014, kmx@volny.cz wrote:
>> This part is kind of an dirty hack which I am not sure about and >> considering the ugliness I am not sure if I want to propose it as a >> patch >> upstream. >> >> The trouble with /mingw is that it might be ignored (skipped) when >> used >> like: -L/mingw/lib or -I/mingw/include but not in case >> -I/mingw/include/freetype2 >> >> Patching /mingw like I do now is one possibility (which I do not like) >> the >> other is to force PkgConfig to somehow override variables: >> - prefix="c:/strawberry/c" >> - exec_prefix="c:/strawberry/c" >> - libdir="c:/strawberry/c/lib" >> - includedir="c:/strawberry/c/include" >> NOTE1: I am not sure about back/forward slashes here >> NOTE2: some of the *.pc files in strawberry perl are not correct and >> will >> still return bogus values
> Would it be possible for relocation.pl.bat update the .pc files? That way they would work even in the unlikely event someone had the real c version of pkg-config installed.
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 just don't see how this goal has anything to do with this commit: >>> >>> https://github.com/StrawberryPerl/perl-PkgConfig/commit/2d4146b8815a88b72257a3f5b10948f92772f916
>> 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.
> Can you understand my frustration though when you say you have accepted this, but bundle the forked version anyway?
I understand. However PkgConfig is not the only one patched/forked module bundled with strawberry perl. Show quoted text
> I bring this commit up because the response to this ticket seems to be "we need this in order to have pkg-config in strawberry", but it doesn't seem to me that you have demonstrated this.
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
> I am open to having some smarts to the PkgConfig Makefile.PL, to have it install pkg-config if Strawberry Perl 5.20.0 or better is detected (I don't want to do this automatically for a MSVC or other non-Strawberry Perl on MSWin32). That would solve the issue of having an old version of pkg-config.
Perhaps making "pkg-config" a default name in case strawberry perl is detected would do the trick. -- kmx
Download (untitled) / with headers
text/plain 2.2k
On Mon Jun 02 14:51:21 2014, kmx@volny.cz 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.
Is there someway to detect the portable version and where the root is? This kind of issue must come up with other modules. Show quoted text
> I understand. However PkgConfig is not the only one patched/forked > module > bundled with strawberry perl.
I totally sympathize with this since most Perl module authors do not care about Windows at all. It was not a priority for the previous owner of PkgConfig and so it took a some effort on my part to get it to work at all on Strawberry. In this case I am willing to work with you or anyone to make PkgConfig more portable and work in Strawberry (or anywhere else). If we can improve upstream to the point that you don't NEED to maintain a fork it means less work for you, and less frustration for me when your version works differently from mine. 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.
Again I am not contesting the intent of the commit, I am contesting the necessity of it given the negative consequences of it. When I opened this ticket which is related to THIS commit you said "however I need pkg-config in strawberry perl so upgrading troubles by simply running "cpanm PkgConfig" (without --configure-args=--script=pkg-config) will last." However you do not NEED to include this change in order for pkg-config to work. And with respect, this change does not "keep as close as possible to upstream PkgConfig". Show quoted text
> Perhaps making "pkg-config" a default name in case strawberry perl is > detected would do the trick.
What I had in mind is to make pkg-config installed in addition to ppkg-config that way it would work as the documentation says that it works. When you install it using the --script option it would only install the specified versions, thus you could use it as the bundled Strawberry version. I will include this change in the next version.
Subject: Re: [rt.cpan.org #96132] upgrading PkgConfig breakds pkg-config
Date: Mon, 02 Jun 2014 23:11:00 +0200
To: bug-Perl-Dist-Strawberry [...] rt.cpan.org
From: kmx <kmx [...] volny.cz>
On 2.6.2014 22:17, Graham Ollis via RT wrote: Show quoted text
> On Mon Jun 02 14:51:21 2014, kmx@volny.cz wrote:
>> 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.
> Is there someway to detect the portable version and where the root is? This kind of issue must come up with other modules.
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
>
>> I understand. However PkgConfig is not the only one patched/forked >> module >> bundled with strawberry perl.
> I totally sympathize with this since most Perl module authors do not care about Windows at all. It was not a priority for the previous owner of PkgConfig and so it took a some effort on my part to get it to work at all on Strawberry. > > In this case I am willing to work with you or anyone to make PkgConfig more portable and work in Strawberry (or anywhere else). If we can improve upstream to the point that you don't NEED to maintain a fork it means less work for you, and less frustration for me when your version works differently from mine. >
>> 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.
> Again I am not contesting the intent of the commit, I am contesting the necessity of it given the negative consequences of it. When I opened this ticket which is related to THIS commit you said > > "however I need > pkg-config in strawberry perl so upgrading troubles by simply running > "cpanm PkgConfig" (without --configure-args=--script=pkg-config) will last." > > However you do not NEED to include this change in order for pkg-config to work. And with respect, this change does not "keep as close as possible to upstream PkgConfig".
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
>
>> Perhaps making "pkg-config" a default name in case strawberry perl is >> detected would do the trick.
> What I had in mind is to make pkg-config installed in addition to ppkg-config that way it would work as the documentation says that it works. When you install it using the --script option it would only install the specified versions, thus you could use it as the bundled Strawberry version. I will include this change in the next version.
I am fine with having both ppkg-config and pkg-config -- kmx
Download (untitled) / with headers
text/plain 1.8k
On Mon Jun 02 17:11:19 2014, kmx@volny.cz 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;
Actually the more I think about it I think the best solution is to use ${pcfiledir}. That would work for both portable and unportable Strawberry. I'd need to implement this outstanding issue, but I don't think that would be too difficult. https://github.com/mnunberg/perl-PkgConfig/issues/2 Strawberry would need to modify the the /mingw/include/freetype2 to be ${pcfiledir}/../include/freetype2 style paths but ideally not the /mingw/include ones (the latter being less important). Show quoted text
> That's it, nothing less, nothing more.
Show quoted text
> I know that for you PkgConfig is THE module. But for me it is just one > from > four hundred.
Honestly? PkgConfig is not the extent of my universe. I have hundreds of modules to deal with too, and I maintain large complicated systems with multiple conflicting interests (32/64/linux/cygwin/MSWin32/*BSD/users/developers/system admins, you name it). I don't refuse help when people offer it just because I can't make an incompatible change to someone else's code. Show quoted text
> Perhaps we should rather move on.
Can we please fix this properly? I think we are pretty close here: the way it stands now you can upgrade PkgConfig, and some things will still work but things like freetype2 won't. I'm willing to do the legwork in Strawberry land since I can see this issue is taking your interest. Is there anything aside from the /mingw paths that we have would need to deal with? I am not familiar with the extent of changes you made in your fork. Is it stored in revision control somewhere?
Subject: Re: [rt.cpan.org #96132] upgrading PkgConfig breakds pkg-config
Date: Tue, 03 Jun 2014 00:28:02 +0200
To: bug-Perl-Dist-Strawberry [...] rt.cpan.org
From: kmx <kmx [...] volny.cz>
Download (untitled) / with headers
text/plain 1.9k
On 2.6.2014 23:47, Graham Ollis via RT wrote: Show quoted text
> Queue: Perl-Dist-Strawberry > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=96132 > > > On Mon Jun 02 17:11:19 2014, kmx@volny.cz wrote:
>> 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;
> Actually the more I think about it I think the best solution is to use ${pcfiledir}. That would work for both portable and unportable Strawberry. I'd need to implement this outstanding issue, but I don't think that would be too difficult. > > https://github.com/mnunberg/perl-PkgConfig/issues/2 > > Strawberry would need to modify the the /mingw/include/freetype2 to be ${pcfiledir}/../include/freetype2 style paths but ideally not the /mingw/include ones (the latter being less important).
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
>> Perhaps we should rather move on.
> Can we please fix this properly? I think we are pretty close here: the way it stands now you can upgrade PkgConfig, and some things will still work but things like freetype2 won't. > > I'm willing to do the legwork in Strawberry land since I can see this issue is taking your interest. > > Is there anything aside from the /mingw paths that we have would need to deal with? I am not familiar with the extent of changes you made in your fork. Is it stored in revision control somewhere?
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 Mon Jun 02 18:28:30 2014, kmx@volny.cz 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.
Sounds great, I only offered to help to save you the effort, but if you can do it easily that will save some time. I think the easiest thing to do is just to do a simple conversion of paths. I can add both /mingw/include and /mingw/lib/pkgconfig/../../include (and lib equivalents) to the list of ignore paths. Making sure to include include/freetype2 style paths. If you can give me some example .pc files I can make sure that my exclusions are correct when I implement them. Show quoted text
> The only remaining important thing is /mingw patching which can be > handled > via ${pcfiledir}
Here is a dev version which includes ${pcfiledir} support. https://metacpan.org/pod/release/PLICEASE/PkgConfig-0.07520_01/lib/PkgConfig.pm I am also now using $^X instead of $INC{'Config.pm'} to find the root to match how you are doing it. I went with Config.pm because $^X is somewhat unreliable on some platforms, but since this is MSWin32 specific code that shouldn't matter (?) I think something like a Strawberry.pm that reported the root and the type of strawberry (portable, unportable, MSI, zip, etc), the strawberry release (is that available somewhere?) would be helpful for module authors with unusual requirements who want to support Strawberry. Show quoted text
> Some minor issues might pop up later.
I expect they will. Question: do you expect to back port PkgConfig / pkg-config to future versions of 5.18 or earlier? If so I will want to change the logic in my Makefile.PL. (My slight preference would be not to back port). Qestion 2: Is there any time table for 5.20.0.2? Or are new versions released as necessary? Or do we wait for 5.20.1? Not pushing for a release, just wanted to have an idea on what to expect. I appreciate your hearing me out, I realize this is not necessarily your priority, but I think we will both be glad that we were able to compromise on a less hackish solution.
Download (untitled) / with headers
text/plain 887b
On Tue Jun 03 08:03:29 2014, PLICEASE wrote: Show quoted text
> I think something like a Strawberry.pm that reported the root and the > type of strawberry (portable, unportable, MSI, zip, etc), the > strawberry release (is that available somewhere?) would be helpful for > module authors with unusual requirements who want to support > Strawberry.
$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' ...
Subject: Re: [rt.cpan.org #96132] upgrading PkgConfig breakds pkg-config
Date: Wed, 04 Jun 2014 10:14:25 +0200
To: bug-Perl-Dist-Strawberry [...] rt.cpan.org
From: kmx <kmx [...] volny.cz>
Download (untitled) / with headers
text/plain 2.3k
Show quoted text
> If you can give me some example .pc files I can make sure that my exclusions are correct when I implement them.
see pcfiles.zip - they are not unified (each is a bit different) this is how they are produced by the build procedure Show quoted text
> Here is a dev version which includes ${pcfiledir} support. > > https://metacpan.org/pod/release/PLICEASE/PkgConfig-0.07520_01/lib/PkgConfig.pm
Your dev version seems to work fine (even with enclosed patched .pc files). I have a question: will it be guaranteed that on strawberry PkgConfig will install pkg-config or should I rather use --script=pkg-config option? Show quoted text
> I think something like a Strawberry.pm that reported the root and the type of strawberry (portable, unportable, MSI, zip, etc), the strawberry release (is that available somewhere?) would be helpful for module authors with unusual requirements who want to support Strawberry.
As Curtis said there is $Config{myuname} which is guaranteed to contain "strawberry-perl" string Maybe we can consider: $Config{mystrawberryroot} = 'C:\Strawberry' (of course properly relocated) or even maybe: $Config{mystrawberryportable} = 1 (or undef) It is just an idea I am not saying I am going to implement it right now. Show quoted text
> Question: do you expect to back port PkgConfig / pkg-config to future versions of 5.18 or earlier? If so I will want to change the logic in my Makefile.PL. (My slight preference would be not to back port).
Definitely not but it might be worth considering whether also pre-5.20 strawberry users should have pkg-config installed by default (along with ppkg-config). Or maybe you can detect in Makefile.PL whether there is already working 'pkg-config' command and if not then install it. Show quoted text
> Qestion 2: Is there any time table for 5.20.0.2? Or are new versions released as necessary? Or do we wait for 5.20.1? Not pushing for a release, just wanted to have an idea on what to expect.
Unless someone reports a really bad bug/issue/problem/trouble the next release will be 5.20.1.1 - which I guess will be in August 2014 Show quoted text
> I appreciate your hearing me out, I realize this is not necessarily your priority, but I think we will both be glad that we were able to compromise on a less hackish solution.
I also want to thank you, especially for your time. To be honest my current priority is to plug off from strawberry hacking for a month or two :) -- kmx
Download pcfiles.zip
application/x-zip-compressed 7.5k

Message body not shown because it is not plain text.

Download (untitled) / with headers
text/plain 4.2k
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
> see pcfiles.zip - they are not unified (each is a bit different) this > is > how they are produced by the build procedure
Exactly what I wanted to see, thanks. Show quoted text
> Your dev version seems to work fine (even with enclosed patched .pc > files). > I have a question: will it be guaranteed that on strawberry PkgConfig > will > install pkg-config or should I rather use --script=pkg-config option?
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
> As Curtis said there is $Config{myuname} which is guaranteed to > contain > "strawberry-perl" string
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
> Maybe we can consider: > $Config{mystrawberryroot} = 'C:\Strawberry' (of course properly > relocated) > or even maybe: > $Config{mystrawberryportable} = 1 (or undef) > > It is just an idea I am not saying I am going to implement it right > now.
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
> Definitely not but it might be worth considering whether also pre-5.20 > strawberry users should have pkg-config installed by default (along > with > ppkg-config).
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
> Or maybe you can detect in Makefile.PL whether there is already > working > 'pkg-config' command and if not then install it.
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
> Unless someone reports a really bad bug/issue/problem/trouble the next > release will be 5.20.1.1 - which I guess will be in August 2014
This sounds fine to me, I don't think this issue by itself is urgent enough for a new Strawberry release. Show quoted text
> To be honest my current priority is to plug off from strawberry > hacking for > a month or two :)
Enjoy your time on other pursuits :)
Should be fixed in strawberry perl 5.20.1.1 which was reelased today


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.