Per the discussion here:

<http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2002-03/msg01058.html>

I think I finally understand why Robin Barker's recent fix for 
Devel/PPPort's Makefile.PL (which is perfectly sensible given the 
documented API) doesn't work as expected on VMS.

The C<depend> section comes rather early in a Makefile and definitely 
before the C<top_targets> section.  But the VMS make utilities, both 
Compaq's MMS and the freeware lookalike MMK, assume that the first 
target in the file is the root of the dependency tree.  Robin's patch 
made C<$(OBJECT)> the first target in the file, so the VMS make 
utilities do what they were designed to do, which is make that target 
and quit.

99% of the time, MakeMaker creates a Makefile that has the 
C<top_targets> section (and thus the C<all> target) first, which is 
why this doesn't come up very often.  But if an extension does 
something that creates a dependency in an earlier section, we're 
hosed.  This has always happened with DBI, which uses the 
C<post_constants> section to add several dependencies (as well as a 
few constants).

There is a comment in C<full_setup()> in MakeMaker.pm that says, 
"Let's try to collect the macros up front, then pasthru, then the 
rules."  The C<depend> section is right in the middle of the macro 
sections, even though its obvious purpose is to define dependency 
rules.  In addition to the problem this is causing on VMS it seems to 
me it could have another unwanted side effect with any make utility, 
namely that any dependencies that reference macros declared in a 
later section (such as C<post_constants>) won't work because the 
macros haven't been expanded yet.

Perhaps there is some rationale or necessity for putting the 
C<depend> section where it is.  Even if there's not, I'm not suicidal 
enough to try reordering MakeMaker sections a few weeks before a 
major release, so I think what I'll do is jigger our build procedure 
so it always makes the C<all> target explicitly when building core 
extensions.  Better solutions welcome.

-- 
________________________________________
Craig A. Berry
mailto:[EMAIL PROTECTED]

"... getting out of a sonnet is much more
 difficult than getting in."
                 Brad Leithauser

Reply via email to