ExtUtils::Install

[kj]

I've been reading the source for ExtUtils/Install.pm, and it is a
disgrace. Code like that is what gives Perl a bad name. I just
can't believe that this dreck is part of the standard library...

kj

 

[Ben Morrow]

I've been reading the source for ExtUtils/Install.pm, and it is a
disgrace. Code like that is what gives Perl a bad name. I just
can't believe that this dreck is part of the standard library...

Ummm... what exactly is wrong with it?

Ben

 

[Tassilo v. Parseval]

Also sprach kj:

I've been reading the source for ExtUtils/Install.pm, and it is a
disgrace. Code like that is what gives Perl a bad name. I just
can't believe that this dreck is part of the standard library...

Please elaborate a little. What is so wrong with it? To me it looks
rather unconspicuous.

Also, have you read the AUTHOR section? It makes clear that this is
legacy code which offen suffers from stylistic (and other) problems. But
considering that I think the code is actually quite good. It is well
documented, has sensible variable names etc. There are worse examples in
a Perl source distribution.

Tassilo

 

[James Willmore]

I've been reading the source for ExtUtils/Install.pm, and it is a
disgrace. Code like that is what gives Perl a bad name. I just
can't believe that this dreck is part of the standard library...

My truck is really old and is in such poor shape ... I can't believe the
Commonwealth of Pennsylvania actually allows it to be on the road ;-)

If you're more specific, I can be more specific

--
Jim

Copyright notice: all code written by the author in this post is
released under the GPL. http://www.gnu.org/licenses/gpl.txt
for more information.

a fortune quote ...
"I'm willing to sacrifice anything for this cause, even other
people's lives"

 

[kj]

OK, the latest example I've been dealing with: the policy for
permissions when copying files from the build to the install
directories is hard-coded and embedded in a huge sub. The only
way to override it it is to cut-and-paste the whole goddam thing
into your code and hope that it doesn't use file-scoped lexicals...
If programming required a license, that sort of crap should be
enough to have it revoked... Yeah, I know, one can always think
of worse, but that's true of any crime...

kj

 

[Tassilo v. Parseval]

Also sprach kj:

OK, the latest example I've been dealing with: the policy for
permissions when copying files from the build to the install
directories is hard-coded and embedded in a huge sub. The only
way to override it it is to cut-and-paste the whole goddam thing
into your code and hope that it doesn't use file-scoped lexicals...
If programming required a license, that sort of crap should be
enough to have it revoked... Yeah, I know, one can always think
of worse, but that's true of any crime...

Maybe you just missed this piece from the DESCRIPTION in the PODs:

Both install() and uninstall() are specific to the way
ExtUtils::MakeMaker handles the installation and deinstallation of
perl modules. They are not designed as general purpose tools.

If you don't want to do it the EU::MakeMaker way, then you should not be
trying to use this module.

As a side note: You are beating dead camels here. Michael G Schwern
doesn't get weary of emphasizing that EU::MakeMaker is seriously flawed
and that instead Module::Build should be used.

Tassilo

 

[Rafael Garcia-Suarez]

kj wrote in comp.lang.perl.misc :

OK, the latest example I've been dealing with: the policy for
permissions when copying files from the build to the install
directories is hard-coded and embedded in a huge sub. The only
way to override it it is to cut-and-paste the whole goddam thing
into your code and hope that it doesn't use file-scoped lexicals...
If programming required a license, that sort of crap should be
enough to have it revoked... Yeah, I know, one can always think
of worse, but that's true of any crime...

Rewrite it. Send a patch. Do something constructive. Don't rely
on others doing all the work for free.