2021. What an interesting year. With the world turned upside down by a pandemic that seemingly had its sights set on...
Whatever Happened to GMAKE?
Randall S. Becker, ITUGLIB Technical Committee
About two years ago, I was asked by a NonStop customer to help fix their build environment to support SCOBOL and a few other release objects. We were using GMAKE, the GUARDIAN port of the UNIX Make program, At about 5:30pm on the Friday, GMAKE went into DEBUG – not a good time, obviously. Of course, it was up to me to figure out what was going on…
The above is a real story. I was trying to use Make $shell function to get the system type to figure out which linker to use. Not only did the function not work, using it was what caused GMAKE to go into DEBUG. The next step was to go to GNSC and open a case. Our team was told that GMAKE is under limited support and the call to DEBUG we hit was going to stick around. Like all good DevOps people, I worked around it. Six months later, Bill Honaker, our Chair, got a message from NED suggesting that ITUGLIB could take over support for GMAKE fixes and enhancements. A year after that, after getting the appropriate approvals and clearances, we were ready to go.
Can you imagine the excitement for this on our team? At the time, GMAKE used an incredibly outdated version of the GNU Make code base – 3.77 from 1998. After some discussions, negotiations, and waiting, we finally received the code package and, to put it mildly, went wild. First, I upgraded the code to the 4.2 code base to match the Make implementation in /usr/coreutils/bin. The newer GMAKE also supports all the functionality delivered as part of the version of GMAKE (T0593) in $SYSTEM.SYSTEM. Then, we started fixing bugs – and as you might expect, the shell function was first. Then came the predefined variables, GUARDIAN DEFINE support, and provisions for extensions.
As a reminder, GMAKE is a build engine that organizes recipes (commands, compiles, link steps) and dependencies (which source goes into what object). GMAKE uses timestamps to figure out what minimum set of stuff should be compiled to update an application. It is like ACIMAKE but for the rest of us.
We also decided, since GMAKE is covered by the GNU Public License (GPLv3), that we would make it public and started the official ITUGLIB GitHub site for GMAKE, at https://github.com/ituglib/gmake.
The site has more than just code. It has the official Users Guide for GMAKE – the stuff about GUARDIAN that isn’t in the GNU Make documentation. Included in our move to GitHub is an issue tracker, so if you find problems, you can let our team know, and branch security so that the main code base is protected by our team. And of course, the code history. GMAKE is in git, after all.
After that all happened, we decided to take some of the extra super bonus features that were part of the Nexbridge GMAKEN code base so that that team didn’t have to support those features anymore. That put us on the GNU Make 4.3 code base. It also includes most of the new variables, some more advanced DEFINE functions, comparison functions like RVU comparison ($vcompare), and extension points that NSGit (T1198) uses to handle SCOBOL requester builds, DDL dictionary rules, and Copy Library dependencies – but you need to get T1198 DLLs for those capabilities. GMAKE just has the extension points.
There are still more planned features, like starting NOWAIT processes, but we have not worked out all the details yet. If you have any ideas or needs, please let us know on our issue tracker on the GitHub Site. We are also planning to move to GNU Make 4.4 – if and when that comes out. ITUGLIB does its best to keep up.
Most importantly, GMAKE is now a far more capable (free) community supported product, which can be obtained from ITUGLIB as a PAK file, built and published using Jenkins, managed by git, and fully visible to the community as part of your software supply chain! You really should upgrade to it instead of just using build scripts. The download packages for L-series and J-series are available at:
Randall S. Becker, Managing Director, Nexbridge Inc.,
Process Maintainer and Open-Source Contributor for ITUGLIB.