Re: [ANNOUNCE] ExtUtils::MakeMaker 6.25_10
Michael G Schwern wrote: http://www.pobox.com/~schwern/src/ExtUtils-MakeMaker-6.25_10.tar.gz or http://svn.schwern.org/svn/CPAN/ExtUtils-MakeMaker/trunk or a CPAN near you Its another release candidate. This one fixes the recompilation problem noted in the last release (and various previous ones). Knock it around. The Good News: All tests OK on WinXP/VC++ using nmake and (my new) dmake with both perl-5.8.6 and bleadperl. libwin32 builds OK too (which it didn't with 6.25_08). The Bad News: Tk (804.027) doesn't build: C:\Temp\Tk-804.027nmake Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. NMAKE : fatal error U1071: cycle in dependency tree for target 'pm_to_blib' Stop. Can you reproduce this on some OS that you have, or do you want me to send in the Makefile's that were written? - Steve Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
Re: Module::Install and portability?
Michael G Schwern [EMAIL PROTECTED] wrote on 03/13/2005 06:34:27 PM: As mentioned here, I want to break up MakeMaker. http://www.makemaker.org/wiki/index.cgi?ModulesForSale There's a number of modules which are just utilities MakeMaker uses and I want them out in their own distribution. But I have to be careful not to introduce a circular dependency. So ideally MakeMaker would continue to come bundled with its own copies of those modules. This looks like a job for Module::Install! The question is, how portable is it? And what's the minimum version of Perl it will run on? I didn't have any luck with Module::Install under OpenVMS/AXP 7.1-1. It does a fair amount of direct manipulation of @INC in ordinary circumstances, and even more on the install, because it tries to bootstrap itself from its own blib directory. Specifically, it makes the assumption that it can push (e.g.) 'blib' on the stack and have it be interpreted as that 'blib' which is a subdirectory of the current directory. This doesn't work under VMS, where what you want is '[.blib]'. I tried some desultory conditionalizing on $^O, but never really got anywhere. The real problem may have been that, as badly as I personally wanted to install Net::LDAP and reset peoples' Windows passwords under VMS, I couldn't justify to myself spending my employers' time on it. My bottom line is that Module::Install requires filename semantics not too far from those of Unix, and while (e.g.) Windows is close enough, VMS isn't by a long shot. Tom Wyant This communication is for use by the intended recipient and contains information that may be privileged, confidential or copyrighted under applicable law. If you are not the intended recipient, you are hereby formally notified that any use, copying or distribution of this e-mail, in whole or in part, is strictly prohibited. Please notify the sender by return e-mail and delete this e-mail from your system. Unless explicitly and conspicuously designated as E-Contract Intended, this e-mail does not constitute a contract offer, a contract amendment, or an acceptance of a contract offer. This e-mail does not constitute a consent to the use of sender's contact information for direct marketing purposes or for transfers of data to third parties. Francais Deutsch Italiano Espanol Portugues Japanese Chinese Korean http://www.DuPont.com/corp/email_disclaimer.html
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.25_10
On Mon, Mar 14, 2005 at 10:04:24AM +, Steve Hay wrote: The Bad News: Tk (804.027) doesn't build: C:\Temp\Tk-804.027nmake Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. NMAKE : fatal error U1071: cycle in dependency tree for target 'pm_to_blib' Stop. Can you reproduce this on some OS that you have, or do you want me to send in the Makefile's that were written? It works fine on OS X, so yes, please send the Makefiles. Don't even wait to ask, always send the Makefiles.
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.25_10
On Mon, Mar 14, 2005 at 10:04:24AM +, Steve Hay wrote: The Good News: All tests OK on WinXP/VC++ using nmake and (my new) dmake with both perl-5.8.6 and bleadperl. libwin32 builds OK too (which it didn't with 6.25_08). The Bad News: Tk (804.027) doesn't build: C:\Temp\Tk-804.027nmake Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. NMAKE : fatal error U1071: cycle in dependency tree for target 'pm_to_blib' Stop. Could you try that with the old nmake? 1.5 I think. The one pointed at in the MakeMaker README.
Re: Module::Install and portability?
On Mon, Mar 14, 2005 at 08:46:12AM -0500, Thomas R Wyant_III wrote: I didn't have any luck with Module::Install under OpenVMS/AXP 7.1-1. It does a fair amount of direct manipulation of @INC in ordinary circumstances, and even more on the install, because it tries to bootstrap itself from its own blib directory. Specifically, it makes the assumption that it can push (e.g.) 'blib' on the stack and have it be interpreted as that 'blib' which is a subdirectory of the current directory. This doesn't work under VMS, where what you want is '[.blib]'. What about ./blib? That should work, IIRC.
Re: Module::Install and portability?
On Monday, March 14, 2005, at 12:10PM, Michael G Schwern [EMAIL PROTECTED] wrote: On Mon, Mar 14, 2005 at 08:46:12AM -0500, Thomas R Wyant_III wrote: I didn't have any luck with Module::Install under OpenVMS/AXP 7.1-1. It does a fair amount of direct manipulation of @INC in ordinary circumstances, and even more on the install, because it tries to bootstrap itself from its own blib directory. Specifically, it makes the assumption that it can push (e.g.) 'blib' on the stack and have it be interpreted as that 'blib' which is a subdirectory of the current directory. This doesn't work under VMS, where what you want is '[.blib]'. What about ./blib? That should work, IIRC. Yes, it should, but so should blib. I'm not convinced this is the real issue, but not sure when I'll get a chance to dig into it myself.
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.25_10
On 2005-03-13, at 16:17:13 -0800, Michael G Schwern wrote: http://www.pobox.com/~schwern/src/ExtUtils-MakeMaker-6.25_10.tar.gz or http://svn.schwern.org/svn/CPAN/ExtUtils-MakeMaker/trunk or a CPAN near you Its another release candidate. This one fixes the recompilation problem noted in the last release (and various previous ones). Knock it around. Works fine for me this time! :-) Marcus -- Any given program, when running, is obsolete.
Re: ExtUtils::CBuilder on VMS (was Re: Phalanxing MakeMaker)
Ken Williams [EMAIL PROTECTED] wrote on 03/12/2005 10:35:22 PM:
On Mar 12, 2005, at 7:18 PM, Ken Williams wrote:
Excellent. I just have one question, then, about the following line:
my @lddlflags = $args{lddl} ? ($cf-{lddlflags}.=$out) :
(/exe=$out);
What is the original value of $cf-{lddlflags} such that it makes
sense to just append =$out to it?
Scratch that, I think I see how it works.
Care to try the 0.09_02 revision, hitting CPAN now?
OK that one is much close to what I thought you were aiming at :-)
It turns out there was an override typo in VMS.pm and t/02-link.t
was left as is. This time around I have checked the return $STATUS
of the compilet program in a vmsish fashion, that was done so as
not to hurt the successful run on Solaris (where vmsish.pm is not
installed and this might be considered a bug in the installperl script
that ships with perl).
Here is a patch against 0.09_02 that addresses
both issues and passes both tests on VMS + perl 5.8.1 and
Solaris + perl 5.6.1:
diff -ru ExtUtils-CBuilder-0_09_02_orig/lib/ExtUtils/CBuilder/Platform/VMS.pm
ExtUtils-CBuilder-0.09_02/lib/ExtUtils/CBuilder/Platform/VMS.pm
--- ExtUtils-CBuilder-0_09_02_orig/lib/ExtUtils/CBuilder/Platform/VMS.pm
2005-03-12 22:28:29.0 -0500
+++ ExtUtils-CBuilder-0.09_02/lib/ExtUtils/CBuilder/Platform/VMS.pm
2005-03-14 12:40:24.628116000 -0500
@@ -25,7 +25,7 @@
return (/exe=$file);
}
-sub arg_shared_object_file {
+sub arg_share_object_file {
my ($self, $file) = @_;
return ($self-{config}{lddlflags}=$file);
}
diff -ru ExtUtils-CBuilder-0_09_02_orig/t/02-link.t
ExtUtils-CBuilder-0.09_02/t/02-link.t
--- ExtUtils-CBuilder-0_09_02_orig/t/02-link.t 2005-03-12 22:28:29.0
-0500
+++ ExtUtils-CBuilder-0.09_02/t/02-link.t 2005-03-14 14:14:44.794097000 -0500
@@ -7,6 +7,10 @@
print 1..0 # Skipped: link_executable() is not implemented yet on
Win32\n;
exit;
}
+ if ($^O eq 'VMS') {
+require vmsish;
+import vmsish;
+ }
plan tests = 5;
}
@@ -35,8 +39,14 @@
ok $exe_file;
# Try the executable
-my $retval = system($exe_file);
-ok $retval 8, 11;
+if ($^O eq 'VMS') {
+ my $retval = system(mcr $exe_file);
+ ok $retval, 11;
+}
+else {
+ my $retval = system($exe_file);
+ ok $retval 8, 11;
+}
# Clean up
for ($source_file, $exe_file, $object_file, @temps) {
End of Patch.
For what it is worth in answer to the first of your questions:
$ perl -V:lddlflags
lddlflags='/Share';
Peter Prymmer
Also see the attachment (to disambiguate line wrap issues):
(See attached file: ec.patch)
ec.patch
Description: Binary data
Re: ExtUtils::CBuilder on VMS (was Re: Phalanxing MakeMaker)
On Mar 14, 2005, at 1:30 PM, [EMAIL PROTECTED] wrote: OK that one is much close to what I thought you were aiming at :-) It turns out there was an override typo in VMS.pm and t/02-link.t was left as is. Oops! That was me forgetting to apply the 02-link.t part of the patch. This time around I have checked the return $STATUS of the compilet program in a vmsish fashion, that was done so as not to hurt the successful run on Solaris (where vmsish.pm is not installed and this might be considered a bug in the installperl script that ships with perl). Here is a patch against 0.09_02 that addresses both issues and passes both tests on VMS + perl 5.8.1 and Solaris + perl 5.6.1: Thanks, applied verbatim (except that I moved the system() call into a my_system() subroutine in case I want to use it again later). -Ken
