Re: ExtUtils:MM_Unix v1.33 manifypods patch
On Thu, Oct 31, 2002 at 03:49:41PM +, Steve Purkis wrote: > Hi Michael & co., > > I've been working on a manifypod -related system, and have had to tweak > ExtUtils::MM_Unix subs so that: > (a) I understood what they did (is this an obfustacted perl > contest? :-) > (b) I could get my work done. > > My solution lives in a Makefile.PL, but it didn't take long to push it > back > into ExtUtils::MM_Unix and whip up a patch. Unfortunately I don't have > time to test it on any other flavour of Unix than Mac OS X 10.1.5 (with > Perl 5.8 and Gnu Make 3.79), or even to write tests for it - sorry in > advance. > > But still, I thought you might find it of some use in your quest to > clean up > MakeMaker ;-). So the patch is attached. I sort of see what you're doing here, this is just a cleanup, right? No new features introduced? If I could ask you to take another whack a this, modify your patch so that rather than using the pod2man binary it uses the Pod::Man module. [1] If nothing else it'll be a lot faster to have one process calling Pod::Man->parse_from_file multiple times than calling pod2man once for each individual POD file. [1] PS You might find these slides from the Refactoring talk useful or at least amusing. They talk specificly about the icky POD2MAN code. http://www.pobox.com/~schwern/talks/Refactoring/slides/slide020.html [1] This means 5.5.3 users will have to install Pod::Man. Oh well. [2] 5.6.1 introduced a pod2man which could do multiple conversions in one command. Unfortunately, we much be backwards compatible to 5.5.3. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One Only mindless violence can raise my spirits now!
Re: INSTALLSCRIPT doesn't have 'site', 'vendor' values?
On Saturday, November 9, 2002, at 11:36 AM, Michael G Schwern wrote: On Thu, Nov 07, 2002 at 07:54:18PM +1100, Ken Williams wrote: If I were to fix this, I think there would be a few parts to it: 1) MakeMaker should try to determine a better place to put scripts (by guessing) Should be possible using the same tricks as the other iffy variables in init_INSTALL(). Thanks, I'll have a look. 2) EU::Install should honor that It'll do that automaticly. It doesn't know anything about the INSTALL* variables, it just gets fed paths. ExtUtils::Install is really just a glorified copy command like GNU install. Oh yeah. Good. 3) Config.pm should have INSTALLSITESCRIPT and INSTALLVENDORSCRIPT entries so MM doesn't have to guess We'll still have to guess for all older versions, so no code savings there. :( RIght, I meant more to increase predictability and reduce guessing, not to actually simplify code. -Ken
Re: INSTALLSCRIPT doesn't have 'site', 'vendor' values?
On Thu, Nov 07, 2002 at 07:54:18PM +1100, Ken Williams wrote: > It sounds like the kind of thing someone's going to be using somewhere, > so it probably shouldn't get completely broken. The two likely candidates are AFS users, who routinely shuffle files around all over the place and use obscure features of MM, and module repackagers (ie. Redhat, Debian, etc...) who need to seperate out architecture dependent vs independent bits. > If I were to fix this, I think there would be a few parts to it: > > 1) MakeMaker should try to determine a better place to put scripts (by > guessing) Should be possible using the same tricks as the other iffy variables in init_INSTALL(). > 2) EU::Install should honor that It'll do that automaticly. It doesn't know anything about the INSTALL* variables, it just gets fed paths. ExtUtils::Install is really just a glorified copy command like GNU install. > 3) Config.pm should have INSTALLSITESCRIPT and INSTALLVENDORSCRIPT > entries so MM doesn't have to guess We'll still have to guess for all older versions, so no code savings there. :( > In practice, I don't think any 'hints' files (in 5.8, anyway) have > INSTALLBIN and INSTALLSCRIPT different, so it's probably pretty safe to > guess from INSTALL*BIN, I think. > > Then I have to figure out how to cooperate/repeat with Module::Build. -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One You see, in this world there's two kinds of people. Those with loaded guns, and those who dig. Dig. -- Blondie, "The Good, The Bad And The Ugly"
Re: INSTALLSCRIPT doesn't have 'site', 'vendor' values?
On Thursday, November 7, 2002, at 05:56 PM, Andreas J. Koenig wrote: On Thu, 7 Nov 2002 13:18:17 +1100, Ken Williams <[EMAIL PROTECTED]> said: Okay. I'll wait a week or so for someone like Andreas or Andy to chime in and explain why there are no other INSTALL*SCRIPT entries, and if that doesn't happen I'll assume it's an error and I'll try to fix it. Sorry, I have no answer to this one. Would it be wrong to just put scripts into INSTALL*BIN? Do we really need to make a big distinction between executable binaries and executable scripts? The reason for 'script' being separated from 'bin' was that you can share scripts between architectures but usually cannot share binaries. If people actually make use of this distiction, nobody knows. It sounds like the kind of thing someone's going to be using somewhere, so it probably shouldn't get completely broken. If I were to fix this, I think there would be a few parts to it: 1) MakeMaker should try to determine a better place to put scripts (by guessing) 2) EU::Install should honor that 3) Config.pm should have INSTALLSITESCRIPT and INSTALLVENDORSCRIPT entries so MM doesn't have to guess In practice, I don't think any 'hints' files (in 5.8, anyway) have INSTALLBIN and INSTALLSCRIPT different, so it's probably pretty safe to guess from INSTALL*BIN, I think. Then I have to figure out how to cooperate/repeat with Module::Build. -Ken
Re: All MakeMaker HTMLifying functionality is going away
On Fri, Nov 08, 2002 at 12:55:01PM -0500, Andy Dougherty wrote:
> We'd give you one if we had a clue what it should be.
Yeah, I don't expect it to be solved. Besides, the Great Convert Everything
To HTML Craze is mercifully over.
Now let's talk $Config{installyamldir}... ;)
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
"That's what Jagulars always do," said Pooh, much interested. "They call
'Help! Help!' and then when you look up they drop down on you."
Re: All MakeMaker HTMLifying functionality is going away
On Thu, 7 Nov 2002, Michael G Schwern wrote: > That was the reason it was killed. No way to know the default location for > HTML docs or when its appropriate to generate and install them. The problem > is punted back to the Config folks. If they can give us a %Config value for > it then we can use it. We'd give you one if we had a clue what it should be. Perl's INSTALL file has had the following paragraph for years now (i.e. since 5.005_57, in May 1999). =item HTML pages Currently, the standard perl installation does not do anything with HTML documentation, but that may change in the future. Further, some add-on modules may wish to install HTML documents. The html Configure variables listed above are provided if you wish to specify where such documents should be placed. The default is "none", but will likely eventually change to something useful based on user feedback. Attempts to get useful user feedback have all failed. -- Andy Dougherty [EMAIL PROTECTED]
