Hi, Definitely our goal is to make z/OS a first class development platform, and not just a target platform. A few of us in the z/OS community have started down this path back in December and we are working our way up the tool chain. Our approach is to build these tools as 64-bit ASCII-based (not EBCDIC-based) now that z/OS has good support for ASCII and UTF8 in the system. So far, we have been working with the various communities and creating patches to the supported tarball and/or the git dev line for the different tools. The goal is to keep the patches as close to 0 as possible by upstreaming as we go. ‘bash’ is higher up the stack (along with zsh). So – they are definitely something we plan to do – we just haven’t got that far up the stack yet. Here is our starter list of ports we are working on: https://github.com/ZOSOpenTools Some like Perl, m4, make are relatively far along. We have up-streamed many Perl patches with the guidance of Karl Williamson for example. m4 has patches I have developed for the tarball build, but I am now working on getting the git dev line to build so that I can bring patches forward for upstreaming.
We also have CI/CD public facing systems we use for ensuring we not only get The code running, but keep it running. We plan to make these systems available more broadly very soon and integrate them into continuous build processes for the open source packages, where the open source communities are willing. This approach of ASCII-based tools is consistent with what IBM and Rocket have been doing for awhile now. The big shift is to do this all in the open rather than doing one-off ports (Node.js, Go, Python, clang, Java are all available for free with optional S&S through IBM and a variety of tools like git and bash are available from Rocket through their anaconda tooling for free with optional S&S). The first on the ‘developed completely in the open’ is Perl: https://github.com/ZOSOpenTools/perlport where I got it up and running with Karl’s help then got patches upstreamed and we have the source and binaries and build all available (the perlport repo is strictly for build scripts and patches and docs – it pulls in the actual code from the perl ‘blead’ line). The binaries we build through our CI/CD Jenkins server are at: https://github.com/ZOSOpenTools/perlport/tags Thanks, Mike From: Bruno Haible <br...@clisp.org> Date: Tuesday, May 31, 2022 at 05:15 To: bug-gnulib@gnu.org <bug-gnulib@gnu.org> Cc: Mike Fulton <fult...@ca.ibm.com> Subject: [EXTERNAL] Re: Failure running gnulib-tool update on z/OS Hi, Mike Fulton wrote: > I am attempting to bootstrap m4 on z/OS which uses gnulib-tool. We need to distinguish two concepts: The development platform and the target platform. * The target platform is the type of system where the collected C code is being run. Gnulib attempts to support a lot of target platforms. See [1] for more info about the target platforms. * The development platform is the type of system where 'git clone', 'gnulib-tool', 'automake', 'autoconf', 'gperf' etc. are being run. Not all target platforms are usable as development platforms: - embedded systems, due to lack of memory, - native Windows platforms, due to trouble with file names and path names, - platforms with an absent or deficient /bin/sh, such as Android and Solaris 10. Note: The C compiler is sometimes used on the target platform, sometimes on the development platform. z/OS is not even listed among the supported target platforms [1], because no one is regularly running the Gnulib test suite on this platform. But with some effort (especially to resolve the pervasive ASCII vs. EBCDIC problems on this platform) there is a possibility that it could be got working. Using z/OS as a development platform, OTOH, requires decent ports of the development tools. Your mail seems to indicate that /bin/sh is a major stumbling point. Another one will likely be gperf (which assumes ASCII). Therefore my recommendation is to use a GNU system as development platform and z/OS as target platform only. This means, create a tarball of sources on the GNU system and compile it on the target platform. Bruno [1] https://www.gnu.org/software/gnulib/manual/html_node/Target-Platforms.html
