[nn3]

There's basically nothing to see here. One or two minor bug fixes, a few cleanups, and a new build system replacing one that already worked fine.

In my experience replacing the build system and doing nothing else is usually a good indicator for a project that will be soon abandoned. If that's the first priority it means there's no real drive to implement anything new.

[siteshwar]

> a new build system replacing one that already worked fine.

Have you actually tried the legacy build system before making that comment ? If not, I would suggest you to try that. It's by far the worst build system I ever dealt with. Just to give you an example, if there's a compilation failure in the middle of build process, build system will not stop, it will continue to compile everything that it should not compile and then exit with status 0. There was an absolute need to replace it with something newer.

Replacing the build system is just the first step towards improving the code base and it's not the end of it.

[nn3]

yes i built ast quite a few times. nmake always worked fine.

[siteshwar]

I was doing lot of refactoring around ksh93 code and legacy build system was not really helpful in detecting problems. It was best to change it.

[matttproud]

I hadn't been aware of this project, but I am thankful it exists as a mksh user. ksh rocks; I love how low-bloat and fast it is. Feature bloat — e.g., distribution package management helper scripts that come preinstalled — slowed down bash. Enough was enough.

To the remark about build system, I would like to offer some speculation: I have (or had?) worked with its maintainer Kurtis by way of common employer on a few projects. He is a fantastic engineer and extremely careful and diligent; from that, I would grant significant deference. His team maintained one of the most sprawling pieces of legacy shell script infrastructure I have seen in my career.

Here's to hoping for a blossoming revival of the original essentials.