Re: lib/test/simple/t/create.t help with VMS issue needed.
sebb [EMAIL PROTECTED] wrote on 08/15/2005 08:34:31 PM: Would it not be better to fix the VMS Perl open() call so it works the same as on other OSes? I meant for READ access only here. The performance impact of altering perl's open() to use the CRTL shr would be significant. Ordinary perl usage would slow to a crawl. Folks who want shr can load and use VMS::Stdio::vmsopen() and pay the performance penalty. Peter Prymmer
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.26_01
Michael G Schwern [EMAIL PROTECTED] wrote on 03/29/2005 05:23:16 PM:
Yes it is. That indicates the test module never got built. Doesn't say
why though... If you're feeling adventurous could you step into setup()
on line 25 of PL_FILES.t and poke around?
One could either modify setup or modify the test. Below I enclose
a patch that takes the latter approach.
On both Solaris and on VMS I obtained the misleading statement:
t/xs
skipped
all skipped: No compiler found to test XS builds
Which it turns out was due to ExtUtils::CBuilder not being installed
not because I did not have a compiler.
Would this be less confusing?
ExtUtils::CBuilder couldn't find a compiler to test XS builds
That would be better. If not too long the line:
ExtUtils::CBuilder was not found or it could not find a compiler
might be more accurate. By the way is the plan to introduce
the new ExtUtils::MakeMaker and the ExtUtils::CBuilder into
bleedperl? Would a warning about a missing prereq for the separate
CPAN dist of MakeMaker be helpful?
Now that's unexpected. VMS works but Solaris didn't.
Silly case sensitive file system: setup() wrote output
files to a directory called PL_FILES-Module then the test came
along and attempted to chdir to PL_Files-Module. That scheme worked
on VMS and Windows, but not on Solaris (unlikely to work on any Unix).
Here is one way to address the problem:
diff -ru ExtUtils-MakeMaker-6.26_01.orig/t/PL_FILES.t
ExtUtils-MakeMaker-6.26_01/t/PL_FILES.t
--- ExtUtils-MakeMaker-6.26_01.orig/t/PL_FILES.t 2005-03-29
00:17:16.0 -0500
+++ ExtUtils-MakeMaker-6.26_01/t/PL_FILES.t 2005-03-30 09:29:15.326006000
-0500
@@ -29,7 +29,7 @@
ok( teardown );
}
-ok chdir('PL_Files-Module');
+ok chdir('PL_FILES-Module');
run(qq{$perl Makefile.PL});
cmp_ok( $?, '==', 0 );
End of Patch.
With that I obtain:
All tests successful, 7 tests and 38 subtests skipped.
Files=40, Tests=714, 120 wallclock secs (60.59 cusr + 46.75 csys = 107.34 CPU)
with perl 5.8.5 on SunOS 5.8 (aka Solaris 8).
Peter Prymmer
to appease the line wrap gremlin also as an attachment:
(See attached file: em.patch)
em.patch
Description: Binary data
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.26_01
Michael G Schwern [EMAIL PROTECTED] wrote on 03/29/2005 12:51:00 AM:
http://www.pobox.com/~schwern/src/ExtUtils-MakeMaker-6.26_01.tar.gz
or
http://svn.schwern.org/svn/CPAN/ExtUtils-MakeMaker/trunk
or
a CPAN near you
Mark Leighton Fisher noticed that PL_FILES weren't working properly
anymore.
This was due to a refactoring typo and has been fixed and tested. Also
the full behavior of PL_FILES has been documented.
So this is a quick alpha release to knock around to make sure the new
PL_FILES.t test works before putting out a quick 6.27.
It did not work for me on SunOS 5.8 + perl 5.6.1 + Forte make:
% make test
snip
t/PL_FILES..# Failed test (t/PL_FILES.t at line 32)
t/PL_FILES..NOK 1# Failed test (t/PL_FILES.t at line 35)
t/PL_FILES..NOK 2# got: 512
# expected: 0
# Failed test (t/PL_FILES.t at line 38)
t/PL_FILES..NOK 3# got: '256'
# expected: '0'
# make: Fatal error: No arguments to build
# Current working directory /home/pprymmer/testit/ExtUtils-MakeMaker-6.26
_01/t
# Failed test (t/PL_FILES.t at line 41)
t/PL_FILES..NOK 4# Failed test (t/PL_FILES.t at line 41)
t/PL_FILES..NOK 5# Failed test (t/PL_FILES.t at line 41)
t/PL_FILES..ok 8/0# Looks like you failed 6 tests of 8.
t/PL_FILES..dubious
Test returned status 6 (wstat 1536, 0x600)
DIED. FAILED tests 1-6
Failed 6/8 tests, 25.00% okay
Here is a run done sans make test:
% perl -Mblib t/PL_FILES.t
Using /home/pprymmer/testit/ExtUtils-MakeMaker-6.26_01.orig/blib
not ok 1
# Failed test (t/PL_FILES.t at line 32)
not ok 2
# Failed test (t/PL_FILES.t at line 35)
# got: 512
# expected: 0
not ok 3
# Failed test (t/PL_FILES.t at line 38)
# got: '256'
# expected: '0'
# make: Fatal error: No arguments to build
not ok 4 - single.out was created
# Failed test (t/PL_FILES.t at line 41)
not ok 5 - 1.out was created
# Failed test (t/PL_FILES.t at line 41)
not ok 6 - 2.out was created
# Failed test (t/PL_FILES.t at line 41)
ok 7
ok 8
1..8
# Looks like you failed 6 tests of 8.
If that is of any help.
On both Solaris and on VMS I obtained the misleading statement:
t/xs
skipped
all skipped: No compiler found to test XS builds
Which it turns out was due to ExtUtils::CBuilder not being installed
not because I did not have a compiler.
On VMS 7.3-2 + perl 5.8.1 + mmk V3.9-6 I obtained:
All tests successful, 8 tests and 94 subtests skipped.
Files=40, Tests=647, 261 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00
CPU)
In trying to figure out why MakeMaker is mislead into
thinking I did not have a compiler I noticed a possible problem
with the Utils.pm handling of old makefiles:
diff -ru ExtUtils-MakeMaker-6.26_01.orig/t/lib/MakeMaker/Test/Utils.pm
ExtUtils-MakeMaker-6.26_01/t/lib/MakeMaker/Test/Utils.pm
--- ExtUtils-MakeMaker-6.26_01.orig/t/lib/MakeMaker/Test/Utils.pm 2005-03-12
13:05:25.0 -0500
+++ ExtUtils-MakeMaker-6.26_01/t/lib/MakeMaker/Test/Utils.pm 2005-03-29
14:12:27.147824000 -0500
@@ -149,7 +149,7 @@
sub makefile_backup {
my $makefile = makefile_name;
-return $Is_VMS ? $makefile : $makefile.old;
+return $Is_VMS ? ${makefile}_old : $makefile.old;
}
=item Bmake
End of Patch.
I think that is correct owing to things like the following:
search descrip.mms MAKEFILE_OLD
MAKEFILE_OLD = Descrip.MMS_old
But in any case the tests all pass on VMS with or without that patch in place.
Peter Prymmer
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.25_08
Michael G Schwern [EMAIL PROTECTED] wrote on 02/08/2005 09:31:48 AM:
Its time for another MakeMaker alpha! This one is mostly VMS fixes
though
I also discovered a conflict with Module::Install and undid an accidental
change that broken Archive::Zip. As far as I know all outstanding issues
are resolved, so this is release candidate... oh let's call it 4.
http://www.pobox.com/~schwern/src/ExtUtils-MakeMaker-6.25_08.tar.gz
or
http://svn.schwern.org/svn/CPAN/ExtUtils-MakeMaker
Nick says code freeze for 5.8.7 is scheduled for end of Feburary. I'd
like to get 6.26 out before then.
This 6.25_08 kit appears to have the same problem with
multiple object files not being comma separated in the static_lib target
that I warned about in previous messages to the list:
http://www.xray.mpe.mpg.de/mailing-lists/vmsperl/2005-01/msg00030.html
http://www.xray.mpe.mpg.de/mailing-lists/vmsperl/2005-01/msg00031.html
and that I had also previously attempted to patch with:
http://www.xray.mpe.mpg.de/mailing-lists/vmsperl/2005-01/msg00032.html
Here is the tail end of the MMK command with 6.25_08 installed into
a perl 5.8.6 tree (with some added line wrapping) trying to build
Bit::Vector 6.3 (a CPAN extension especially chosen since it has
multiple $(OBJECT) files):
CC/DECC /Include=[]/Standard=Relaxed_ANSI/Prefix=All/Obj=.obj
/NOANSI_ALIAS/float=ieee/ieee=denorm_results/Define=(VERSION=6.3,
XS_VERSION=6.3)/Include=(perl_root:[lib.VMS_AXP.5_8_6.CORE])/NoList
VECTOR.c
If F$Search([.BLIB.ARCH.AUTO.BIT.VECTOR]VECTOR.OLB).eqs. Then
Library/Object/Create [.BLIB.ARCH.AUTO.BIT.VECTOR]VECTOR.OLB
Library/Object/Replace [.BLIB.ARCH.AUTO.BIT.VECTOR]VECTOR.OLB bitvector.obj
vector.obj
%DCL-W-MAXPARM, too many parameters - reenter command with fewer parameters
\VECTOR\
%MMK-F-ERRUPD, error status %X00038098 occurred when updating target
[.BLIB.ARCH.AUTO.BIT.VECTOR]VECTOR.OLB
Note that the VMS LIBRARY command does not like to
insert space separated lists of .o files into an archive.
It will work with a comma separated list.
Enclosed is a patch taken against MM 6.25_08 that allows
MakeMaker's own mmk test suite to pass 100% and to allow me to
build Bit::Vector 6.3 on VMS:
diff -ru ExtUtils-MakeMaker-6.25_08.orig/lib/ExtUtils/MM_VMS.pm
ExtUtils-MakeMaker-6.25_08/lib/ExtUtils/MM_VMS.pm
--- ExtUtils-MakeMaker-6.25_08.orig/lib/ExtUtils/MM_VMS.pm 2005-02-08
09:07:02.0 -0500
+++ ExtUtils-MakeMaker-6.25_08/lib/ExtUtils/MM_VMS.pm 2005-02-18
16:54:04.507216000 -0500
@@ -980,7 +980,10 @@
my(@m,$lib);
push @m,'
-$(INST_STATIC) : $(OBJECT) $(MYEXTLIB) $(INST_ARCHAUTODIR)$(DFSEP).exists
+# Rely on suffix rule for update action
+$(OBJECT) : $(INST_ARCHAUTODIR)$(DFSEP).exists
+
+$(INST_STATIC) : $(OBJECT) $(MYEXTLIB)
';
# If this extension has its own library (eg SDBM_File)
# then copy that to $(INST_STATIC) and add $(OBJECT) into it.
@@ -991,7 +994,11 @@
# if there was a library to copy, then we can't use MMS$SOURCE_LIST,
# 'cause it's a library and you can't stick them in other libraries.
# In that case, we use $OBJECT instead and hope for the best
-push(@m,\t,'Library/Object/Replace $(MMS$TARGET) $(OBJECT)',\n);
+if ($self-{MYEXTLIB}) {
+ push(@m,\t,'Library/Object/Replace $(MMS$TARGET) $(OBJECT)',\n);
+} else {
+ push(@m,\t,'Library/Object/Replace $(MMS$TARGET)
$(MMS$SOURCE_LIST)',\n);
+}
push @m, \t\$(NOECHO) \$(PERL) -e 1 \$(INST_ARCHAUTODIR)extralibs.ld\n;
foreach $lib (split ' ', $self-{EXTRALIBS}) {
Peter Prymmer
(See attached file: mm_6.25_08.patch)
mm_6.25_08.patch
Description: Binary data
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.25_06
Peter Prymmer/FactSet wrote on 01/05/2005 11:18:01 AM: was buildable by it. If 6.25_08 gets released I'll see about patching it, otherwise I may try to prepare a patch for 6.25_07 (but don't wait too long for me). I have tried to browse over to http://www.pobox.com/~schwern/src/ExtUtils-MakeMaker-6.25_08.tar.gz and obtained HTTP 404 - File not found. I truncated the filename and that apparenty resolved to: http://magnonel.guild.net/~schwern/src/ and in there I see no 6.25_08 file. I have been unable to locate the 6.25_08 kit. Hence I now present a revised patch to 6.25_07 to address the object library object insertion issue while retaining a dependency on the .exists file that you want (and was present in previous MakeMakers): --- ExtUtils-MakeMaker-6_25_07/lib/ExtUtils/MM_VMS.pm;-1Fri Dec 31 08:48:52 2004 +++ ExtUtils-MakeMaker-6_25_07/lib/ExtUtils/MM_VMS.pm Thu Jan 6 07:32:16 2005 @@ -981,9 +981,9 @@ my(@m,$lib); push @m,' # Rely on suffix rule for update action -$(OBJECT) : $(FIRST_MAKEFILE) +$(OBJECT) : $(FIRST_MAKEFILE) $(INST_ARCHAUTODIR)$(DFSEP).exists -$(INST_STATIC) : $(OBJECT) $(MYEXTLIB) $(INST_ARCHAUTODIR)$(DFSEP).exists +$(INST_STATIC) : $(OBJECT) $(MYEXTLIB) '; # If this extension has its own library (eg SDBM_File) # then copy that to $(INST_STATIC) and add $(OBJECT) into it. I hope that helps/suffices. Peter Prymmer (See attached file: mm_vms.patch_03) mm_vms.patch_03 Description: Binary data
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.25_06
Michael G Schwern [EMAIL PROTECTED] wrote on 01/04/2005 05:12:32 PM:
Ahh, $(MMS$SOURCE_LIST) is a list of all dependencies. I think it can be
safely removed. The logic is this:
if ($self-{MYEXTLIB}) {
push(@m,\t,'Library/Object/Replace $(MMS$TARGET)
$(OBJECT)',\n);
} else {
push(@m,\t,'Library/Object/Replace $(MMS$TARGET)
$(MMS$SOURCE_LIST)',\n);
}
That is not quite correct. As it turns out $(MMS$SOURCE_LIST) is a comma
separated list of filenames without types (in the language of RMS file
parsing
TYPEs are also known as extensions in the Windows centric world). This
difference is crucial to the use of LIBRARY as I'll demonstrate below.
Since the only time $(MMS$SOURCE_LIST) is used is when $(MYEXTLIB) is
empty
and the only important dependencies are $(OBJECT) and $(MYEXTLIB) the
list is
always going to be $(OBJECT) so both branches are effectively the same.
So
this should solve the problem while keeping the dependency.
--- lib/ExtUtils/MM_VMS.pm (revision 4204)
+++ lib/ExtUtils/MM_VMS.pm (local)
@@ -994,11 +991,7 @@
# if there was a library to copy, then we can't use MMS$SOURCE_LIST,
# 'cause it's a library and you can't stick them in other libraries.
# In that case, we use $OBJECT instead and hope for the best
-if ($self-{MYEXTLIB}) {
- push(@m,\t,'Library/Object/Replace $(MMS$TARGET)
$(OBJECT)',\n);
-} else {
- push(@m,\t,'Library/Object/Replace $(MMS$TARGET)
$(MMS$SOURCE_LIST)',\
n);
-}
+push(@m,\t,'Library/Object/Replace $(MMS$TARGET) $(OBJECT)',\n);
push @m, \t\$(NOECHO) \$(PERL) -e 1
\$(INST_ARCHAUTODIR)extralibs.ld\n;
foreach $lib (split ' ', $self-{EXTRALIBS}) {
Unfortunately it looks like this will break builds for
extensions that have more than one file listed in $(OBJECT).
Among them would be Bit::Vector 6.3, Compress::Zlib 1.33,
Date::Calc 5.3, DBD::mysql 2.903_1 (gleaned from my local
list of extensions, the list is potentially larger).
To illustrate how the LIBRARY/OBJECT/REPLACE command chokes
on a space separated list of obj files let me start
with a clean directory into which I copy the bitvector.obj and
vector.obj files from the place where my cpan modules are built
and create a bare bones descrip.mms file that uses your proposal:
$ type descrip.mms
PERL = perl
OBJECT = bitvector.obj vector.obj
BASEEXT = TESTIT
LIB_EXT = .olb
INST_STATIC = $(BASEEXT)$(LIB_EXT)
all :: $(INST_STATIC)
write sys$output all up to date now
$(INST_STATIC) : $(OBJECT) $(MYEXTLIB)
If F$Search($(MMS$TARGET)).eqs. Then Library/Object/Create
$(MMS$TARGET)
write sys$output $(MMS$SOURCE_LIST)
Library/Object/Replace $(MMS$TARGET) $(OBJECT)
$(NOECHO) $(PERL) -e 1 $(INST_ARCHAUTODIR)extralibs.ld
Here is a test run of that:
$ mmk
If F$Search(TESTIT.OLB).eqs. Then Library/Object/Create TESTIT.OLB
write sys$output BITVECTOR.OBJ,VECTOR.OBJ
BITVECTOR.OBJ,VECTOR.OBJ
Library/Object/Replace TESTIT.OLB bitvector.obj vector.obj
%DCL-W-MAXPARM, too many parameters - reenter command with fewer parameters
\VECTOR\
%MMK-F-ERRUPD, error status %X00038098 occurred when updating target
TESTIT.OLB
Note that it created TESTIT.OLB but failed to insert anything in it:
$ directory/size testit.olb
Directory USER:[PPRYMMER.MAKEMAKER]
TESTIT.OLB;1 214
Total of 1 file, 214 blocks.
On the other hand if I alter my descrip.mms to incorporate
the special $(MMS$SOURCE_LIST) macro I obtain the following result:
--- descrip.mms;-1 Wed Jan 5 11:04:17 2005
+++ descrip.mms Wed Jan 5 11:07:47 2005
@@ -11,5 +11,5 @@
$(INST_STATIC) : $(OBJECT) $(MYEXTLIB)
If F$Search($(MMS$TARGET)).eqs. Then Library/Object/Create
$(MMS$TARGET)
write sys$output $(MMS$SOURCE_LIST)
-Library/Object/Replace $(MMS$TARGET) $(OBJECT)
+Library/Object/Replace $(MMS$TARGET) $(MMS$SOURCE_LIST)
$(NOECHO) $(PERL) -e 1 $(INST_ARCHAUTODIR)extralibs.ld
This works OK as demonstrated below:
$ delete testit.olb;
$ mmk
If F$Search(TESTIT.OLB).eqs. Then Library/Object/Create TESTIT.OLB
write sys$output BITVECTOR.OBJ,VECTOR.OBJ
BITVECTOR.OBJ,VECTOR.OBJ
Library/Object/Replace TESTIT.OLB BITVECTOR.OBJ,VECTOR.OBJ
perl -e 1 extralibs.ld
write sys$output all up to date now
all up to date now
$ directory/size testit.olb
Directory USER:[PPRYMMER.MAKEMAKER]
TESTIT.OLB;11091
Total of 1 file, 1091 blocks.
Note that TESTIT.OLB now has both modules inside it (hence it occupies
more disk space).
You seem dead set on having .exists as a dependent somehow,
I'd recommend removing it from the $(INST_STATIC) dependents
and I noted that in the descrip.mms for Bit::Vector there is
a rule for $(OBJECT) to depend on .exists like so:
$ search dga2:[cpan_modules.bit-vector-6_3]descrip.mms $(INST_STATIC)
:/win=(3,4)
# Rely on suffix rule for update action
$(OBJECT) : $(INST_ARCHAUTODIR)$(DIRFILESEP).exists
$(INST_STATIC) : $(OBJECT) $(MYEXTLIB)
If
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.25_06
Peter Prymmer/FactSet wrote on 01/05/2005 11:18:01 AM: That is not quite correct. As it turns out $(MMS$SOURCE_LIST) is a comma separated list of filenames without types (in the language of RMS file parsing TYPEs are also known as extensions in the Windows centric world). This difference is crucial to the use of LIBRARY as I'll demonstrate below. OK so now I ought to correct my correction: the $(MMS$SOURCE_LIST) while comma separated does retain the .OBJ file types. The command: LIBRARY/OBJECT/REPLACE VECTOR.OLB BITVECTOR.OBJ,VECTOR.OBJ Knows to put BITVECTOR and VECTOR into the OLB library file. This can be verified with the following sort of command from the shell prompt: ibrary/list [.blib.arch.auto.bit.vector]vector.olb Peter Prymmer
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.25_06
Michael G Schwern [EMAIL PROTECTED] wrote on 01/04/2005 04:46:54 PM: -$(INST_STATIC) : $(OBJECT) $(MYEXTLIB) $(INST_ARCHAUTODIR)$(DFSEP).exists +$(INST_STATIC) : $(OBJECT) $(MYEXTLIB) '; # If this extension has its own library (eg SDBM_File) # then copy that to $(INST_STATIC) and add $(OBJECT) into it. Why would removing it as a dependency matter? Because of the subsequent action command: $ search descrip.mms library/object/replace/window $(INST_STATIC) : $(OBJECT) $(MYEXTLIB) If F$Search($(MMS$TARGET)).eqs. Then Library/Object/Create $(MMS$TARGET) Library/Object/Replace $(MMS$TARGET) $(MMS$SOURCE_LIST) $(NOECHO) $(PERL) -e 1 $(INST_ARCHAUTODIR)extralibs.ld The library/object command knows when it is being asked to insert a non *.OBJ file into an OLB library because of the different file attributes that a text file like .exists has. Peter Prymmer
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.25_06
Michael G Schwern [EMAIL PROTECTED] wrote on 01/04/2005 04:44:50 PM: On Fri, Dec 31, 2004 at 12:41:38PM -0500, [EMAIL PROTECTED] wrote: Which looks like a problem with DBI code not MakeMaker. Did DBI work with 6.17? DBI 1.45 would build with 6.17, but as Craig pointed out the Makefile.PL for that particular extension has some unportabilities associated with its customized clean target. Hence neither 6.17 nor 6.25_07 could clean DBI 1.45 successfully (both dbipro*.pl files are erroneously deleted on VMS). Peter Prymmer
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.25_06
Peter Prymmer/FactSet wrote on 12/31/2004 04:36:31 PM: I have not yet found how to fix the .exists into OLB problem nor the trouble with MMS V3.2-01 reported earlier. I forgot to mention that *.opt files are not being cleaned on VMS as another problem that persists. I seem to have solved the .exists getting lib/replaced into OLB problem though. Herein is a suggested patch: --- extutils-makemaker-6_25_07/lib/extutils/mm_vms.pm;1 Fri Dec 31 08:48:52 2004 +++ ExtUtils-MakeMaker-6_25_07/lib/ExtUtils/MM_VMS.pm Mon Jan 3 10:43:10 2005 @@ -983,7 +983,7 @@ # Rely on suffix rule for update action $(OBJECT) : $(FIRST_MAKEFILE) -$(INST_STATIC) : $(OBJECT) $(MYEXTLIB) $(INST_ARCHAUTODIR)$(DFSEP).exists +$(INST_STATIC) : $(OBJECT) $(MYEXTLIB) '; # If this extension has its own library (eg SDBM_File) # then copy that to $(INST_STATIC) and add $(OBJECT) into it. With that and the previously mentioned touchups I made to my MM_Unix.pm I was able to build and test DBI-1.45. I'll see about restoring the cleaning of .opt files next. (My version of MMS is perhaps too old to bother worrying about). Peter Prymmer
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.25_06
Peter Prymmer/FactSet wrote on 01/03/2005 10:54:24 AM:
I'll see about restoring the cleaning of .opt files next.
OK here is a patch that implements this extra clean target file
cleanup.
--- ExtUtils-MakeMaker-6_25_07/lib/ExtUtils/MM_VMS.pm;-3Mon Jan 3 10:43:10
2005
+++ ExtUtils-MakeMaker-6_25_07/lib/ExtUtils/MM_VMS.pm Mon Jan 3 11:59:26 2005
@@ -1017,7 +1017,7 @@
sub extra_clean_files {
return qw(
- *.Map *.Dmp *.Lis *.cpp *.$(DLEXT) $(BASEEXT).bso
+ *.Map *.Dmp *.Lis *.cpp *.$(DLEXT) *.Opt $(BASEEXT).bso
.MM_Tmp
);
}
I found it instructive to compare a couple of different
versions of MM_VMS.pm to see which extra VMS specific
files were mentioned (idiosyncracy to note: note
only are the arguments to search switched with respect
to the arguments to unix grep, but the VMS shell does
not expand the * by deafult and it is passed to the search
program literally):
Perl 5.8.6 with a patched MakeMaker 6.25_07
$ search perl_root:[lib.extutils]mm_vms.pm *.map
*.Map *.Dmp *.Lis *.cpp *.$(DLEXT) *.Opt $(BASEEXT).bso
Perl 5.005_02 with MakeMaker 5.4301
$ search perl_root:[lib.extutils]mm_vms.pm *.map
push @m, ' $(RM_F) *.Map *.Dmp *.Lis *.cpp *.$(DLEXT) *$(OBJ_EXT)
*$(LIB_EXT) *.Opt $(BOOTSTRAP) $(BASEEXT).bso .MM_Tmp
Perl 5.8.1 with MakeMaker 6.17
$ search perl_root:[lib.extutils]mm_vms.pm *.map
push @m, ' $(RM_F) *.Map *.Dmp *.Lis *.cpp *.$(DLEXT) *$(OBJ_EXT)
*$(LIB_EXT) *.Opt $(BOOTSTRAP) $(BASEEXT).bso .MM_Tmp
I note that with 6.25_07 the various *.OBJ; files are
handled with mmk clean as is the DBI.EXE sharable
image. The BOOTSTRAP macro seems to have disappeared,
hence I think that the only thing missing was the *.Opt
that I added in the above patch (but I have not tested
static extension building and cleaning much).
Peter Prymmer
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.25_06
Michael G Schwern [EMAIL PROTECTED] wrote on 01/01/2005 07:38:57 PM:
My bad. I left in a / when I unified the VMS tool_xsubpp(). Its better
solved by changing $(XSUBPPDIR)/xsbupp to $(XSUBPPDIR)$(DFSEP)xsubpp.
I can confirm that this solution would be fine for VMS since
DFSEP contains an empty string as it needs.
The only other difference is VMS had this:
XSUBPPDEPS = @tmdeps
and Unix had this:
XSUBPPDEPS = @tmdeps \$(XSUBPP)
I'm assuming that some fix was put into the Unix version and it was
forgotten for VMS. It went in as part of a large, rambling change from
the cfperl branch years ago.
I am trying to imagine what utility there is in having
a dependence on /unix/path/to/xsubpp inside the Makefile.
Perhaps if you were hacking on xsubpp it might be helpful, but
even if you were doing that I'd argue that your time would be
better spent starting off running the
perl Makefile.PL
command and not relying on a dependence upon xsubpp to trigger
your module/extension rebuilds for you. I could be missing
something here though (???).
At any rate the folloing patch to MM_Unix.pm does allow
for DBI 1.45 to build on VMS (with the two other patches
applied to MM_VMS.pm):
--- ExtUtils-MakeMaker-6_25_07/lib/ExtUtils/MM_Unix.pm;-2 Fri Dec 31 08:48:17
2004
+++ ExtUtils-MakeMaker-6_25_07/lib/ExtUtils/MM_Unix.pm Mon Jan 3 12:43:38
2005
@@ -3520,9 +3520,9 @@
return qq{
XSUBPPDIR = $xsdir
-XSUBPP = \$(PERLRUN) \$(XSUBPPDIR)/xsubpp
+XSUBPP = \$(PERLRUN) \$(XSUBPPDIR)\$(DFSEP)xsubpp
XSPROTOARG = $self-{XSPROTOARG}
-XSUBPPDEPS = @tmdeps \$(XSUBPP)
+XSUBPPDEPS = @tmdeps
XSUBPPARGS = @tmargs
XSUBPP_EXTRA_ARGS =
};
I have not tested that on Unix though.
Peter Prymmer
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.25_07
Michael G Schwern [EMAIL PROTECTED] wrote on 01/01/2005 06:50:43 PM: I don't quite understand what 6.17 has to do with it. MakeMaker builds itself using itself, not the installed version. Sorry - I did not realize that. With that installed a second attempt to build it with mms 3.2-01 still fails with a similar message. I have verified that this MMS can handle rudimentary descrip.mms files. I do not know yet what is causing the trouble. Probably the directory target issue on older MMS' that Craig pointed out. Probably. My version of MMS is older than Craig's and is even less informative about the trouble than his was. Peter Prymmer
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.25_07
Michael G Schwern [EMAIL PROTECTED] wrote on 01/03/2005 02:41:17 PM: Do these guys charge for upgrades or something? They might. Peter Prymmer
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.25_06
Michael G Schwern [EMAIL PROTECTED] wrote on 12/29/2004 10:33:02 PM: Its also hideously insecure. You're running a shell script that could do anything. A problem with any self-extracting archive. From shar(1). SECURITY CONSIDERATIONS It is easy to insert trojan horses into shar files. It is strongly rec- ommended that all shell archive files be examined before running them through sh(1). Archives produced using this implementation of shar may be easily examined with the command: egrep -v '^[X#]' shar.file I find it interesting to note too that the command: perl Makefile.PL can be made to do anything provided a trojan horse has been inserted either directly into the Makefile.PL file or into another file that Makefile.PL either requires or do()'s. It is interesting to note also that these days many folks login to linux as root and they may not even directly run that command after having examined the Makefile.PL since they may be using a convenience utility such as the CPAN shell. While I doubt that: make shdist or: mmk shdist is often used nowadays to prepare somehting for upload to CPAN, I suspect that removing it might adversely affect folks that have to email perl module distributions along 7 bit email relays For those that need that there is uutardist. Or if they really need it they can just uuencode or base64 encode the tarball themselves. Or let their MTA do it as is the current practice. The emailability of Unix shar or VMS share files is one consideration. Another is that the native VMS command @ is all that is needed to unpack a VMS_SHARE prepared file. In fact, the (VMS_)share format is as close to a native VMS compatible dist format as MakeMaker currently offers. All of the others: *.zip, *.tar.gz, *.tar.bz2, etc. require the installation of a special non VMS native unpacking program. (Hmm, perhaps we need a new pcsidist target? Then there is that whole ppm thing that was supposed to be the be all of binary dist formats especially suited to folks that had no compiler... so many dist formats to choose from.) I'd throw shdist out if I didn't think it would be more trouble than its worth. I hope nobody's using it. I think the unportability of shar was its main downfall rather than security concerns. The shar file might be able to unpack with: sh sharfile on SunOS 4.3 but it might not unpack on HP-UX 11.x (most likely since some necessary utility was not on your $PATH). It's not that bad to support, and it is not too popular, some folks might want to have it for some reason that I may or may not have been able to put forth. Peter Prymmer
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.25_06
H.Merijn Brand [EMAIL PROTECTED] wrote on 12/30/2004 03:32:31 AM: On Wed 29 Dec 2004 19:49, [EMAIL PROTECTED] wrote: Craig A. Berry [EMAIL PROTECTED] wrote on 12/29/2004 01:09:58 PM: 4.) The following macro is defined and is used in the shdist target: SHAR = vms_share There is no such native command as vms_share. If I knew more about the intention, I might be able to suggest an alternative. The proza below smells like valid information for inclusion in README.vms I am not so sure. Having the VMS_SHARE program installed on VMS is only necessary for folks who will be preparing shdist archives for distribution. The information in README.vms is for folks who will be installing and administering perl on a VMS system. Though that task often includes the unpacking of module or extension distributions (and there is information on where to pick up tar for VMS et alia) it should be noted that a file such as Charles Bailey's on CPAN: authors/id/C/CB/CBAIL/VMS-DCLsym-1_0.share may be unpacked on any VMS V4 or later with the native VMS @ command (@ is analogous to sh or source under csh). Documentation on how to use @ is supplied with the OS's HELP facility as well as on the web, e.g.: http://h71000.www7.hp.com/doc/732FINAL/9996/9996pro_001.html#blue_3 Peter Prymmer P.S. vms_share was on the Freeware 4 CD (but not on 5 or 6). See for example: http://h71000.www7.hp.com/freeware/freeware40/vms_share/
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.25_06
Michael G Schwern [EMAIL PROTECTED] wrote on 12/30/2004 03:55:15 PM: Try out the attached patch. With the patch applied I obtained a bare bones mmk test result: All tests successful, 7 tests and 91 subtests skipped. Files=38, Tests=633, 239 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU) which was done with perl 5.8.5 running on VMS V7.3-2, Compaq C S6.5-002, and MMK V3.9-6. I might even get to my big module collection test with this Peter Prymmer
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.25_07
Michael G Schwern [EMAIL PROTECTED] wrote on 12/31/2004 03:59:29 AM: http://www.pobox.com/~schwern/src/ExtUtils-MakeMaker-6.25_07.tar.gz Test obtained. First using perl 5.8.6 and mmk V3.9-6: All tests successful, 7 tests and 94 subtests skipped. Files=38, Tests=639, 239 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU) Next using perl 5.8.6 and mms V3.2-01: Module will not build. The descrip.mms written out by ExtUtils::MakeMaker::VERSION 6.17 runs into %SYSTEM-F-ACCVIO, access violation and a register dump. I cannot get to MMS TEST. I'll see if installing the mmk built 6.25_07 has any positive effect on helping MMS here. I see that instmodsh was installed: Directory PERL_ROOT:[UTILS] INSTMODSH.;1 Total of 1 file. With that installed a second attempt to build it with mms 3.2-01 still fails with a similar message. I have verified that this MMS can handle rudimentary descrip.mms files. I do not know yet what is causing the trouble. Peter Prymmer
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.25_06
Michael G Schwern [EMAIL PROTECTED] wrote on 12/30/2004 05:22:30 PM: On Thu, Dec 30, 2004 at 04:47:18PM -0500, [EMAIL PROTECTED] wrote: I might even get to my big module collection test with this Wait for the next alpha. I have to fix that IGNORE problem first. Warning: this message contains long lines that may have been wrapped by my MUA at weird places. With ExtUtils::MakeMaker 6.25_07, perl 5.8.6, mmk V3.9-6, and a test case of a slightly modified DBI 1.45 initially I obtain: %MMK-F-CANTUPD, cannot update target MCR - sources unknown $ MCR dga2:[perl-5_8_6_root]perl.exe -MExtUtils::Command -e cp Changes [.blib.lib.DBI]Changes.pm $ MCR dga2:[perl-5_8_6_root]perl.exe -MExtUtils::Command -e cp Roadmap.pod [.blib.lib.DBI]Roadmap.pm cp [.lib.dbd]dbm.pm [.blib.lib.dbd]dbm.pm cp [.lib.win32]dbiodbc.pm [.blib.lib.win32]dbiodbc.pm cp [.lib.dbi]w32odbc.pm [.blib.lib.dbi]w32odbc.pm herein are many completed commands. In a subsequent attempt to simply run mmk in the directory: $ mmk %MMK-F-CANTUPD, cannot update target MCR - sources unknown $ show symbol $status $STATUS == %X1C14805C It appears that it wants to consider MCR as a target for some reason. A run of mmk/log indicates that it wants to update a file called perl.c (itself apparenty derived from perl.xsi). This is beginning to look like a problem with the XSUBPP macros. Contrast the following search (think grep) done to the descrip.mms generated for DBI 1.45 by MakeMaker 6.17: $ sea descrip.mms xsubpp # --- MakeMaker tool_xsubpp section: XSUBPPDIR = perl_root:[lib.ExtUtils] XSUBPP = $(PERLRUN) $(XSUBPPDIR)xsubpp XSUBPPDEPS = perl_root:[lib.ExtUtils]typemap typemap XSUBPPARGS = -typemap perl_root:[lib.ExtUtils]typemap -typemap typemap $(XSUBPP) $(XSPROTOARG) $(XSUBPPARGS) $(MMS$TARGET_NAME).xs $(MMS$TARGET) $(XSUBPP) $(XSPROTOARG) $(XSUBPPARGS) $(MMS$TARGET_NAME).xs $(MMS$TARGET_NAME).c perl.c dbi.c : $(XSUBPPDEPS) Compared to the same search for the 6.25_07 generated descrip.mms file: $ sea descrip.mms xsubpp # --- MakeMaker tool_xsubpp section: XSUBPPDIR = perl_root:[lib.ExtUtils] XSUBPP = $(PERLRUN) $(XSUBPPDIR)/xsubpp XSUBPPDEPS = perl_root:[lib.ExtUtils]typemap typemap $(XSUBPP) XSUBPPARGS = -typemap perl_root:[lib.ExtUtils]typemap -typemap typemap XSUBPP_EXTRA_ARGS = $(XSUBPP) $(XSPROTOARG) $(XSUBPPARGS) $(MMS$TARGET_NAME).xs $(MMS$TARGET) $(XSUBPP) $(XSPROTOARG) $(XSUBPPARGS) $(MMS$TARGET_NAME).xs $(MMS$TARGET_NAME).c dbi.c perl.c : $(XSUBPPDEPS) If I remove the extraneous $(XSUBPP) macro from the XSUBPPDEPS assignment I now obtain: $ mmk MCR dga2:[perl-5_8_6_root]perl.exe perl_root:[lib.ExtUtils]/xsubpp -typemap perl_root:[lib.ExtUtils]typemap -typemap typemap PERL.xs PERL.C Can't open perl script perl_root:[lib.extutils]/xsubpp: file specification syntax error %RMS-F-SYN, file specification syntax error %MMK-F-ERRUPD, error status %X000186D4 occurred when updating target PERL.C If I correct the XSUBPP path like so: --- descrip.mms Fri Dec 31 12:36:21 2004 +++ descrip.mms;-1 Fri Dec 31 12:34:12 2004 @@ -229,7 +229,7 @@ # --- MakeMaker tool_xsubpp section: XSUBPPDIR = perl_root:[lib.ExtUtils] -XSUBPP = $(PERLRUN) $(XSUBPPDIR)xsubpp +XSUBPP = $(PERLRUN) $(XSUBPPDIR)/xsubpp XSPROTOARG = XSUBPPDEPS = perl_root:[lib.ExtUtils]typemap typemap XSUBPPARGS = -typemap perl_root:[lib.ExtUtils]typemap -typemap typemap I now obtain: $ mmk CC/DECC /Include=[]/Standard=Relaxed_ANSI/Prefix=All/Obj=.obj /NOANSI_ALIAS/float=ieee/ieee=denorm_results/Define=(DBI_NO_THREADS,V ERSION=1.45,XS_VERSION=1.45)/Include=(perl_root:[lib.VMS_AXP.5_8_6.CORE])/NoList PERL.c %RMS-F-SYN, file specification syntax error ^ %CC-E-DECLARATOR, Invalid declarator. Which looks like a problem with DBI code not MakeMaker. I hope that provides some useful feedback. Sorry I do not yet have a path for the XSUBPP problems on VMS. Peter Prymmer
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.25_06
[EMAIL PROTECTED] wrote on 12/31/2004 12:41:38 PM: I hope that provides some useful feedback. Sorry I do not yet have a path for the XSUBPP problems on VMS. One other oddity noted with 6.25_07: $ mmk distclean snippage Not in MANIFEST: dbi.opt I am fairly certain that it used to be able to delete the linker options files that it wrote out before. Peter Prymmer
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.25_06
[EMAIL PROTECTED] wrote on 12/31/2004 01:01:12 PM: [EMAIL PROTECTED] wrote on 12/31/2004 12:41:38 PM: I hope that provides some useful feedback. Sorry I do not yet have a path for the XSUBPP problems on VMS. One other oddity noted with 6.25_07: Here is another oddity. The .exists files are being incorrectly thought of as lib elements. With DBI 1.45 and the two descrip.mms edits I mentioned before a clean build now does the following: $ mmk snip If F$Search([.BLIB.ARCH.AUTO.DBI]DBI.OLB).eqs. Then Library/Object/Create [.BLIB.ARCH.AUTO.DBI]DBI.OLB Library/Object/Replace [.BLIB.ARCH.AUTO.DBI]DBI.OLB DBI.OBJ,[.BLIB.ARCH.AUTO.DBI].EXISTS %LIBRAR-W-OPENIN, error opening P:[CPAN_MODULES_586.DBI-1_45.BLIB.ARCH.AUTO.DBI]DBI.EXISTS; as input -RMS-E-FNF, file not found %MMK-F-ERRUPD, error status %X10861098 occurred when updating target [.BLIB.ARCH.AUTO.DBI]DBI.OLB It should probably not try to lib/obj/replace the .exists file since that file is not an .obj. Peter Prymmer
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.25_06
[EMAIL PROTECTED] wrote on 12/31/2004 01:01:12 PM: One other oddity noted with 6.25_07: $ mmk distclean snippage Not in MANIFEST: dbi.opt I am fairly certain that it used to be able to delete the linker options files that it wrote out before. I failed to mention this one before but it appears that both mmk clean and mmk distclean are now deleting the source for the EXE_FILES. Note: $ mmk clean MCR dga2:[perl-5_8_6_root]perl.exe -MExtUtils::Command -e rm_f *.olb perl.c core core.[0-9] [.blib.arch.auto.DBI]extralibs.all core.[0-9][0-9] DBI.bso dbi.c MCR dga2:[perl-5_8_6_root]perl.exe -MExtUtils::Command -e rm_f pm_to_blib.ts core.[0-9][0-9][0-9][0-9] DBI.x DBI.bs perl.exe tmon.out *.obj blibdirs.ts MCR $dga2:[fds0.perl.perl-5_8_6_root]perl.exe -MExtUtils::Command -e rm_f core.[0-9][0-9][0-9][0-9][0-9] *perl.core core.*perl.*.? Makeaperl.MMS DBI.def perl core.[0-9][0-9][0-9] mon.out MCR dga2:[fds0.perl.perl-5_8_6_root]perl.exe -MExtUtils::Command -e rm_f libDBI.def perlmain.c perl.exe [.blib.arch.auto.DBI]extralibs.ld so_locations DBI.exp MCR dga2:[fds0.perl.perl-5_8_6_root]perl.exe -MExtUtils::Command -e rm_rf dbiproxy.pl dbitrace.log ndtest.prt dbiprof.pl snip $ perl Makefile.PL snip Warning: the following files are missing in your kit: dbiprof.pl dbiproxy.pl Please inform the author. snip $ search Makefile.PL EXE_FILES EXE_FILES = [ dbiproxy$ext_pl, dbiprof$ext_pl ], Peter Prymmer
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.25_06
Craig A. Berry [EMAIL PROTECTED] wrote on 12/31/2004 03:34:14 PM:
I think this one is an old problem specific to DBI, and IIRC it's
because it expects dbiproxy.PL to be a different file from
dbiproxy.pl.
Indeed it seems that this is the case. I am sorry for having
reported a spurious problem as though it were MakeMaker's fault.
It would appears that folks on Windows and OS/2 (Mac OS?) would
also have trouble with this case sensitive addition to the
clean target:
$ search makefile.pl dbipr/win
VERSION_FROM= 'DBI.pm',
PREREQ_PM = { Test::Simple = 0.40 },
EXE_FILES = [ dbiproxy$ext_pl, dbiprof$ext_pl ],
DIR = [ ],
dynamic_lib = { OTHERLDFLAGS = $::opt_g },
clean = { FILES= \$(DISTVNAME) Perl.xsi t/zv*_*.t
. dbiproxy$ext_pl dbiprof$ext_pl dbitrace.log
dbi.prof ndtest.prt },
dist = {
DIST_DEFAULT= 'clean distcheck disttest tardist',
Nasty.
Peter Prymmer
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.25_06
[EMAIL PROTECTED] wrote on 12/31/2004 12:41:38 PM:
This is beginning to look like a problem with the XSUBPP macros.
I've found a workwaround for this specific problem that I'll
enclose as a diff. Since an OS specific hack inside of
MM_Unix.pm seems completely counter to the whole put overrides
into MM_$^O.pm design philosophy of MakeMaker I do not expect
this diff to be taken at face value as a patch. I am sending it
merely wanted to illustrate concretely where VMS
was experiencing trouble.
--- lib/extutils/mm_unix.pm;-1 Fri Dec 31 08:48:17 2004
+++ lib/ExtUtils/MM_Unix.pm Fri Dec 31 16:26:34 2004
@@ -3518,6 +3518,18 @@
$self-{XSPROTOARG} = unless defined $self-{XSPROTOARG};
+if ($Is_VMS)
+{
+return qq{
+XSUBPPDIR = $xsdir
+XSUBPP = \$(PERLRUN) \$(XSUBPPDIR)xsubpp
+XSPROTOARG = $self-{XSPROTOARG}
+XSUBPPDEPS = @tmdeps
+XSUBPPARGS = @tmargs
+XSUBPP_EXTRA_ARGS =
+};
+}
+else {
return qq{
XSUBPPDIR = $xsdir
XSUBPP = \$(PERLRUN) \$(XSUBPPDIR)/xsubpp
@@ -3526,6 +3538,7 @@
XSUBPPARGS = @tmargs
XSUBPP_EXTRA_ARGS =
};
+}
};
I have not yet found how to fix the .exists into OLB
problem nor the trouble with MMS V3.2-01 reported earlier.
Peter Prymmer
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.25_06
Craig A. Berry [EMAIL PROTECTED] wrote on 12/29/2004 01:09:58 PM: 4.) The following macro is defined and is used in the shdist target: SHAR = vms_share There is no such native command as vms_share. If I knew more about the intention, I might be able to suggest an alternative. shar on unix was an old time sh(ell) ar(chive) file shareing format that turned a binary into a self extracting shell script. IIRC it used something analogous to uuencoding to keep the shell script into an emailable text format. There was an analog for VMS that would turn binaries into self extracting DCL text files (it called into TPU when needed). While I doubt that: make shdist or: mmk shdist is often used nowadays to prepare somehting for upload to CPAN, I suspect that removing it might adversely affect folks that have to email perl module distributions along 7 bit email relays (admittedly there may not be that many left). I'd not recommend getting rid of the SHAR macro unless it is currently hurting something else. I note that Charles Bailey has a copy of VMS-DCLsym on CPAN in DCL share format, see for example: http://www.cpan.org/modules/by-authors/id/CBAIL/VMS-DCLsym-1_0.share The comments within that file mention the utility used: Using: VMS_SHARE 8.5-1, (C) 1993 Andy Harper, Kings College London UK James Gray, Michael Bednarek It appears that current locations for VMS_SHARE kits include: http://www.tmk.com/ftp/multinet-contributed-software/vms_share/ http://vms.process.com/scripts/fileserv/fileserv.com?VMS_SHARE Peter Prymmer
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.25_01
[EMAIL PROTECTED] wrote on 12/18/2004 08:31:28 AM: On VMS V7.3-2, Compaq C S6.5-002, MadGoat Make Utility V3.9-6, against perl 5.8.1: All tests successful, 7 tests and 87 subtests skipped. Files=36, Tests=603, 156 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU) Later I'll try some exe_files installation tests. While I have not yet completes that task I do have another test report this time with perl 5.8.6: All tests successful, 7 tests and 87 subtests skipped. Files=36, Tests=603, 137 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU) Which I suppose is better than the failures of: lib/ExtUtils/t/basic..FAILED at test 2 snip lib/ExtUtils/t/prereq_print...FAILED at test 2 Seen with the build and `mmk test` of the perl 5.8.6 kit. Peter Prymmer
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.25_01
Michael G Schwern [EMAIL PROTECTED] wrote on 12/17/2004 09:41:47 PM: http://svn.schwern.org/svn/CPAN/ExtUtils-MakeMaker/trunk or svn://svn.schwern.org/CPAN/ExtUtils-MakeMaker/trunk or http://www.pobox.com/~schwern/src/ExtUtils-MakeMaker-6.25_01.tar.gz or a CPAN near you. Kicked out an alpha release of MakeMaker because I made a large wad of code changes and want it kicked around. On VMS V7.3-2, Compaq C S6.5-002, MadGoat Make Utility V3.9-6, against perl 5.8.1: All tests successful, 7 tests and 87 subtests skipped. Files=36, Tests=603, 156 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU) Later I'll try some exe_files installation tests. Peter Prymmer
Re: [PATCH] Detecting strlcat() and strlcpy() in Configure
H.Merijn Brand [EMAIL PROTECTED] wrote on 11/01/2004 09:57:06 AM: On Sat 30 Oct 2004 19:42, H.Merijn Brand [EMAIL PROTECTED] wrote: On Fri 29 Oct 2004 04:58, Steve Peters [EMAIL PROTECTED] wrote: Since I don't know what VMS actually has, and configure.com doesn't have commented out lines, I'd like to know what to do for that Part 4 - epoc, and djgpp, and Part 5 - Porting/* Part 5 is now also done (#23450, #23455 and #23457) I'd still would muchly appreciate some comments on my VMS question $ cc /ver Compaq C S6.5-002 on OpenVMS Alpha V7.3-2 and it does not have any strl* functions in it's CRTL. But they may be added at some time. We could add tests to configure.com and that might help with the extraction of config.h from config_h.SH, but I have to admit to not having built bleed on VMS in quite a while, so if Craig Berry chimes in with something it superseded what I've said here. I'll see about syncing out the latest bleed Peter Prymmer
Re: [PATCH] readdir_r for VMS (was Re: [PATCH] configure.com: sig_num, etc.)
Craig Berry wrote: !To really stress test this with multiple threads going after the same !directory stream I'd need an SMP machine to test on, which I don't have. !But I think we are at least somewhat safer than we were before. Can you specify which thread option to configure.com to use? Also: has anyone made a tar ball out of [EMAIL PROTECTED] (or something later that incorporates your patch) that is accessible via either anon ftp or http? I could give it a try on an SMP machine. Is there any ad hoc testing to try? Peter Prymmer
Re: ext/Encode/t/perlio on VMS (was Re: perl@16539)
Dan the Encode Maintainer wrote: !-ST(0) = PL_sv_no; !+/* ST(0) = PL_sv_no; */ !+ST(0) = PL_sv_yes; ! XSRETURN(1); ! } ! !Even if it works, I do not consider this to be a radical cure. But a !cure nonetheless ! !BTW, what is the most concise way to check the architecture FROM XS? FWIW: #ifdef VMS #endif should do the trick (although in subsequent discussion it looks like Nick nixed the idea of changing Encode.xs). Peter Prymmer
