[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Porting m4 to z/OS
Re: Porting m4 to z/OS
Wed, 30 Jul 2008 06:34:23 -0600
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:184.108.40.206) Gecko/20080708 Thunderbird/220.127.116.11 Mnenhy/0.7.5.666
-----BEGIN PGP SIGNED MESSAGE-----
According to David Crayford on 7/30/2008 6:23 AM:
| ouch... This ones tough! I want to port m4 to z/OS. It's been done
| before but not thoroughly ftp://ftp.mks.com/pub/s390/gnu/.
| Of course, my motivation is really to port the GNU build chain, of which
| m4 is an intrinsic part. Our goal is to port:
| -autoconf 2.61
Why not 2.62?
| -automake 1.10.1
| -m4 1.4.10
Why not 1.4.11?
| -gmake 3.8.1
| -libtool 2.2.4
| -gzip 1.3.12
| What I have found is that porting m4 is non-trivial on an EBCDIC
| platform. I understand that the industry has spoken and
| ASCII and it's successors are the dominant forces, but please take pity
| on us poor EBCDIC sufferers!
| IBM made a good start porting GNU tools to the mainframe back in 2001
| with the help of mks. There's a site of ported
| tools which is now starting to look geriatric
| The port of m4 was, AFAIK, the base code. It's now time to update the
| GNU tool chain on z/OS.
| EBCDIC is the big issue, m4 relies on the ASCII collating sequence. This
| was true with the original cut and has become
| even more prevalent with each new release. I'm thinking it's a good idea
| for us to maintain a separate patch for EBCDIC?
Submit the patches here, and if they are easy to maintain, I have no
objection to including them upstream. No need to fork a separate patch if
they are not a maintenance nightmare.
| What's choking the port right now is the expand_ranges function. I can
| easily patch it by converting EBCDIC to ASCII and
| then back again
But is that correct? Right now, the M4 manual documents that the use of
ranges within the translit operator is byte-encoding dependent, and that
m4 code intended to be portable to EBCDIC should not use ranges in translit.
| but I'm not sure if I quite understand how it's supposed
| to work.
What's wrong with the current interpretation of a range of consecutive
bytes? (other than the obvious fact that in EBCDIC, the range of bytes
a-z includes more than 26 letters). I'm not sure that transliterating to
ASCII, doing a range, then transliterating back to EBCDIC is necessarily
the correct approach.
| For example, take the following autoconf
| m4_translit(AC_Header, [./-], [___])
| Does m4_translit treat the [./-] - as a range?
No, because '-' is at the end of the string, rather than the middle. To
my knowledge, expand_ranges should NOT be triggered by autoconf code; if
it is, that should be reported to the autoconf list, so that we can
rewrite the m4_translit there.
| Right now it's mangling
| the headers. What I'm looking for is a fast start,
| what version of m4 is compatible with autoconf 2.61?
m4 1.4.5 through m4 1.4.11.
| Where are the
| ASCII-EBCDIC hot spots?
In m4, hopefully only the translit builtin (and then, only if you use
ranges), and possibly the regexp/patsubst builtins.
| Any help will be warmly received...
Don't work too hard, make some time for fun as well!
Eric Blake address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----