public at khwilliamson
Nov 26, 2009, 9:45 AM
Post #11 of 13
(360 views)
Permalink
|
|
Re: PATCH: Makefile patches for mktables; wrap uniprops.t
[In reply to]
|
|
And, there is a patch for the vms makefile that came after the mktables
version you've been using. I'm not sure if it's correct, but it's
better than what was there previously.
karl williamson wrote:
> Craig A. Berry wrote:
>> On Wed, Nov 25, 2009 at 5:19 AM, Nicholas Clark <nick [at] ccl4> wrote:
>>> On Tue, Nov 24, 2009 at 06:47:43PM -0500, Eric Brine wrote:
>>>> On Tue, Nov 24, 2009 at 4:26 PM, karl williamson
>>>> <public [at] khwilliamson>wrote:
>>>>
>>>>> As I'm sending this, I'm wondering if my wrap is correct. I just
>>>>> did a
>>>>> 'do path', with slashes in the path. Maybe only a 'require' can use
>>>>> slashes portably.
>>>>>
>>>> Windows has no problems with forward slashes. Dunno about VMS.
>>
>> For any Perl file operation I'm aware of, Unix syntax is fine on VMS.
>> But pedantically speaking, C<require> is a Perl module operation not a
>> Perl file operation, and there's no particular reason that some
>> as-yet-undreamed-of implementation might not store Perl modules in a
>> database or use an object-oriented spoon to retrieve them from the
>> object soup du jour, or whatever. C<do EXPR>, however, is explicitly
>> a file operation and IIRC, both C<do> and C<require> are currently
>> implemented via Perl_pp_require(), which uses standard PerlIO
>> functions to open files in the filesystem.
>>
>>> I'm not Craig Berry
>>
>> Count your blessings, young man :-).
>>
>>> (or John E. Malmberg or one of various other people who
>>> really do know this stuff), but from my experience of Trying Not To
>>> Break It,
>>> *perl* on VMS will usually cope quite happily with a "Unix" pathname,
>>> and
>>> translate it to native.
>>>
>>> Provided one isn't invoking external programs, and one isn't using
>>> "strange"
>>> characters in filenames, most everything we need to do whilst
>>> building perl
>>> can be done with Unix-style pathnames with forward slashes on every
>>> platform.
>>> (As far as I can remember)
>>
>> This is a pretty good summary. There are wrinkles of course, like the
>> the fact that multiple dots in a filename count as strange characters
>> under some circumstances but not others. E.g.,
>> ../dist/base/t/fields-5.6.0.t doesn't work without non-default
>> environment settings but [-.dist.base.t]fields-5.6.0.t does.
>>
>> And there are still plenty of ways to get into trouble. The common
>> practice of using the filesystem as a database with the filenames as
>> mixed-case primary keys doesn't work because filename case is not (by
>> default) preserved. Also note that the File::Spec functions typically
>> return values in native syntax, so operating directly on slashes after
>> a return from those functions isn't likely to do what you expect.
>>
>> Most likely one or both of the gotchas described in the previous
>> paragraph are involved in the fact that the new mktables breaks the
>> build on VMS (see below). I'll try to have a look soonish but it's a
>> 14,000-line program and I've got a big system conversion keeping me
>> busy this holiday weekend.
>
> Hopefully, this will save you some work. Those line numbers tell me
> you're not using the very latest patch on this; The 'Failed to open'
> message is expected, the first time, and is based on a change to what we
> do with mktables.lst after I delivered; I'll look into doing something
> about it. I believe that the line 13552 messages have already been
> fixed in a later patch. The undefined subroutine turns out to be a real
> problem to output a warning message, in a previously unexercised leg. It
> should be 'join_lines'. I'll submit a patch, but I expect things to
> work much better if you get all the current patches and try again.
>
>>
>> MCR Sys$Disk:[]miniperl.exe "-I[.lib]" "-I[.cpan.Cwd]"
>> "-I[.cpan.Cwd.lib]" [.lib.unicore]mktables "-C" [.lib.unicore] "-P"
>> [.pod] "-makelist" "-maketest" "-p"
>>
>> [.lib.unicore]mktables: Failed to open 'mktables.lst', turning on
>> -globlist
>> option instead: no such file or directory; at
>> [.lib.unicore]mktables line 13472
>> Use of uninitialized value in string ne at [.lib.unicore]mktables line
>> 13552.
>> Use of uninitialized value in string ne at [.lib.unicore]mktables line
>> 13552.
>> Use of uninitialized value in string ne at [.lib.unicore]mktables line
>> 13552.
>> <many of the same snipped>
>> Use of uninitialized value in string ne at [.lib.unicore]mktables line
>> 13552.
>> Use of uninitialized value in string ne at [.lib.unicore]mktables line
>> 13552.
>> Undefined subroutine &main::join_line called at [.lib.unicore]mktables
>> line 13564.
>>
>
|
0002-further-windows-makefiles-fixes.patch
