-----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 e...@byu.net -----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-----
