PATCH: Makefile patches for mktables; wrap uniprops.t
Karl Williamson
branch is 'make'.
It looks to me like Steve's windows smoker would still be trying to run
mktables (ever-so-slowly) every time, and hopefully this fixes that.
I started with Rafael's patches, and grepped through the source for any
mention of mktables or the files I removed, and then patched things as
best as I can guess for vms and windows. I also patched the Cross
makefile, which looks more like the ones I'm familiar with. However
there is a Makefile.SH.patch in that directory that I have no idea what
to do with.
I changed t/re/uniprops.t to just be a wrapper for the generated test
file, which I went back to the old name for: TestProp.pl, left in the
same directory as mktables. I changed the makefile to correspond,
adding it and mktables.lst to the dependencies.
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.
Eric Brine
> 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.
Steve Hay
> Attached is a patch for these things. It looks to me like Steve's
> windows smoker would still be trying to run mktables (ever-so-slowly)
> every time, and hopefully this fixes that.
>
mention
> of mktables or the files I removed, and then patched things as best as
I
> can guess for vms and windows.
From a quick look at the changes to the Win32 makefiles in your patch,
it looks like you've not updated UNIDATAFILES in win32/Makefile, you've
missed TestProp.pl from UNIDATAFILES in win32/Makefile.ce, and you've
not updated the mktables command-line arguments in win32/makefile.mk.
Nicholas Clark
I'm not Craig Berry (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)
Nicholas Clark
Karl Williamson
probably should have taken a break and come back to it not so bleary-eyed.
Here's a patch for the things you mentioned, also pushed to
git://github.com/khwilliamson/perl.git,
branch make
Steve Hay
> Attached is a patch for these things. It looks to me like Steve's
> windows smoker would still be trying to run mktables (ever-so-slowly)
> every time, and hopefully this fixes that.
>
> I took Rafael's patches, and grepped through the source for any
mention
> of mktables or the files I removed, and then patched things as best as
I
which
> looks more like the ones I'm familiar with. However there is a
> Makefile.SH.patch in that directory that I have no idea what to do
with.
>
> I changed t/re/uniprops.t to just be a wrapper for the generated test
> file, which I went back to the old name for: TestProp.pl, left in the
> same directory as mktables. I changed the makefile to correspond,
> adding it and mktables.lst to the dependencies.
>
a
> 'do path', with slashes in the path. Maybe only a 'require' can use
> slashes portably.
Thanks, applied as dd942ab019ac5630d7e06b835a1377c56943a35d, and applied
your (off-list) patch for my Win32 makefiles comments as
3060357dad64d4573f46d88af24707468f4e742d.
Not sure if it will make my smokes any quicker, though, because
Test-Smoke does a 'clean' inbetween each configuration that it builds &
tests, which will remove all files generated by mktables anyway. (Or
have I misunderstood what you meant?)
Karl Williamson
I'm afraid the clean will remove them. I don't know what the
consequences would be of changing so they don't clean unless it is a
'real or 'very', I'm not sure which is which.
Karl Williamson
by the various functions. I concluded from that that you couldn't have
a slash in the path, for it would be sent to the OS with a slash in it.
Craig A. Berry
> On Tue, Nov 24, 2009 at 06:47:43PM -0500, Eric Brine wrote:
>> On Tue, Nov 24, 2009 at 4:26 PM, karl williamson <pub...@khwilliamson.com>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.
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.
Karl Williamson
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.
Karl Williamson
version you've been using. I'm not sure if it's correct, but it's
better than what was there previously.
Craig A. Berry
<pub...@khwilliamson.com> wrote:
> Craig A. Berry wrote:
>> 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.
This was with 17cc9359ea8ee1b546aa067b91362160e3c1e1ee. As I write I
only see 3 commits since then, none affecting mktables, but I haven't
reviewed the list for unapplied patches.
Karl Williamson
3df51b85ce4a56647cf991297e3b51b9dffe4414
the one for mktables:
f86864acbf97469fd9e5d5233d51ff743f4d8d6e
Nicholas Clark
> On Wed, Nov 25, 2009 at 5:19 AM, Nicholas Clark <ni...@ccl4.org> wrote:
> > 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.
The irony of this is that it can actually be *more* portable to eschew
File::Spec and simply manipulate all filenames internally "Unix" style with
forward slashes as directory separators.
Provided
1: your paths don't go outside perl
2: you don't fall foul of any of the subtleties Craig describes.
But this is actually how the build scripts (certainly make_ext.pl) work.
Nicholas Clark