Then let me propose (i.e. throw up the balloon and duck while everyone
shoots at it).
Then how about a perllib.db. Pre-digested search paths. What %INC would
look like if everything and the kitchen sink were loaded. No parsing,
nothing but straight forward lookup code.
If not found, or an entry not found fall back.
Decision of searching in the installation tree if not found in the db
is debatable. But I would 'trust' the perllib.db. Otherwise there is
an installation problem.
Special entries could be made for finding site-lib, versioning.
<chaim>
>>>>> "SC" == Simon Cozens <[EMAIL PROTECTED]> writes:
SC> On Fri, Aug 04, 2000 at 09:13:44AM -0400, Chaim Frenkel wrote:
>> Well, the issue is how much time is spent opening directories and checking
>> for entries. Also on an NFS mounted file system, the directory has to be
>> re-requested.
SC> It may take just as long to parse the kpathsea configs, grovel through the
SC> lsr file and locate the thing you need. I'd have to benchmark it to be sure.
>> Actually, thinking about it. This may make automatic @INC adjustments.
>> All the core needs to find is the ls-R, that would give it what to search.
SC> Nope. kpathsea needs various config stuff to get it bootstrapped.
SC> It's an idea, and a reasonably sensible one, but I'm really not sure it's
SC> a win.
--
Chaim Frenkel Nonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
