Re: MY Errors on compiling mod_perl
On Wednesday, April 24, 2002, at 12:08 PM, Michael G Schwern wrote:
On Wed, Apr 24, 2002 at 10:43:36AM +1000, Ken Williams wrote:
requiring ExtUtils::MakeMaker. MM is one thing. MY is just Wrong.
How is anybody supposed to know that? The docs give examples
like this:
package MY; # so that SUPER works right
sub c_o {
my $inherited = shift-SUPER::c_o(_);
$inherited =~ s/old text/new text/;
$inherited;
}
So one might reasonably expect that 'MY' is a valid subclass name that
will get you access to the MakeMaker methods.
...you may define private subroutines in the Makefile.PL
^^
Docs aren't perfect, but I can't possibly see how the
Overriding MakeMaker
Methods docs gives license to do:
my $MM = bless {} = 'MY';
...
my($extralibs, $bsloadlibs, $ldloadlibs, $ld_run_path) =
$MM-ext(join ' ', -L$lpath, $libperl, potential_libs);
You don't just bless hashes directly into classes that might
vaguely exist
without some knowledge that you're doing naughty things.
That makes it sound so seedy. But there's no difference between
doing that and doing MY-ext(...), which doesn't sound as seedy
anymore.
The point is that the docs say that MY is a class that inherits
from ExtUtils::MakeMaker (or more precisely ExtUtils::MM_*), but
it doesn't say under what conditions, so one might reasonably
assume that it happens when you load ExtUtils::MakeMaker. This
was true (more or less) for a long time, then not true for a
while, and now it's true again.
That code was likely written years and years ago anyway.
Yes, you'll certainly get no argument from me that it Should Be Changed.
-Ken
Re: MY Errors on compiling mod_perl
On Wed, Apr 24, 2002 at 04:50:34PM +1000, Ken Williams wrote: That makes it sound so seedy. But there's no difference between doing that and doing MY-ext(...), which doesn't sound as seedy anymore. The point is that the docs say that MY is a class that inherits from ExtUtils::MakeMaker (or more precisely ExtUtils::MM_*), but it doesn't say under what conditions, so one might reasonably assume that it happens when you load ExtUtils::MakeMaker. This was true (more or less) for a long time, then not true for a while, and now it's true again. Ok. Doc patch coming along nicely then? ;) -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Realize this, sweetheart, I'm squeezing my poodle.
Makefile.PL's in subdirs affect each other and their parent
Currently all Makefile.PL's are runinng inside the same package unless
declared explicitly by each Makefile.PL. This leads to problems.
For example function redefinition errors under:
use strict;
use warnings FATAL = 'all';
e.g if the parent dir's Makefile.PL and the child both define:
sub clean_files {
return [@scripts];
}
redefine warning will kill the makemaker.
This can be worked around as:
use strict;
use warnings FATAL = 'all';
no warnings 'redefine';
Or declaring a package in each Makefile.PL.
But ideally MakeMaker should run child Makefile.PL's in a dedicated
package created on the fly by MM (e.g. based on the path):
eval package Makemaker::Root::$sub_dir_path; $slurped_file_content; 1;;
Otherwise there is the problem that i've mentioned here, and the child
Makefile.PL's can inadvertently mess up each others global variables and
what not.
What do you think? If this works for Apache::Registry (running any
script so it won't affect any other script running by the same
interpreter) it will probably work for MM as well.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Makefile.PL's in subdirs affect each other and their parent
On Thu, Apr 25, 2002 at 01:09:06AM +0800, Stas Bekman wrote:
Currently all Makefile.PL's are runinng inside the same package unless
declared explicitly by each Makefile.PL. This leads to problems.
For example function redefinition errors under:
use strict;
use warnings FATAL = 'all';
e.g if the parent dir's Makefile.PL and the child both define:
sub clean_files {
return [@scripts];
}
redefine warning will kill the makemaker.
This can be worked around as:
use strict;
use warnings FATAL = 'all';
no warnings 'redefine';
Or declaring a package in each Makefile.PL.
But ideally MakeMaker should run child Makefile.PL's in a dedicated
package created on the fly by MM (e.g. based on the path):
I'd like to do that, but I can't. For backwards compatibility reasons
Makefile.PL's must be run in package main. It changed accidentally in
5.48_01 and it broke several modules.
It does, unfortunately, shatter the illusion that each Makefile.PL is it's
own thing. You're welcome to play with ExtUtils::MakeMaker-eval_in_x() to
throw up more smoke and mirrors, but please make sure it will build PDL and
Wx.
Hmm... how was your Makefile.PL setup working before with 5.6.1's MakeMaker?
It should have blown up, or at least emitted a warning, there as well.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
turds slide easily
spooge the paste into my crack
poop falls free no more
-- Schwern
Re: Makefile.PL's in subdirs affect each other and their parent
Michael G Schwern wrote:
On Thu, Apr 25, 2002 at 01:09:06AM +0800, Stas Bekman wrote:
Currently all Makefile.PL's are runinng inside the same package unless
declared explicitly by each Makefile.PL. This leads to problems.
For example function redefinition errors under:
use strict;
use warnings FATAL = 'all';
e.g if the parent dir's Makefile.PL and the child both define:
sub clean_files {
return [@scripts];
}
redefine warning will kill the makemaker.
This can be worked around as:
use strict;
use warnings FATAL = 'all';
no warnings 'redefine';
Or declaring a package in each Makefile.PL.
But ideally MakeMaker should run child Makefile.PL's in a dedicated
package created on the fly by MM (e.g. based on the path):
I'd like to do that, but I can't. For backwards compatibility reasons
Makefile.PL's must be run in package main. It changed accidentally in
5.48_01 and it broke several modules.
:(
It does, unfortunately, shatter the illusion that each Makefile.PL is it's
own thing. You're welcome to play with ExtUtils::MakeMaker-eval_in_x() to
throw up more smoke and mirrors, but please make sure it will build PDL and
Wx.
What about adding a new flag? e.g. if the main Makefile.PL says:
WriteMakefile(
PrivateCompartment = 1,
...
)
then it'll provide one and all children will inherit it unless they
explicitly override it?
That actually sounds like a good idea. Some projects may want to have
their all Makefiles to share main:: others will want these to be
separate. This will give more control to the developers.
Hmm... how was your Makefile.PL setup working before with 5.6.1's MakeMaker?
It should have blown up, or at least emitted a warning, there as well.
It's a new setup, in mod_perl 2.0 everything is trying to run under
use strict;
use warnings FATAL = 'all';
So all warnings will be fixed before they even have a chance to be
introduced.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Makefile.PL's in subdirs affect each other and their parent
On Thursday, April 25, 2002, at 01:45 PM, Stas Bekman wrote: What about adding a new flag? e.g. if the main Makefile.PL says: WriteMakefile( PrivateCompartment = 1, ... ) then it'll provide one and all children will inherit it unless they explicitly override it? It's difficult to add new flags to MakeMaker, because you have to ensure that all the people installing your module have a version of MakeMaker that supports it. Perhaps difficult isn't the right word - more like futile. If you don't mind putting a MakeMaker dependency in the distribution, though, it can be done. Really, it would be nice to have separate build_dependency items, like a real package manager. Stas, for your problem, a really ugly but workable solution might be to fork the main process in each of the subdirs' Makefile.PL's, oder? -Ken
