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

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

Comment on Re^2: Strawberry CPAN.pm wrongly overrides INC in Makefile.PL Download Code

Replies are listed 'Best First'.
Re^3: Strawberry CPAN.pm wrongly overrides INC in Makefile.PL by Anonymous Monk on Sep 30, 2008 at 07:54 UTC
`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.	[reply] [d/l]
Re^4: Strawberry CPAN.pm wrongly overrides INC in Makefile.PL by syphilis (Archbishop) on Sep 30, 2008 at 08:22 UTC
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	[reply]