Sharing Eiffel code and utilities - how do we really do it?
I have cleaned up my 'generic' libraries to a reasonable extent, see https://github.com/wolandscat/EOMF
. But the whole project is still a single project, even though it contains seemingly disaparate things.
As you can see from the home page, some of these are:
- a compiler and serialisers for ODIN (Object Data Instance Notation) - the (more powerful and more readable) JSON equivalent we use extensively on the openEHR project. We use this for all .cfg files, object schema files, and general serialisation purposes.
- the msg_code_gen tool to convert error & UI message files into code, so that a) no extra files need to be shipped, b) UI & errors can be localised to any language and c) all such UI elements are converted to Eiffel constants, so that any missing definitions cause a compile fail (i..e you can't accidentally ship your app with missing error cods or UI strings). The input files are in ODIN form. Ideally a tool like this would be integrated into Eiffel Studio to provide proper internationalisation of apps.
- a tool to convert a whole directory tree of .ico & .png files to source code (avoid shipping hundreds of icons). Ideally this would also be in Eiffel Studio.
- the Basic Meta-Model library, essentially a XMI replacement expressed in ODIN, based on the Eiffel meta-model (primarily data elements, no functions yet). We use this to represent object models published as standards (UML diagrams are not computable, except via XMI which is an unholy unreadable mess).
- a rough and ready UI library called EVX that is a layer on top of the EV_* classes, providing a higher level of calls to create controls, menus etc.
- various app framework classes, that I am sure everyone has their own versions of, and keep being re-invented time and again. Particularly environment settings of all kinds, app defaults, etc.
- various other classes needed to make up for missing features in ISE and gobo classes (simple example a class that provide a file system function to return the full paths of all files defined by a regex, i..e something a bit like find path -name regex -print).
I could in theory separate these out somehow, but actually they are inter-dependent at various levels, a bit like gobo. For example, nearly everything relies on the ODIN parser, e.g. all my apps create, save and read their .cfg files in that form, and also get all their UI strings from ODIN files. And so on...
The test code for all these tools is in various stages of development (our real 'test' is our main archetype workbench application).
Rather than do a lot of separation work on my own, I would rather have a discussion with people here to get an idea of how best to arrange, package, document etc code and tools that are potentially re-usable.
These are the original Eiffel Hub questions.
I know others are working hard on things like EWF and much else. But I can't help the feeling that we commonly re-invent things and don't share because sharing is too hard.
[One thought I have is this: I used to think in terms of trying to get everything into a single library space, e.g. the ISE shipment. I now think this is a bad idea. It would be better if we just has libs in $ISE_EIFFEL, $GOBO, $EWF, $WHATEVER, but they all worked to the same principles. Tools and libs that are fixes to Eiffel Studio should of course be added there. We need to work out those common priinciples]