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.26_01
On Tue, Mar 29, 2005 at 02:43:42PM -0500, [EMAIL PROTECTED] wrote:
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)
snip
If that is of any help.
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?
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
sub makefile_backup {
my $makefile = makefile_name;
-return $Is_VMS ? $makefile : $makefile.old;
+return $Is_VMS ? ${makefile}_old : $makefile.old;
}
Thanks.
But in any case the tests all pass on VMS with or without that patch in place.
Now that's unexpected. VMS works but Solaris didn't.
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.26_01
Michael G Schwern wrote: Mark Leighton Fisher noticed that PL_FILES weren't working properly anymore. Just to set the record straight -- Mike Castle spotted the PL_FILES problem with my module, Test::MockDBI. Mike informed me, so I as the Test::MockDBI developer informed the EU::MM list et.al. Mark Leighton Fisher http://www.fisherscreek.com [EMAIL PROTECTED]317-223-3211
OpenVMS behavior options - (was: [ANNOUNCE] ExtUtils::MakeMaker 6.26_01)
[Replies set to vmsperl@perl.org, as it is the only list I am subscribed to]
Michael G Schwern wrote:
On Tue, Mar 29, 2005 at 02:43:42PM -0500, [EMAIL PROTECTED] wrote:
But in any case the tests all pass on VMS with or without that patch in place.
Now that's unexpected. VMS works but Solaris didn't.
Which makes this a point to bring up some VMSisms that some people
including OpenVMS Perl programmers may not be aware of.
There are also some changes that I am currently testing on the side that
will potentially affect any Perl module that has OpenVMS specific code
in it. They can be turned on and off as needed, but I would like to be
able to eventually pass the self tests supplied with Perl with these
features set.
MM_UNIX is one of the ones potentially affected. I am not yet good
enough at reading Perl scripts to tell.
Some background:
The behavior of the OpenVMS C runtime library is dependent on feature
logicals which control how many things work.
But with these feature logicals set, which perl scripts can check
through the ENV{} operator, the C RTL features of OpenVMS can change to
behaving more like UNIX and less like traditional OpenVMS.
The way that Perl is currently implemented, changing these feature
logicals from their default is almost certainly guaranteed to have bad
results. This is because in many cases some of the C filename parsing
is bypassed for the support of older versions of OpenVMS.
As part of what I am doing to implement Symbolic link support on
OpenVMS, it requires that to use Symbolic links, the C feature logicals
and VMS environment settings need to be honored by the PERL executable.
The plus side of this is that it will allow Perl on OpenVMS 8.2 (Alpha
and I64), and to a lesser extent older versions of OpenVMS on Alpha to
run many scripts that are expecting UNIX behavior that currently will
not run.
Many of these scripts are used in the building of programs on UNIX, and
having them work unmodified on OpenVMS would be goodness for all.
The unfortunate side effect is that when these features are set to a
UNIX compatible mode, any perl scripts that are expecting traditional
VMS behavior with out requesting a filename converted explicitly to VMS
format on VMS may break.
I hope that you will pardon my lack of Perl Script programing experience
on these explanations, and for brevity, I am simplifying things, but
some of the things that are optional are:
1. Treat all filenames as UNIX syntax. No VMS file specifications are
permitted.
2. Accept VMS or UNIX file specifications, but always report them as
UNIX type.
With either the above two enabled, the .dir on OpenVMS directories
vanishes from returned file specifications, which may be something that
impacts MM_UNIX as noted above. Also unless a VMS specific conversion
is requested, a returned file is likely to be in UNIX format and as
noted below in the correct case, and also may include UNICODE or other
characters that normally are not in a VMS file specification.
It certainly affects the standard tests that are supplied with Perl.
3. Case preserved filenames. Filenames will be created with the case
that the application specified them in and reported that way. This
requires that the files are on an ODS-5 file system or later.
This also affects the standard tests.
4. Case sensitive filenames. Unlike the others, this is not set by a
feature logical, but a VMS environment setting. I noticed in Perl that
it was able to inquire if a platform was case sensitive, and I changed
my local copy of Perl to report the process setting that is currently in
effect. I have not tested that mode yet. This also requires ODS-5
filesystem or later.
In my current development phase, these feature settings are only checked
at the startup of perl, and changing the ENV{} after that point may have
strange side effects.
There are some others, like the handling of umask() which can be
predicted or affected by the ENV{} for that value.
Also for the OpenVMS C runtime to effectively work with Symbolic links,
the option of 2 above needs to be set, and effectively at least the
option of 3 above also.
I have also noticed that some Perl scripts are assuming that / is a
directory separator for things like ENV{'HOME'} and 'PERL5DB'. When the
mode 1 or 2 above is set, those will work on OpenVMS, where now they do not.
-John
[EMAIL PROTECTED]
Personal Opinion Only
Re: OpenVMS behavior options - (was: [ANNOUNCE] ExtUtils::MakeMaker 6.26_01)
On Tue, Mar 29, 2005 at 09:34:09PM -0500, John E. Malmberg wrote:
The behavior of the OpenVMS C runtime library is dependent on feature
logicals which control how many things work.
But with these feature logicals set, which perl scripts can check
through the ENV{} operator, the C RTL features of OpenVMS can change to
behaving more like UNIX and less like traditional OpenVMS.
The way that Perl is currently implemented, changing these feature
logicals from their default is almost certainly guaranteed to have bad
results. This is because in many cases some of the C filename parsing
is bypassed for the support of older versions of OpenVMS.
Thanks for all that information.
The problem effects not only VMS but Unixen as well. It stems from the
problem of Perl programs assuming that because you are on Operating System
X you will be using Filesystem Y. For example, most programs assume that
when you run on Unix you're going to have case-sensitive filenames. Run
the Perl test script on Linux in a FAT filesystem and things will go
awry.
The issue is to not assume operating system or file system attributes
based solely on the value of $^O or even %Config options. You also don't
want to user to have to look at %ENV and be an expert in VMS esoteria to
figure out what the right thing is to do.
To that end I've devised a strategy which does platform-independent probes
to figure out what works and what doesn't. For example, figuring out if
you're on a case sensitive or insensitive filesystem is pretty easy.
1. Write out SoMeFiLe with the contents foo
2. Write out sOmEfIlE with the contents bar
3. If SoMeFiLe contains foo you are case sensitive.
To determine if you're case preserving...
4. Do a readdir and look for /^somefile$/i.
4a. If you get back sOmEfIlE you are case preserving.
4b. If you get back somefile you are non-case preserving with downcasing.
4c. If you gete SOMEFILE you are non-case preserving with upcasing.
You can devise these sorts of probes for all sorts of different attributes.
How long can a filename be? Is the dot special? How many directories
deep can I go? How long a command can I execute? Do I have symlinks?
Hard links? Can I fork?
There are various optimization techniques and ways to deal with multiple
mounted partition types as well as when they change, but the basic technique
of probing the actual runtime system rather than make assumptions based
on the OS or %Config from when Perl was built is the important part. Then
the user can simply query a FileSystem object to find out this information.
I've wanted this sort of thing for MakeMaker for a very long time and
someday I'll get around to coding it.
