Beefy Boxes and Bandwidth Generously Provided by pair Networks DiBona
Do you know where your variables are?
 
PerlMonks  

Re: Strawberry CPAN.pm wrongly overrides INC in Makefile.PL

by adamk (Chaplain)
on Sep 29, 2008 at 02:41 UTC ( #714244=note: print w/ replies, xml ) Need Help??


in reply to Strawberry CPAN.pm wrongly overrides INC in Makefile.PL

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.


Comment on Re: Strawberry CPAN.pm wrongly overrides INC in Makefile.PL
Re^2: Strawberry CPAN.pm wrongly overrides INC in Makefile.PL
by mje (Deacon) on Sep 29, 2008 at 08:15 UTC
      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".
        Anonymous Monk said:
        long-standing assumption by module authors that you can ask the user to provide you anything you like as a param to Makefile.PL

        I have not made that assumption. I have gone out of my way to make my modules work without FAILs from cpan-testers, via cpan shell, from the command line and the module in question:

        • uses prompt which does not prompt when doing automated smoking like cpan-testers do and fall back to a decent default.
        • goes out of its way to ensure cpan knows what the requirements are - setting build_requires, configure_requires in META (although it would seem few people have a cpan that understands these yet). They set PREREQ_PM in ExtUtils::MakeMaker. All so cpan knows what the dependencies are and automated smokers don't baulk and FAIL it.
        • instead of asking whether DBI is installed and where the DBI header file can be found they use a method supplied with DBI to return the header file name and location. They then set this into INC but this is where it all goes wrong in strawberry perl and it also causes a major problem needing to ensure DBI is present before calling a method in DBI but having to do this after PREREQ_PM is acted on.
        • defaults to the most common configuration for the platform you are building on but supports overrides for anyone wanting anything not so usual.
        • understands that for some people they may be installing the module before having installed an ODBC driver and the tests don't baulk on this.

        Between trying to avoid FAIL reports via cpan-testers, keeping up with non-compatible changes in ExtUtils::MakeMaker and supporting distributions that work differently (like strawberry perl) I'm guessing some module authors are living in a world of pain and certainly I seem to be spending more time tweaking things back and forth in the installations instead of adding all those requested features the users of the module want.

        All I want in this case is to add a path to INC (without it my module will not even build - it is XS and needs DBI header files). It would appear for the current version of ExtUtils::MakeMaker and strawberry perl the only automatic thing I can do is delete INC from ARGV which seems a little drastic. The user on the other hand can either a) install manually b) edit makepl_arg in cpan c) edit Makefile after generation. For now I'm looking for INC in ARGV, outputting a message saying it will not work with advice on fixing it and, oh yes, remembering to exit 0 without creating a Makefile or cpan testers will issue a FAIL.

Re^2: Strawberry CPAN.pm wrongly overrides INC in Makefile.PL
by syphilis (Canon) on Sep 29, 2008 at 09:11 UTC
    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
      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.
        The problem is, however, that if I remove those values, the Strawberry build process fails

        Interesting ... you've come across a situation where those values *do* contribute something useful. What error messages do you get when you remove those values ?

        More effort is needed by people that actually understand GCC to help investigate exactly why that is, I suspect

        I don't think it would have much to do with gcc. But then if, in the first place, I was wrong about the potential usefulness of the code in question .....

        Cheers,
        Rob

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://714244]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others surveying the Monastery: (5)
As of 2014-04-20 10:04 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (485 votes), past polls