On May 17, 2012, at 11:15 AM, Craig A. Berry wrote:
>
> On May 16, 2012, at 8:34 AM, Nicholas Clark wrote:
>
[some text deleted]
>> 9: The IA64 machine *initially* fails like this:
>>
>> MCR PTAC$DKA0:[NCLARK.I.perl5160-RC2]miniperl.exe "-I[--.lib]" "-I[--.lib]"
>> "-ME
>> xtUtils::Command" -e "cp" "--" DYNALOADER.OPT
>> [--.LIB.AUTO.DYNALOADER]DYNALOADER
>> .OPT
>> %MMS-F-GWKNOACTS, Actions to update DL_VMS.C are unknown.
>> %MMS-F-GWKNOACTS, Actions to update DL_VMS.C are unknown.
>
> The problem here is that MMK can infer that it needs to generate dl_vms.c
> from dl_vms.xs, but MMS can't do that.
>
Makefile.pl is currently placing the following lines in the MMS file:
.SUFFIXES :
.SUFFIXES : $(OBJ_EXT) .c .cpp .cxx .xs
and
.xs.c :
$(XSUBPPRUN) $(XSPROTOARG) $(XSUBPPARGS) $(MMS$TARGET_NAME).xs
>$(MMS$TARGET)
and (for this particular instance)
dl_win32.c dl_aix.c dl_dld.c dl_vmesa.c dl_dllload.c dl_dyld.c dl_none.c
dl_hpux.c dl_beos.c dl_mpeix.c dl_dlopen.c dl_next.c dl_symbian.c dl_vms.c :
$(XSUBPPDEPS)
MMK then searches the list of suffixes that follow .c to see if it has a rule
to build the .c file since no explicit action is given. It finds the .xs.c
rule and executes it. MMS does not do this.
There are two ways to address this.
1. Instead of having makefile.pl write out the .xs.c line as a user-defined
rule, write it out as an action line after the 3rd entry above so that it reads
like this:
dl_win32.c dl_aix.c dl_dld.c dl_vmesa.c dl_dllload.c dl_dyld.c dl_none.c
dl_hpux.c dl_beos.c dl_mpeix.c dl_dlopen.c dl_next.c dl_symbian.c dl_vms.c :
$(XSUBPPDEPS)
$(XSUBPPRUN) $(XSPROTOARG) $(XSUBPPARGS) $(MMS$TARGET_NAME).xs
>$(MMS$TARGET)
2. When makefile.pl writes out the .xs.c user-defined rule, have it add the
following:
.DEFAULT :
IF F$LOCATE("]XSUBPP","$+") .NE. F$LENGTH("$+") THEN $(XSUBPPRUN)
$(XSPROTOARG) $(XSUBPPARGS) $(MMS$TARGET_NAME).xs >$(MMS$TARGET)
The second option has the added benefit of providing a null action for anything
else that MMS can't figure out how to build which takes care of the "actions to
build STATIC not found" error as well.
On an unrelated issue:
Can the code invoked by makefile.pl tell whether perl itself is being built or
if a perl extension is being built? If so, would it be possible to have the
"install" part of the perl build process add the following files with their
indicated contents to the directory PERL_ROOT:[LIB…CORE]?
__DECC_INCLUDE_EPILOGUE.H
#pragma names restore
__DECC_INCLUDE_PROLOGUE.H;1
#pragma names save
#pragma names uppercase
#pragma names truncated
This way, the makefile.pl for extensions can automatically add
/names=(as_is,shortened) to the CC command line when building extensions. This
is a requirement to build a number of extensions, not only because they might
use an external library with very long names but also because some programmers
out there still think it is clever to use different routine/variable names that
differ only in case. Those two files will cause all files included in, or by,
the […core]*.h files to be treated as if /names=(uppercase,truncated) had been
specified. The routine that converts .xs to .c already handles truncating any
names that are part of perl so the shortened only takes effect for references
to external libraries.
Alternatively, one could build perl with /names=shortened, and change the
prologue file accordingly, and completely eliminate the process of manually
shortening names.
Thoughts?
Mark Berryman
