Re: gnu utilities for MVS and CMS

[Eric Blake]

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

According to Paul Edwards on 2/4/2009 1:44 PM:
> MVS is on the list of recognized platforms:
>>
>> $ ./build-aux/config.sub mvs
>> i370-ibm-mvs
> 
> Which particular MVS compiler is that though?  One that supports
> Unix extensions or one that only supports C89?  I'm using the latter.

I think you misunderstand what I was getting at.  Your _platform_ is
recognized as a named porting target, not your current _compiler_ which is
installed on that platform.  But to be successful in porting GNU software
to your platform, you will have to figure out how to get ./configure
scripts to run, either natively, from a cross-compilation environment, or
by hand, because most GNU packages depend on the output of their configure
script to learn about features of the current system, rather than
consulting a potentially outdated database of platform capabilities.

> 
>> What version of bash are you using, and from where did you get it?  I
> 
> C:\devel\m4x>bash --version
> GNU bash, version 3.2.25(17)-release (i686-pc-cygwin)
> Copyright (C) 2005 Free Software Foundation, Inc.

That seems reasonable, so it is now up to you to figure out why configure
is not finding install-sh.  Another thing to consider - why not run
configure on your MVS machine for a native build, rather than trying to
run it on Windows for a cross-compile build?  If MVS has a reasonably
portable sh implementation, then that would be the way to go.

> And I've already reported to the appropriate people that the
> C compiler environment that comes with Cygwin is not
> C89-compliant because it pollutes the namespace with
> Unix stuff like "open" etc (can't remember which specific
> one I reported).  No-one was interested in providing a C89
> compliant compiler.

I think you have a slight misunderstanding here.  The way I see it, no one
on the cygwin list cared about the lack of a _free-standing_ C89
environment, at least, not enough to contribute patches.  But C89 allows
for extensions in _hosted_ environments, and a POSIX system which pollutes
the namespace with extensions like "open" can still qualify as a C89
compliant compilation environment, albeit no longer a strict free-standing
environment.

> 
> m4 1.4 which works for me, is 318k.  m4 1.4.12 which doesn't, is 1,169k.

m4 1.4 predates gnulib, and while it may compile on lots of systems, it
violates lots of POSIX-compliance rules in its behavior.  m4 1.4.12 uses
gnulib to guarantee POSIX behavior, even on platforms that are not
POSIX-compliant.  This is not bloat - if platforms would implement the
standards correctly, then gnulib wouldn't have to ship so much source
code.  And note that this goal of providing POSIX behavior necessarily
implies that your system has some notion of POSIX extensions (although the
fact that m4 compiles on mingw proves that your system can be very
non-compliant while still getting POSIXy behavior out of m4).

> 
> I would argue that if the tar ball is going to be so massively bloated,
> it can afford to keep a copy of the C89 code, for instant portability
> to C89 systems.

You still misunderstand how projects that use gnulib actually works.  All
of gnulib is designed to be compiled with a C89 compiler, once you have
successfully completed a ./configure run.  Configure does two things - it
defines a set of #defines in config.h that control how the various gnulib
source files compile.  And it defines a set of sed scripts, run by the
makefile, which turn foo.in.h header templates into replacement header
files.  The sed scripts replace @BLAH@ constructs with the appropriate
value.  So your complaint about @ in the m4 source code means that you
have not yet run the sed scripts via the Makefile, which in turn are
difficult to run until after you have completed ./configure.  Don't even
bother worrying about portability problems in the other files in the
distribution until you have completed the configuration step.

> I guess it's just a case of a different philosophy.  I like and expect
> C89-compliant code to be provided so that all I need to do is zip
> up some files,

It sounds like what you are asking is for some pre-configured files for a
free-standing C89 environment.  But GNU software does not go out of the
way to target free-standing environments - it is much easier to develop
code when we can rely on hosted environments, with POSIX and other
extensions above and beyond what C89 guarantees.  There is a difference
between limiting yourself to only the functions guaranteed by C89 (m4 does
not do this, nor do I want to bend over backwards trying to do so), and
limiting yourself to the features guaranteed by a C89 compiler (m4 does
this; if you have a C89 compiler that can't compile m4 after a successful
./configure run, then that is a bug we need to fix).

> These extra hoops are similar to
> running an ANSI2K&R translator on an alien system because
> the compiler you actually have is not C89-compliant, only
> K&R.

At one point, GNU projects still promised K&R compilation.  But that day
has come and gone; C89 is 20 years old now, so within the past 5 years, we
quit trying to support K&R compilers as a waste of valuable volunteer
time.  You may be right with your claims that porting modern software to
MVS is a lost cause.

- --
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

iEYEARECAAYFAkmKXfIACgkQ84KuGfSFAYDO/gCgsdzvZe0nDebn3eRyiStU+/cD
00cAoMY5UzlSzaO7jdc8z3H7viECpESL
=x1lF
-----END PGP SIGNATURE-----