Beefy Boxes and Bandwidth Generously Provided by pair Networks Bob
P is for Practical
 
PerlMonks

Strawberry CPAN.pm wrongly overrides INC in Makefile.PL

by nobull (Friar)
 | Log in | Create a new user | The Monastery Gates | Super Search | 
 | Seekers of Perl Wisdom | Meditations | PerlMonks Discussion | 
 | Obfuscation | Reviews | Cool Uses For Perl | Perl News | Q&A | Tutorials | 
 | Poetry | Recent Threads | Newest Nodes | Donate | What's New | 

on Sep 28, 2008 at 09:50 UTC ( #714150=perlquestion: print w/ replies, xml ) Need Help??
nobull has asked for the wisdom of the Perl Monks concerning the following question:

Admin note: I posted this to "Seekers..." but on reflection it probably should be a "Meditation". Could someone with the power please move it.

I have Strawberry Perl 5.10.0.2 installed on WinXP SP3 and Win2003 boxes.

I can download modules from CPAN and build them manually using.

perl Makefile.PL dmake dmake test dmake install

This all works fine because the PATH, INCLUDE and LIB environment variables contain the relevant directories under C:\strawberry.

However if I use the CPAN module it invokes perl to build the Makefile thus:

C:\strawberry\perl\bin\perl.exe Makefile.PL LIBS=-LC:\strawberry\c\lib + INC=- IC:\strawberry\c\include

Most of the time this is harmless but in some cases this results in a broken Makefile. For example in Compress::Raw::Zlib Makefile.PL contains the following:

WriteMakefile( NAME => 'Compress::Raw::Zlib', VERSION_FROM => 'lib/Compress/Raw/Zlib.pm', INC => "-I$ZLIB_INCLUDE" ,

Relevant extracts from the (broken) Makefile for Compress::Raw::Zlib generated by running Makefile.PL from CPAN:

# # MakeMaker ARGV: (q[LIBS=-LC:\strawberry\c\lib], q[INC=-IC:\strawbe +rry\c\include]) # # MakeMaker Parameters: # INC => q[-I./zlib-src] # --- MakeMaker constants section: INC = -IC:\strawberry\c\include

And, for comparison, relevant extracts from (working) Makefile for Compress::Raw::Zlib generated by running Makefile.PL manually:

# # MakeMaker ARGV: () # # MakeMaker Parameters: # INC => q[-I./zlib-src] # --- MakeMaker constants section: INC = -I./zlib-src

The outcome of this is that under the CPAN module the compiler can't find any of the include files in the zlib-src subdirctory.

This is relatively easy to fix by editing c:/strawberry/perl/lib/CPAN/Config.pm and changing the line...

makepl_arg => q[LIBS=-LC:\\strawberry\\c\\lib INC=-IC:\\strawberry\\c\ +\include],
...to...
makepl_arg => q[],

Who should I advise this to in order to get it fixed in the next release of Strawberry?

Update: oops, transposition in the Makefile snippets corrected.

Update: jettero suggests there may be a mailing list. I hate mailing lists as a way of reporting bugs. They are just the wrong tool. I have now found (in the obvious place (D'oh!)) the "official" way to report bugs. I think I will copy have copied the relevant parts of this thread to ticket 39663 in the CPAN RT for Perl-Dist-Strawberry . Then I may post links to that to relevant mailing lists.

Comment on Strawberry CPAN.pm wrongly overrides INC in Makefile.PL
Select or Download Code
Re: Strawberry CPAN.pm wrongly overrides INC in Makefile.PL
by jettero (Prior) on Sep 28, 2008 at 10:46 UTC
    I was going to recommend their mailing list, but I'm not actually finding any information on it. I know I've seen those guys active (arguing the merits of strawberry over active) on one of the lists I follow. (Probably perl-xs?) I'm sure they have a list somewhere. That's definitely where I'd start.

    My thinking is that you'll have to argue your way through it. It isn't a bug. They did that because they include a bunch of libs with strawberry, which is part of the reason people like that dist I believe.

    You might argue it's a bug in CPAN... It seems to be the various INC dirs (from config and makefiles) should be additive in some circumstances. So maybe it's a bug in EU::MM? I certainly couldn't say. I can think of cases were you'd want to be able to override INC and others where you'd want to add them.

    -Paul

[reply]
      I was going to recommend their mailing list, but I'm not actually finding any information on it. I know I've seen those guys active (arguing the merits of strawberry over active) on one of the lists I follow. (Probably perl-xs?) I'm sure they have a list somewhere. That's definitely where I'd start.
      Thanks. I'll address that in an update to my original node.
      It isn't a bug. They did that because they include a bunch of libs with strawberry, which is part of the reason people like that dist I believe.

      I think you are mistaken. Or more accurately you may be right in your assertion that "they did that because..." but they were in fact suffering from confused thinking when they did it.

      The directories that are being added (or rather substituted) here are not the (just) directories containing the "bunch of libs" they are the directories containing the standard include files and libraries that are part of the GCC installation.

      The Makefile invokes GCC as simply "gcc" thus assuming that the environment (at least PATH) is configured correctly to find the correct GCC installation. If you are using the GCC.EXE that's found by traversing the PATH environment variable then you should be using the headers and libraries that are found by traversing the LIB and INCLUDE environment variables.

      Ironically when Strawberry is installed it also puts C:\strawberry\perl\lib\CORE into the INCLUDE environment variable (and similarly the LIB variable). This is also wrong! The Makefile that is created by Makefile.PL does not and should not assume that these directories are listed in the environment variables. (Update: the Vanilla Perl documentation admits "LIB and INCLUDE changes are likely more than are necessary, but attempt to head off potential problems compiling external programs for use with Perl and various CPAN modules.". I still think it is wrong to include the C:\strawberry\perl libraries in the INCLUDE and LIB environment variables.) (Further update: these are to be removed in the next release.)

      You might argue it's a bug in CPAN...

      Definitely not, the setting in the CPAN/Config.pm file is explicitly there for providing arguments to be passed unchanged through to the invocation of Makefile.PL. It is impossible to fault CPAN.pm for doing so.

      That's of course assuming the thing that wrote the CPAN/Config.pm isn't considered part of the CPAN module. (Update: The file is hardwired in Perl-Dist-Strawberry.)

      It seems to be the various INC dirs (from config and makefiles) should be additive in some circumstances. So maybe it's a bug in EU::MM? I certainly couldn't say. I can think of cases were you'd want to be able to override INC and others where you'd want to add them.

      This is all true. However, for the reasons I give above, I consider it irrelevant in the current context.

[reply]
[d/l]
         ...

        Appreciated a lot that you, nobull, posted this since it could not have come at a better time for me: I just set up Strawberry on a new box and hadn’t started using it yet.

        There is no need to pass these setting. The Makefile invokes GCC as simply “gcc” thus assuming that the environment (at least PATH) is configured correctly to find the correct GCC installation. If you are using the GCC.EXE that’s found by traversing the PATH environment variable then you should be using the (standard) headers and libraries that are found by traversing the LIB and INCLUDE environment variables.

        It might not be smart to take for granted that the user’s PATH is set up correctly. Mine or yours always would be; but a lot of experience answering questions on realtime chat has demonstrated that many users do not even know what PATH is, or understand PATH and other environmental vars at all. This applies to people right here on Perlmonks everyday; I am not talking at all about some hypothetical breed far outside the possible user base of Strawberry. So a superior approach might be to set cc in the Perl Config-heavy.pl file to the fully-qualified pathname where the mingw gcc that’s shipped with Strawberry is installed. That way the right gcc is always called:

        Config_heavy.pl: cc='gcc'
                becomes       cc='C:/strawberry/c/bin/gcc'

        Strawberry’s setup program alters the MSWindows system PATH (%Path%) env var but that’s inherently fragile when something later (like a brain-damaged user or other software setup program) could come along and clobber that.

        In summation, yeah, this is not being done the right way by the current release of Strawberry 5.10. This needs to be fixed.

[reply]
[d/l]
Re: Strawberry CPAN.pm wrongly overrides INC in Makefile.PL
by adamk (Chaplain) on Sep 29, 2008 at 02:41 UTC
    To follow up from the RT ticket...

    A command line provided INC value is part of the officially supported API of ExtUtils::MakeMaker, and is known to override any INC passed to MakeMaker from the Perl code.

    This is known and intended (if admittedly somewhat confusing) behaviour.

    It is the responsibility of any and all MakeMaker Makefile.PL that make use of the INC type params to themselves check for a command line INC param, remove if from @ARGV, and integrate THEIR INC params into the one provided on the command line.
[reply]
[reply]
        Personally, I used the "I'm staying at Schwern's place and asked him" form of the documentation. So perhaps it's an unofficially-supported feature...

        One of the long-standings problems with the Makefile.PL command line invocation is that it's really an API, but nobody has formalised it or told anyone.

        There's a long-standing assumption by the CPAN clients that you can just pass in the same params to everything (which is why that CPAN/Config.pm setting exists) and a long-standing assumption by module authors that you can ask the user to provide you anything you like as a param to Makefile.PL.

        The former is actually the more-correct, since in the general case there IS no user to read your docs and type stuff into Makefile.PL. And any module that HAS to have a user type in stuff is more of less incompatible with the CPAN.

        I believe one of Schwern's "improving the CPAN" tasks was to try and properly codify the Makefile.PL "API".
[reply]
      To follow up from the RT ticket...

      adamk, I'm not quite sure how the points you raised fit into the scheme of things. From nobull's original post:

      makepl_arg => q[LIBS=-LC:\\strawberry\\c\\lib INC=-IC:\\strawberry\\c\ +\include<c>],
      I don't see how such a line of code can ever contribute anything useful. By my understanding, the MinGW compiler itself is the only thing that will ever make use of that information - and it already knows about those locations and searches them by default.

      If the information cannot "ever contribute anything useful" then I think it should be removed, as nobull has suggested.

      nobull, as regards the setting of LIB and INCLUDE environment variables (raised in the rt ticket), Strawberry definitely *used* to set those variables, though they served no purpose (as adamk indicated).

      Cheers,
      Rob
[reply]
[d/l]
        If the information cannot "ever contribute anything useful" then I thi +nk it should be removed, as nobull has suggested.
        Agreed. The problem is, however, that if I remove those values, the Strawberry build process fails.

        More effort is needed by people that actually understand GCC to help investigate exactly why that is, I suspect.
[reply]
[d/l]

Back to Seekers of Perl Wisdom


Login:
Password
remember me
What's my password?
Create A New User

Node Status
node history
Node Type: perlquestion [id://714150]
Approved by Corion
Front-paged by Corion
help
Community Ads
Chatterbox
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users
Others avoiding work at the Monastery: (6)
GrandFather
wfsp
atcroft
herveus
Eyck
gnosti
As of 2009-11-21 09:33 GMT
Sections
The Monastery Gates
Seekers of Perl Wisdom
Meditations
PerlMonks Discussion
Categorized Q&A
Tutorials
Obfuscated Code
Perl Poetry
Cool Uses for Perl
Perl News
Information
PerlMonks FAQ
Guide to the Monastery
What's New at PerlMonks
Voting/Experience System
Tutorials
Reviews
Library
Perl FAQs
Other Info Sources
Find Nodes
Nodes You Wrote
Super Search
List Nodes By Users
Newest Nodes
Recently Active Threads
Selected Best Nodes
Best Nodes
Worst Nodes
Saints in our Book
Leftovers
The St. Larry Wall Shrine
Offering Plate
Awards
Craft
Snippets Section
Code Catacombs
Quests
Editor Requests
Buy PerlMonks Gear
PerlMonks Merchandise
Planet Perl
Perlsphere
Use Perl
Perl.com
Perl 5 Wiki
Perl Jobs
Perl Mongers
Perl Directory
Perl documentation
CPAN
Random Node
Voting Booth

Future historians will find that the material characteristic of the current era is...

Aluminium
Plastic
Oil
Water
Carbon dioxide
Copper
Iron
Silicon
Salt
Uranium
Hydrogen
Other

Results (729 votes), past polls