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.

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.

 ...

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.

Read more... (2 kB)

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

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>],
[download]

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.
[download]

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.

Can you tell me where in any documentation it says this, as previously I must have missed it. I also have problems reported with the module I maintain and strawberry perl setting INC and no one until now on rt or in mailing lists has mentioned this "responsibility".

See http://rt.cpan.org/Ticket/Display.html?id=32811, http://rt.cpan.org//Ticket/Display.html?id=32789 and http://www.mail-archive.com/makemaker@perl.org/msg02680.html

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