Skip Menu |

This queue is for tickets about the ExtUtils-MakeMaker CPAN distribution.

Report information
The Basics
Id: 1991
Status: rejected
Priority: 0/
Queue: ExtUtils-MakeMaker
People
Owner: Nobody in particular
Requestors: comdog [...] panix.com
Cc:
AdminCc:
Bug Information
Severity: Normal
Broken in: 6.05
Fixed in: (no value)

History Show all quoted text
  Mon Jan 27 02:39:59 2003 bdfoy [...] cpan.org - Ticket created
Subject: eval_in_x does not pass Makefile.PL arguments
With something in WriteMakefile's DIR key, MakeMaker runs the Makefile.PL files for the directories in the anonymous array value of DIR. However, it does not pass through the arguments (e.g. PREFIX) to those Makefile.PLs. I overrode this in my Makefile.PL sub ExtUtils::MakeMaker::eval_in_x { my( $self, $dir) = @_; chdir $dir or Carp::carp("Couldn't change to directory $dir: $!"); system("perl ./Makefile.PL @ARGV"); } I did not see anything in the docs to suggest any reason why @ARGV should not be passed through to the other Makefile.PLs, and this is the expected behaviour. The preamble of the other Makefile.PLs claim that the values were passed, even though they weren't.
  Sun Mar 30 20:48:31 2003 mschwern [...] cpan.org - Status changed from 'new' to 'stalled'
  Sun Mar 30 20:48:31 2003 mschwern [...] cpan.org - Correspondence added
[BDFOY - Mon Jan 27 02:39:59 2003]: Show quoted text
> With something in WriteMakefile's DIR key, MakeMaker runs the > Makefile.PL files for the directories in the anonymous array value > of DIR. However, it does not pass through the arguments (e.g. > PREFIX) to those Makefile.PLs.
@ARGV is passed but its deliberately ignored for an unknown reason. Since I don't understand the reason, I don't understand the internal mechanics of multiple Makefile.PLs in MakeMaker, and it appears to always have worked this way I'm inclined to say its a historical feature and leave it as it is unless someone can explain why they're ignored or at least point to where/when the ignorance was added. Show quoted text
> I overrode this in my Makefile.PL
The code below subtly changes the mechanics. All sub Makefile.PLs are deliberately (?) called in the same process so they can share certain values. Whether or not this is a good idea or not is up for grabs, but you should know you're changing the behavior. The actual logic for ignoring @ARGV is in ExtUtils::MakeMaker::new(). Look for parse_args(). Show quoted text
> sub ExtUtils::MakeMaker::eval_in_x > { > my( $self, $dir) = @_; > chdir $dir or Carp::carp("Couldn't change to directory $dir: $!"); > > system("perl ./Makefile.PL @ARGV"); > } > > I did not see anything in the docs to suggest any reason why @ARGV > should not be passed through to the other Makefile.PLs, and this is > the expected behaviour. The preamble of the other Makefile.PLs > claim that the values were passed, even though they weren't.
  Mon Jul 28 19:15:27 2014 rt-cpan [...] trout.me.uk - Correspondence added
Obviously broken original code and no updated patch since schwern's request in 2003; rejecting
  Mon Jul 28 19:15:28 2014 The RT System itself - Status changed from 'stalled' to 'open'
  Mon Jul 28 19:15:29 2014 rt-cpan [...] trout.me.uk - Status changed from 'open' to 'rejected'
  Mon Jul 28 19:16:24 2014 The RT System itself - Status changed from 'rejected' to 'open'
  Mon Jul 28 19:51:44 2014 rt-cpan [...] trout.me.uk - Correspondence added
On Mon Jul 28 19:15:27 2014, MSTROUT wrote: Show quoted text
> Obviously broken original code and no updated patch since schwern's > request in 2003; rejecting
wrf, RT. re-rejecting.
  Mon Jul 28 19:51:47 2014 rt-cpan [...] trout.me.uk - Status changed from 'open' to 'rejected'