I am not sure it might be helpful to the OCaml community, as we already have well integrated test frameworks, but here is a tool I wrote in OCaml to work with GNU projects: autofonce is a modern runner for testsuites created for the GNU Autoconf tools.
Compared to Autoconf tools, its main features are:
improved terminal output
automatic parallel execution
promotion of tests results to fix tests
filtering by keywords, numbers and ranges
execution from any project directory
A typical Autoconf test looks like:
# Start of a test, and the name that will be displayed
# can be used to select tests to run:
AT_KEYWORDS([example test autofonce])
# create a file `file` with its content
content of file
on multiple lines
# call some command, check its exit code, stdout, stderr
AT_CHECK([cat file], , [stdout of my command], [stderr of my command])
# you can do more, ignore some results, run more tests in case of failure, etc.
# end of the test
I personally like the syntax better than the one of cram tests, though there is some weird escaping issues with brackets (see the section in the doc).
Compatibility with Autoconf is only partial, as it uses a grammar interpretation of what should actually be m4 macros, but it was good enough to run the full GnuCOBOL testsuite after a few fixes (that actually improved the testsuite).
The package is on Opam, but sources, documentation and static binaries are available from Github:
Since 2022, OCamlPro has been involved in a big modernization project for the French state: the goal is to move a large COBOL application, running on a former Bull mainframe (GCOS) to a cluster of Linux computers. The choice was made to use the most open-source compiler, GnuCOBOL, that had already been used in such projects.
I wonder, have you considered creating something like c2rust but for COBOL? To convert and refactor some of the COBOL sources into a modern language, e.g. OCaml (as it’s done by the OCamlPro)? From what I heard finding developers that could understand and write COBOL code is immensely hard.
There are already many such tools, targetting other languages from COBOL. However, very few of them are able to generate maintenable code in the target language, so that using these tools does not always lead to a successful migration. Companies are now experimenting with machine-learning based translations that seem to give interesting results.
Actually, it is only one part of the problem. On the other side, COBOL is mostly used for accounting, and what you can do with it is quite limited, so switching to another language creates other problems…
My understanding is that it’s a compiler to Java, not a transpiler. The one we use, GnuCOBOL, is a compiler to C, and C is then translated to machine code. I expect they are both used in the same manner, one targetting machine code, the other one targetting JVM environments.
Thanks for the link ! We have also our own Menhir-based parser for COBOL, which required actually a big effort (the language is really huge…). It uses the incremental interface of Menhir, so that we could use it in our LSP for Vscode.