I wasn't looking to change the source code -- or I don't understand the purpose
of the grep?
But looking at perlrun option to use a run-time config file might be the trick..
I.e. rebuild perl once to use a site-config, and that looks like it might to the trick...
Thanks!
| [reply] |
I wasn't looking to change the source code -- or I don't understand the purpose of the grep?
The purpose of grepping the source is to find what you're looking for, info on PREFIX ... as you can see from the results the perlfaq contains info on it among other places
| [reply] |
Ah, I see, but in this case, the search got back 100 results. 1 of those, you
tell me, has pertinent information. I think I mentioned at the end of my intial post on this -- "things are always much easier to find when you know where they are". In such situations, what is clearly apparent to one can be completely opaque to another.
Having read the FAQ, though it doesn't apply to what I wanted either -- it involves
changing where things install by changing params to MakeMaker, which doesn't
help when you are doing cpan -i modname.
Most modules don't hard-code paths in their scripts, so the fact that this one (spamassassin) did, threw me a bit. It drew it's defaults out of the fields in
the perl was compiled with -- so I was trying to figure out if there was a way
to change those fields after the fact, or a shim-layer to return 'corrected values' if perl was moved.
The Dist::Portable module looks to be the most straightforward, but building in the 'site.pl' option that allows arbitrary code to be run on startup might allow more convenience to configure features common in my system's scripts.
If I wanted to get fancy, I could even implement a shim-manager like MS's compatibility agent that applies the appropriate shims/binary (script) to make
it compat with the current perl. Just some random musing on possibilities...
Very cool...and thanks...
| [reply] |