[✨]: include yourself in compiler-explorer

[GitMensch]

Is your feature request related to a problem?
It is nice to be able to compare the results of compilers, and also gives the project some additional visibility.

Describe the solution you'd like
Add yourself to compiler-explorer.
This would mean to add it to its main repo into the existing COBOL definition, see compiler-explorer/compiler-explorer@6f7218a; and also to integrate it to the infrastructure repository. The matching commit to the one above is compiler-explorer/infra@8948308.

Note that the main entry is based on GCC so that's "cheap", you'd use a "complete" definition like https://github.com/compiler-explorer/compiler-explorer/blob/main/lib/compilers/gnucobol.ts that more or less just uses the build and use instructions you already have.

The .net one is possibly also useful to inspect: https://github.com/compiler-explorer/compiler-explorer/blob/main/lib/compilers/dotnet.ts

Additional context
Note: before this is done - ensure that the codegen works for the examples (which are 'simple'), those are available at https://github.com/compiler-explorer/compiler-explorer/tree/main/examples/cobol

After that it is likely a good idea to create a new compiler issue there and discuss the necessary steps and if they may do the actual work.

[KTSnowy]

Sorry for the late reply to this issue, I'll work on adding Otterkit to compiler-explorer as soon as I have some free time.

Should we wait until Otterkit is properly working before adding to compiler-explorer?

[GitMensch]

It is enough if it works properly with the sample programs (that abide to the COBOL standard / dialect Otterkit targets and for simple code like common MOVE / DISPLAY). gcobol is also included since some time and it was definitely neither feature-complete nor bug-free.

[KTSnowy]

It is enough if it works properly with the sample programs (that abide to the COBOL standard / dialect Otterkit targets and for simple code like common MOVE / DISPLAY).

I'll add us to compiler explorer as soon as I get some of the stuff from #35 working. This won't be another dialect, just a set of standard features that we should prioritize implementing to make replacing C possible (features that map one-to-one with C).