Re: ExtUtils::MakeMaker help - PL_FILES

[Alberto Simões]

Heyas

Michael G Schwern wrote:
 I am using PL_FILES = { foo/bar.PL = foo/bar }, and foo/bar.PL uses a
 lateral file (say, ugh.txt) on the distro to build the script foo/bar.

 How can I force the dependency, so make knows it should rebuild foo/bar
 when I change ugh.txt?
 You should be able to add the dep in a postamble.
 
 sub MY::postamble {
 return qq[
 
 foo/bar.PL :: ugh.txt
 $(NOOP)
 ];
 }
 

Unfortunately it is not working. Tried also foo/bar :: ugh.txt but
foo/bar is not rebuilt when I change ugh.txt

Oh well :)
Thanks
Alberto
-- 
Alberto Simões

Re: ExtUtils::MakeMaker help - PL_FILES

[Michael G Schwern]

Alberto Simões wrote:

Heyas

Michael G Schwern wrote:

I am using PL_FILES = { foo/bar.PL = foo/bar }, and foo/bar.PL uses a
lateral file (say, ugh.txt) on the distro to build the script foo/bar.

How can I force the dependency, so make knows it should rebuild foo/bar
when I change ugh.txt?

You should be able to add the dep in a postamble.

sub MY::postamble {
return qq[

foo/bar.PL :: ugh.txt
$(NOOP)
];
}



Unfortunately it is not working. Tried also foo/bar :: ugh.txt but
foo/bar is not rebuilt when I change ugh.txt


Ahh, it needs to be added as a dependency on the original statement.  That is:

foo/bar :: foo/bar.PL pm_to_blib
$(PERLRUNINST) foo/bar.PL foo/bar

has to be changed to

foo/bar :: foo/bar.PL pm_to_blib ugh.txt
$(PERLRUNINST) foo/bar.PL foo/bar

Unfortunately the only way to do this is to override processPL() and do a s/// 
on the output of $self-SUPER::processPL.


package MY;
sub processPL {
my $self = shift;

my $make = $self-SUPER::processPL(@_);
$make =~ s{pm_to_blib}{pm_to_blib ugh.txt};

return $make;
}

This simple s/// will break if you have more than one PL file.  Repairing it 
is left as an exercise for the reader.



--
E: Would you want to maintain a 5000 line Perl program?
d: Why would you write a 5000 line program?

Re: ExtUtils::MakeMaker help - PL_FILES

[Michael G Schwern]

Alberto Simões wrote:

Hello,

I am using PL_FILES = { foo/bar.PL = foo/bar }, and foo/bar.PL uses a
lateral file (say, ugh.txt) on the distro to build the script foo/bar.

How can I force the dependency, so make knows it should rebuild foo/bar
when I change ugh.txt?

At the moment I need to make clean, perl Mkefile.PL, make...


You should be able to add the dep in a postamble.

sub MY::postamble {
return qq[

foo/bar.PL :: ugh.txt
$(NOOP)
];
}


--
10. Not allowed to purchase anyone's soul on government time.
-- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
   http://skippyslist.com/list/

Re: ExtUtils::MakeMaker help - PL_FILES

[brian d foy]

In article 4a93f5ae.6000...@alfarrabio.di.uminho.pt, Alberto Simões
al...@alfarrabio.di.uminho.pt wrote:


 I am using PL_FILES = { foo/bar.PL = foo/bar }, and foo/bar.PL uses a
 lateral file (say, ugh.txt) on the distro to build the script foo/bar.
 
 How can I force the dependency, so make knows it should rebuild foo/bar
 when I change ugh.txt?

I don't know a way that you can do this from Makemaker.

Have you tried creating the dependency in the Makefile itself? You
insert a bit of code into the Makefile through MY::postamble, and you
make it run the same thing that processes the PL_FILES.

That's certainly ugly. When you get down to this level of detail, it's
sometimes easier to use Module::Build unless you have some other
contraint that forces you to use MakeMaker.

Re: ExtUtils::MakeMaker help - PL_FILES

[Alberto Simões]

Hey

brian d foy wrote:
 In article 4a93f5ae.6000...@alfarrabio.di.uminho.pt, Alberto Simões
 al...@alfarrabio.di.uminho.pt wrote:
 
 
 I am using PL_FILES = { foo/bar.PL = foo/bar }, and foo/bar.PL uses a
 lateral file (say, ugh.txt) on the distro to build the script foo/bar.

 How can I force the dependency, so make knows it should rebuild foo/bar
 when I change ugh.txt?
 
 I don't know a way that you can do this from Makemaker.
 
 Have you tried creating the dependency in the Makefile itself? You
 insert a bit of code into the Makefile through MY::postamble, and you
 make it run the same thing that processes the PL_FILES.

Yes, that's an option.
But
 That's certainly ugly.
:)

 When you get down to this level of detail, it's
 sometimes easier to use Module::Build unless you have some other
 contraint that forces you to use MakeMaker.

At the moment my only constrain is take time to look into M::B :)

Thanks
ambs
-- 
Alberto Simões - Departamento de Informática - Universidade do Minho
 Campus de Gualtar - 4710-057 Braga - Portugal

ExtUtils::MakeMaker help - PL_FILES

[Alberto Simões]

Hello,

I am using PL_FILES = { foo/bar.PL = foo/bar }, and foo/bar.PL uses a
lateral file (say, ugh.txt) on the distro to build the script foo/bar.

How can I force the dependency, so make knows it should rebuild foo/bar
when I change ugh.txt?

At the moment I need to make clean, perl Mkefile.PL, make...

Thanks


-- 
Alberto Simões - Departamento de Informática - Universidade do Minho
 Campus de Gualtar - 4710-057 Braga - Portugal

Re: [EMAIL PROTECTED] VMS fixes FIRST_MAKEFILE, PL_FILES

[John E. Malmberg]

John E. Malmberg wrote:
These are the patches needed for the tests FIRST_MAKEFILE.t and 
PL_FILES.t to pass on VMS.


I have seen no response to the patch in the message I am replying to, is 
there a problem with it?


There are also two typo fixes in MM_Unix.pm and MM_VMS.pm that are 
already in [EMAIL PROTECTED] but not in the 6.30_01 tarball.




In lib/ExtUtils/MM_Unix.pm, $^X is a complete specification on VMS, and 
adding $Config{exe_ext} to it will always produce the wrong file name.


The VMS version of the Perl test harness runs with Perl having the name 
Perl..  This bug has not caused tests to fail because find_perl was 
able to find another copy of Perl in it's search.


To clarify, even though MM_Unix is starting out with an incorrect 
filename for the Perl on VMS that it is running under, the file_perl() 
routine is finding a Perl to make it work, which is why this bug has not 
been visible.


Because directories can not be combined in VMS the way they can be on 
UNIX macros need to be expanded/eliminated in sub process_PL().



In lib/ExtUtils/MM_VMS.pm, setup the $self-{MAKEFILE} to default to the 
FIRST_MAKEFILE parameter if present, else to 'descrip.mms'.


'$(FIRST_MAKEFILE)_OLD' needs to have it's macros expanded/eliminated so 
that it is parsed correctly on VMS before it is stored in 
$self-{MAKEFILE_OLD}


Then, if the filenames did not already contain a '.' to delimit a file 
type from the filename, then VMS needs a tailing . to indicate that 
there is a blank type instead of the default .MMS in this case.



In t/FIRST_MAKEFILE.t, for using a makefile name with out an .type on 
VMS, a trailing dot is generated as above, so the test needs to be 
modified to not fail when a trailing dot has been added to the filename.



I still need to come up with a solution to an issue with t/basic.t. This 
test fails on VMS if the logical name BIN is defined and the DECC 
feature DECC$UNIX_PATH_BEFORE_LOGNAME is not not also enabled.


What I missed writing here, is that the GNV product when installed by 
default creates the logical name BIN that causes the conflict.



And a correction below:

The test t/Installed.t will also fail on VMS if the logical name foo is
defined before it runs.  One of the other test scripts will leave this
logical name behind if it is run with out using the test harness.

-John
[EMAIL PROTECTED]
Personal Opinion Only

Re: More PL_FILES issues

[Michael G Schwern]

On Thu, Apr 28, 2005 at 08:36:10AM -0700, Mike Castle wrote:
 On Wed, Apr 27, 2005 at 01:20:01PM -0700, Michael G Schwern wrote:
  Anyhow, try it out.  If it turns out its going to break a bunch of things
  I'll probably just change it back to running PL files after pm_to_blib to
  minimize boat rocking.
 
 FWIW, it turns out the patch breaks Object-Transaction-1.01.  Granted, that
 package is over 2 years old, but it's at least one datapoint.

Ok, I've recanted on this point.  6.29 will have the old behavior restored.


-- 
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
ROCKS FALL! EVERYONE DIES!
http://www.somethingpositive.net/sp05032002.shtml

Re: More PL_FILES issues

[Nick Ing-Simmons]

Michael G Schwern [EMAIL PROTECTED] writes:

2)  PL files are processed *before* pm_to_blib is run.

Anything you create will be considered for copying into blib.  BUT this
means you cannot rely on having the uninstalled module in your path.

I think Tk was assuming that, I know something I wrote does...

Re: More PL_FILES issues

[Michael G Schwern]

On Thu, May 05, 2005 at 06:35:19PM +0100, Nick Ing-Simmons wrote:
 Michael G Schwern [EMAIL PROTECTED] writes:
 
 2)  PL files are processed *before* pm_to_blib is run.
 
 Anything you create will be considered for copying into blib.  BUT this
 means you cannot rely on having the uninstalled module in your path.
 
 I think Tk was assuming that, I know something I wrote does...

Yeah.  I think this change is going to wind up being reverted.


-- 
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
Just call me 'Moron Sugar'.
http://www.somethingpositive.net/sp05182002.shtml

Re: More PL_FILES issues

[Mike Castle]

On Wed, Apr 27, 2005 at 01:20:01PM -0700, Michael G Schwern wrote:
 On Wed, Apr 27, 2005 at 12:25:11PM -0700, Mike Castle wrote:
  It looks to me like PL_FILES are being ran AFTER pm_to_blib:
 
 Yeah, there's nothing explicitly stating that PL files should be
 processed before pm_to_blib.  The attached patch does it.  However it 
 changes pm_to_blib from a : to a :: which I'm pretty sure is going to break 
 a bunch of existing MakeMaker hacks.  cpansearch is down so I can't check 
 for sure.

Ok... that makes the build process work as expected.  Still fails, but
that's because of the new semantics.  :-

Btw, for a fun MM hack that's broken, try to build xmltv sometime with the
latest EU:MM.  It fails miserably.  I've not even bothered to try to figure
that one out.

http://prdownloads.sourceforge.net/xmltv/xmltv-0.5.39.tar.bz2?download

Anyway, since the PL_FILES have changed from PERLRUNINST to PERLRUN, what's
the recommended process for applications that expected PERLRUNINST?

Add something like:

use lib lib;

at the top of the script?  (seems to work for IP-Country)

If so, perhaps this could be documented in the PL_FILES section?

mrc

Re: More PL_FILES issues

[Mike Castle]

On Wed, Apr 27, 2005 at 01:20:01PM -0700, Michael G Schwern wrote:
 Anyhow, try it out.  If it turns out its going to break a bunch of things
 I'll probably just change it back to running PL files after pm_to_blib to
 minimize boat rocking.

FWIW, it turns out the patch breaks Object-Transaction-1.01.  Granted, that
package is over 2 years old, but it's at least one datapoint.

mrc

Re: More PL_FILES issues

[Michael G Schwern]

On Wed, Apr 27, 2005 at 12:25:11PM -0700, Mike Castle wrote:
 It looks to me like PL_FILES are being ran AFTER pm_to_blib:

Yeah, there's nothing explicitly stating that PL files should be
processed before pm_to_blib.  The attached patch does it.  However it 
changes pm_to_blib from a : to a :: which I'm pretty sure is going to break 
a bunch of existing MakeMaker hacks.  cpansearch is down so I can't check 
for sure.

Anyhow, try it out.  If it turns out its going to break a bunch of things
I'll probably just change it back to running PL files after pm_to_blib to
minimize boat rocking.

=== lib/ExtUtils/MM_Unix.pm
==
--- lib/ExtUtils/MM_Unix.pm  (revision 4482)
+++ lib/ExtUtils/MM_Unix.pm  (local)
@@ -2841,7 +2841,7 @@
 my $self = shift;
 my($autodir) = $self-catdir('$(INST_LIB)','auto');
 my $r = q{
-pm_to_blib : $(TO_INST_PM)
+pm_to_blib :: $(TO_INST_PM)
 };
 
 my $pm_to_blib = $self-oneliner(CODE, ['-MExtUtils::Install']);
@@ -3048,7 +3048,7 @@
 
 $m .= sprintf 'MAKE_FRAG', ($target) x 2, ($plfile) x 2, $target;
 
-all :: %s
+pm_to_blib :: %s
$(NOECHO) $(NOOP)
 
 %s :: %s

Re: More PL_FILES issues

[Michael G Schwern]

On Wed, Apr 27, 2005 at 01:52:50PM -0700, Mike Castle wrote:
 Btw, for a fun MM hack that's broken, try to build xmltv sometime with the
 latest EU:MM.  It fails miserably.  I've not even bothered to try to figure
 that one out.
 
 http://prdownloads.sourceforge.net/xmltv/xmltv-0.5.39.tar.bz2?download

Guh, that thing overrides so much its hopeless.


 Anyway, since the PL_FILES have changed from PERLRUNINST to PERLRUN, what's
 the recommended process for applications that expected PERLRUNINST?

Haven't decided yet if this change is going to stand or not.  Have to
look through how PL_FILES is being used once cpansearch is up.

More PL_FILES issues

[Mike Castle]

It appears that 6.28 is still having some PL_FILES issues.

In particular, IP-Country 2.17 and 2.18 both have issues (only versions I
have access to).

What I'm seeing is this:

cp lib/IP/Country/Fast/ip.gif blib/lib/IP/Country/Fast/ip.gif
/usr/bin/perl bin/ip2cc.PL bin/ip2cc
Can't locate IP/Country.pm in @INC (@INC contains:
/usr/lib/perl5/5.8.6/i386-linux-thread-multi /usr/lib/perl5/5.8.6
/usr/lib/perl5/site_perl/5.8.6/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.6 /usr/lib/perl5/site_perl .) at bin/ip2cc.PL
line 3.


The root cause appears to be this:

bin/ip2cc :: bin/ip2cc.PL 
$(PERLRUN) bin/ip2cc.PL bin/ip2cc


If I change PERLRUN to PERLRUNINST (like it used to be in 6.17), it works.

If you test this, make sure you don't have it installed, otherwise it picks
up the installed versions of the files, and it looks like it works.

mrc

Re: More PL_FILES issues

[Michael G Schwern]

On Mon, Apr 25, 2005 at 11:37:00PM -0700, Mike Castle wrote:
 The root cause appears to be this:
 
 bin/ip2cc :: bin/ip2cc.PL 
 $(PERLRUN) bin/ip2cc.PL bin/ip2cc
 
 
 If I change PERLRUN to PERLRUNINST (like it used to be in 6.17), it works.
 
 If you test this, make sure you don't have it installed, otherwise it picks
 up the installed versions of the files, and it looks like it works.

Yes, that change was deliberate. 


r2332 | schwern | 2005-03-15 01:24:44 -0800 (Tue, 15 Mar 2005) | 4 lines

 [EMAIL PROTECTED]:  schwern | 2005-03-15 01:24:56 -0800
 - Fixed a circular dependency on processed PL files introduced as part
   of RT 6460 in 6.25_02.



There is essentially two mutually contradicting ways it could work.

1)  PL files are processed *after* pm_to_blib is run.

If this happens then the .PL file can get at the module being installed.
BUT this means that you can't generate something in lib/ and expect it to
be copied into blib/lib/.  ie. You can't generate a .pm file unless you
target blib/lib directly which is undesirable.


2)  PL files are processed *before* pm_to_blib is run.

Anything you create will be considered for copying into blib.  BUT this
means you cannot rely on having the uninstalled module in your path.


I have opted for #2 as it seems more important and natural to be able to
generate any file and MakeMaker treat it as if it was there all along.

I've made a small clarification to the PL_FILES docs about this.

Re: PL_FILES

[Michael G Schwern]

On Sun, Feb 13, 2005 at 03:52:55AM +, Sisyphus wrote:
 # --- MakeMaker processPL section:
 
 all :: Core.xs
 $(NOECHO) $(NOOP)
 
 Core.xs :: Core.xs.PL
 $(PERLRUNINST) Core.xs.PL Core.xs

*snip*

 Afaict, Core.xs.PL is not being run - no warnings, no error messages, no 
 mention of 'Core.xs.PL' - it is just apparently being ignored.
 'dmake' runs until it errors trying to link to Core.obj - which doesn't 
 exist. I'm assuming that Core.obj doesn't exist simply because Core.xs 
 didn't get generated in the first place. (Though with 'nmake' I get the 
 impression that Core.xs doesn't get generated until 'nmake' realises 
 that 'Core.obj' is needed ... but it's hard for me to work out just 
 what's going on behind the scenes. I really don't know if this is a 
 problem with the way dmake processes PL_FILES, or whether it's a problem 
 with the xs_c and/or xs_o sections.)

The code above, and what's in the Makefile you provided, appears correct.
Though make_from_PL() is kind of redundant.

The only thing I can think is somehow the Core.obj target is getting run
before Core.xs.PL is and Core.obj does not depend on Core.xs.  That's
100% hypothesis but I don't see anything in the Makefile which causes
Core.obj to be dependent on Core.xs but I don't really understand the .xs*
targets.

If it was GNU make I'd run a make -d and follow the dependency tree using
the resulting debug output.  Don't know what the dmake equivalent is.

Re: PL_FILES and EU::MM 6.25_01+

[Mike Castle]

This is my third post on the subject (I'm sure they're getting through as I
see them in the archives :-).

Can any developers please comment on the problem below?

I see that a release is on the horizon, but this issue has still not been
addressed.  Please, either fix or document.

I have filed a bug on rt: 11536

mrc

On Sat, Jan 08, 2005 at 11:59:54AM -0800, Mike Castle wrote:
 It looks like, starting with 6.25_01, the makefile fragment for PL_FILES
 has changed.  It is no longer passing the target as an option the to
 PERLRUNINST call.  Is this intentional?  I didn't see any mention of this
 in the Changes file.
 
 MP3-Tag-0.94 is the current package I'm noticing this with.  I also came
 across it with another package, but I forgot the name already.
 
 Anyway, with 6.25 installed, the pertinent lines from the Makefile are:
 
 [EMAIL PROTECTED]:42am]src/MP3-Tag/MP3-Tag-0.94(581) perl Makefile.PL ; grep 
 data_pod.PL Makefile
 Writing Makefile for MP3::Tag
 # PL_FILES = { data_pod.PL=q[ID3v2-Data.pod] }
 ID3v2-Data.pod :: data_pod.PL
 $(PERLRUNINST) data_pod.PL ID3v2-Data.pod
 
 And with 6.25_01 and 6.25_05 I see:
 [EMAIL PROTECTED]:55am]src/MP3-Tag/MP3-Tag-0.94(582) perl Makefile.PL ; grep 
 data_pod.PL Makefile
 Writing Makefile for MP3::Tag
 # PL_FILES = { data_pod.PL=q[ID3v2-Data.pod] }
 ID3v2-Data.pod :: data_pod.PL
 $(PERLRUNINST) data_pod.PL
 
 I'm not sure if this was an intentional thing or not.  At first I thought
 it was, in keeping with this part of the docs:
 
 ``The *.PL files are expected to produce output to the target files
 themselves.''
 
 But now I'm not sure.
 
 Thoughts?
 mrc
 -- 
  Mike Castle  [EMAIL PROTECTED]  www.netcom.com/~dalgoda/
 We are all of us living in the shadow of Manhattan.  -- Watchmen
 fatal (You are in a maze of twisty compiler features, all different); -- gcc

-- 
 Mike Castle  [EMAIL PROTECTED]  www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal (You are in a maze of twisty compiler features, all different); -- gcc

Re: PL_FILES

[Ken Williams]

On Feb 13, 2005, at 6:11 PM, Sisyphus wrote:
I know that PL_FILES get processed during the running of 'make' - but 
is there any documentation that tells me anything about precisely 
*when* the processing occurs ? - and what triggers the processing of 
them ? - or how to control the timing of the processing of them ? I 
imagined they'd all get done together (ie one after the other) but 
that's not happening.

If the info's not sitting around somewhere, then it doesn't matter 
greatly - this is not something that has to be solved yesterday. I can 
play around with it and hopefully make it less messy - maybe I'll even 
learn enough to ask an intelligent question :-)

My understanding is that MakeMaker writes a Makefile with all the 
dependencies, and then make/dmake/nmake work out *when* to satisfy 
those dependencies.  So your question is, in a sense, beyond the scope 
of MakeMaker.

To track this down, try putting the excerpt you quoted into a new 
Makefile, define the macros it needs, and run it.  Does it create the 
correct output files?

 -Ken

Re: PL_FILES and EU::MM 6.25_01+

[Ken Williams]

On Jan 8, 2005, at 1:59 PM, Mike Castle wrote:
It looks like, starting with 6.25_01, the makefile fragment for 
PL_FILES
has changed.  It is no longer passing the target as an option the to
PERLRUNINST call.  Is this intentional?  I didn't see any mention of 
this
in the Changes file.
I vote bug.  Want to submit a patch?
 -Ken

Re: PL_FILES

[Michael G Schwern]

On Sun, Feb 13, 2005 at 03:52:55AM +, Sisyphus wrote:
 I have this in my makefile (generated for dmake, by running 'perl 
 Makefile.PL'):

Please send your Makefile.PL and Makefile along with your bug reports.
Without them there isn't a whole lot that can be done.

Re: PL_FILES

[Sisyphus]

Michael G Schwern wrote:
On Sun, Feb 13, 2005 at 03:52:55AM +, Sisyphus wrote:
I have this in my makefile (generated for dmake, by running 'perl 
Makefile.PL'):

Please send your Makefile.PL and Makefile along with your bug reports.
Without them there isn't a whole lot that can be done.
It's all way too messy at the moment. I'm not really in a position to 
make a bug report until I learn a little more about what's supposed to 
happen.
Maybe I should try and keep it a little simpler:

I know that PL_FILES get processed during the running of 'make' - but is 
there any documentation that tells me anything about precisely *when* 
the processing occurs ? - and what triggers the processing of them ? - 
or how to control the timing of the processing of them ? I imagined 
they'd all get done together (ie one after the other) but that's not 
happening.

If the info's not sitting around somewhere, then it doesn't matter 
greatly - this is not something that has to be solved yesterday. I can 
play around with it and hopefully make it less messy - maybe I'll even 
learn enough to ask an intelligent question :-)

Cheers,
Rob

PL_FILES

[Sisyphus]

Hi,
I have this in my makefile (generated for dmake, by running 'perl 
Makefile.PL'):

# --- MakeMaker processPL section:
all :: Core.xs
$(NOECHO) $(NOOP)
Core.xs :: Core.xs.PL
$(PERLRUNINST) Core.xs.PL Core.xs
all :: Types.pm
$(NOECHO) $(NOOP)
Types.pm :: Types.pm.PL
$(PERLRUNINST) Types.pm.PL Types.pm
all :: pdl.h
$(NOECHO) $(NOOP)
pdl.h :: pdl.h.PL
$(PERLRUNINST) pdl.h.PL pdl.h
Afaict, Core.xs.PL is not being run - no warnings, no error messages, no 
mention of 'Core.xs.PL' - it is just apparently being ignored.
'dmake' runs until it errors trying to link to Core.obj - which doesn't 
exist. I'm assuming that Core.obj doesn't exist simply because Core.xs 
didn't get generated in the first place. (Though with 'nmake' I get the 
impression that Core.xs doesn't get generated until 'nmake' realises 
that 'Core.obj' is needed ... but it's hard for me to work out just 
what's going on behind the scenes. I really don't know if this is a 
problem with the way dmake processes PL_FILES, or whether it's a problem 
with the xs_c and/or xs_o sections.)

No such problem however with the other files. They get run and do 
precisely what they should.

Core.xs.PL is syntactically correct. When I run 'perl Core.xs.PL' it 
does what it's supposed to do (ie Core.xs is generated correctly), but 
I'm totally at a loss to understand why it's not being run automatically.
Everything appears to me to be as it should in both the Makefile.PL and 
the Makefile (though that doesn't really mean much :-).

Any advice/clues on what to do, or where to look, to work out why it's 
being ignored ?
Does anyone know of anything that is likely to precipitate such behaviour ?

Is it just that it needs to be promoted up the order of doing things ? 
(If so - how to do that ?) It's something that can be done any time 
after the '.pm' files are copied into the blib.

Also - if I run 'perl Makefile.PL' followed by 'perl Core.xs.PL' and 
*then* run 'dmake', then it works fine - but I'd really like to get it 
working the way it should if I can.

Cheers,
Rob

Re: PL_FILES and EU::MM 6.25_01+

[Mike Castle]

I noticed this problem below is still in 6.26_07.

Any comments?

mrc

On Sat, Jan 08, 2005 at 11:59:54AM -0800, Mike Castle wrote:
 It looks like, starting with 6.25_01, the makefile fragment for PL_FILES
 has changed.  It is no longer passing the target as an option the to
 PERLRUNINST call.  Is this intentional?  I didn't see any mention of this
 in the Changes file.
 
 MP3-Tag-0.94 is the current package I'm noticing this with.  I also came
 across it with another package, but I forgot the name already.
 
 Anyway, with 6.25 installed, the pertinent lines from the Makefile are:
 
 [EMAIL PROTECTED]:42am]src/MP3-Tag/MP3-Tag-0.94(581) perl Makefile.PL ; grep 
 data_pod.PL Makefile
 Writing Makefile for MP3::Tag
 # PL_FILES = { data_pod.PL=q[ID3v2-Data.pod] }
 ID3v2-Data.pod :: data_pod.PL
 $(PERLRUNINST) data_pod.PL ID3v2-Data.pod
 
 And with 6.25_01 and 6.25_05 I see:
 [EMAIL PROTECTED]:55am]src/MP3-Tag/MP3-Tag-0.94(582) perl Makefile.PL ; grep 
 data_pod.PL Makefile
 Writing Makefile for MP3::Tag
 # PL_FILES = { data_pod.PL=q[ID3v2-Data.pod] }
 ID3v2-Data.pod :: data_pod.PL
 $(PERLRUNINST) data_pod.PL
 
 I'm not sure if this was an intentional thing or not.  At first I thought
 it was, in keeping with this part of the docs:
 
 ``The *.PL files are expected to produce output to the target files
 themselves.''
 
 But now I'm not sure.
 
 Thoughts?
 mrc
 -- 
  Mike Castle  [EMAIL PROTECTED]  www.netcom.com/~dalgoda/
 We are all of us living in the shadow of Manhattan.  -- Watchmen
 fatal (You are in a maze of twisty compiler features, all different); -- gcc

-- 
 Mike Castle  [EMAIL PROTECTED]  www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal (You are in a maze of twisty compiler features, all different); -- gcc