Modular Compiler / Packaging Structure

[vanrein]

We should split the compiler, so packages can be more subtle about dependencies

• the compiler loads and directs modules
• the compiler has basic knowledge of Petri Nets and PNML files
• modules with implementation models: tabular, bitfieldvec
• modules generating for languages/libraries: C, Erlang/OTP, C/MPZ, ...
• not all implementations models will work on all languages/libraries

We will need to have a full grasp of what needs to be generated before we can split the functionality; specifically, issues #6, #9, #10, #11 and #13 need to be resolved first. Until then, we will be stuck with a monolithic compiler that needs all of pntools, cmph and that may even generate all output in one go.

[vanrein]

What we can already do in an earlier stage, is add arguments to the compiler, that are mindful of this future split of functionality. Flags to select an output language might be phrased as backend module loading instructions, for instance: not --c-plain but --language=c-plain basically.