Re: [Win32] Feature request: acknowledge $ENV{LIBRARY_PATH}

"Sisyphus" <[email protected]>
Newsgroups gmane.comp.lang.perl.modules.extutils-makemaker.devel
Message-ID <A3298A9FBEF0400592846E06B80B7A1E@desktop2>
----- Original Message ----- 
From: "Michael G Schwern" <[email protected]>
To: "Sisyphus" <[email protected]>
Cc: "makemaker" <[email protected]>
Sent: Monday, April 27, 2009 7:41 AM
Subject: Re: [Win32] Feature request: acknowledge $ENV{LIBRARY_PATH}


> Sisyphus wrote:
>> Could the attached patch (against version 6.50 of
>> ExtUtils/Liblist/Kid.pm) be applied ?

[snip]

> Alternatively, show me that ExtUtils::CBuilder does it (and tests it) and 
> I'll
> just follow their lead.

I don't know much about ExtUtils::CBuilder, though I would be surprised if 
it takes $ENV{LIBRARY_PATH} into consideration. Does it, like MakeMaker, 
insist on finding the library for itself before passing the link on to the 
rest of the build process ? If not, then setting $ENV{LIBRARY_PATH} would 
alone be sufficient, and there would not even be a need for 
ExtUtils::CBuilder to know anything about $ENV{LIBRARY_PATH}.

It's the fact that MakeMaker won't pass the link on if it can't find the 
library for itself, that's posing the problem. (I understand the reason that 
Makemaker does this - and I'm not suggesting the behaviour should change.)

Anyway, I can always amend Kid.pm in accordance with that patch for my own 
use (which is what I'll do for many, but probably not all, of my perls).

Unless it's a Win32 OS && has a LIBRARY_PATH environment variable set, that 
patch has no effect, so it's hard to see how it could possibly break 
anything. Even if the LIBRARY_PATH variable contained garbage, I don't think 
it would break anything (untested).  But, of course, I don't make any 
*guarantees*.

Cheers,
Rob
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.