Code generation

[omaus]

This PR

• adds functions for code generation (from OBO files to F# source files)
  • unit tests accordingly
• closes Add CodeGenerator for structural ontologies #55

Left to do:

• (GitHub action for automatized execution?)

[kMutagene]

Looks good so far, with minor changes.

Also, please incorporate code generation into the build process, so that the .fs files for the ontologies get generated the same way we currently generate the .obo files from yml
see

ARCTokenization/build/BasicTasks.fs

Line 37 in e5280af

let buildOntologies =

This most likely means that the code generation must move into a separate project, as we must execute it before building the other projects that should contain the generated .fs files. ideally, make it a console application so we can just build and run it via a fake process

[kMutagene]

Please stop committing test scripts to repos. Pls refactor anything relevant to actual unit tests or do not commit it at all.

[kMutagene]

you seriously need to fix your encoding problems 😆

[kMutagene]

My initial idea for this has been adding a separate runnable project (basically the same type as the build project) and invoking that from within the build project's pipelines.

However, looking at this PR, i think it would be best to set up OBO.NET.CodeGeneration as a completely separate library. This way, we can cleanly add a dependency to that package in the build project, keep the rest as-is, and also make code generation from obo files usable in other projects. Additionally, we do not bloat this repo further with another project.

I think the only thing to adapt code-wise would be parameterizing the namespace of the generated files.

What do you think @omaus?

[kMutagene]

While it seems to work, i really do not like this circular dependency, where the build project is dependent on one of the projects it is supposed to build.

[omaus]

My initial idea for this has been adding a separate runnable project (basically the same type as the build project) and invoking that from within the build project's pipelines.

However, looking at this PR, i think it would be best to set up OBO.NET.CodeGeneration as a completely separate library. This way, we can cleanly add a dependency to that package in the build project, keep the rest as-is, and also make code generation from obo files usable in other projects. Additionally, we do not bloat this repo further with another project.

I think the only thing to adapt code-wise would be parameterizing the namespace of the generated files.

What do you think @omaus?

Closed due to this and since the functionality is already realized in OBO.NET.