Re: Porting m4 to z/OS

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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
| http://www-03.ibm.com/servers/eserver/zseries/zos/unix/redbook/index.html.
| 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
| code:
|
| 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             [email protected]
-----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

iEYEARECAAYFAkiQX88ACgkQ84KuGfSFAYAzAQCdEKcvQ8IODQt8+g42c8bI9h4z
KyEAni2WRUR0s9hYP/d5YbNMLrtVnUR8
=MKMW
-----END PGP SIGNATURE-----