CMHG sources?

You could probably file this one under “you’d get eleventy billion more developers/users if the OS was open source!!!11eleven”, but I was wondering if it would be possible to release the CMHG sources. That way it would be a lot easier for people to experiment with things like more optimal SWI/vector veneers, or new features like multi-core or usermode modules.

Or I guess anyone interested in the above could just develop the features in cmunge, and CMHG development can potentially be discontinued (after all, for something as simple as module header generation, there’s little point in having two competing implementations of the same system).

This must be a specialist question as I do not even understand the acronyms (apart from OS and SWI).

The following article may help to shed a little light on CMunge and CMHG → http://gerph.org/riscos/ramble/buildsystem.html#CMunge

This must be a specialist question

CMHG – C Module Header Generator. A program that creates a piece of code to start up a module written in C, and to munge the OS calls (vectors, SWIs, *commands) into something that can work with C.

That way it would be a lot easier for people to experiment with things like more optimal SWI/vector veneers, or new features like multi-core or usermode modules.

Or even having proper module tasks rather than application tasks wrapped as modules. I know it is possible as I wrote my own entry code that does it. It’s probably horrifically wrong but it’s a “proof” and nothing crashes. ;-)

I asked about access to the CMHG sources four years ago (https://www.riscosopen.org/forum/forums/11/topics/2682) but, as with my offer to do some updating of ABC (even older!), nothing has ever come of it.
Strange. You’d think “they” would be interested in people willing to do some work on the various dev tools for free wouldn’t you? <shrug>

I guess what I’m trying to say is… don’t hold your breath.

“you’d get eleventy billion more developers/users if the OS was open source!!!11eleven”

Well, any idiot could see that was a non-starter. If it wasn’t a generic whinge about the licencing, it would be a generic whinge about the devtools not being free, and if not that it would be an epic rant about the fact that huge swathes of the OS is incomprehensible gibberish because it’s not written in the favourite toy scripting language of the day.

The following article may help to shed a little light on CMunge and CMHG → http://gerph.org/riscos/ramble/buildsystem.html#CMunge

Interesting – that makes it sound like ROL switched over to using CMunge. In which case there probably isn’t anything major stopping us from doing the same.

that makes it sound like ROL switched over to using CMunge.

Hmm. The person who tweaked, hacked, then seemingly ended up maintaining the tool decides to use it for their build of RISC OS.
That, plus the obviously healthy dose of “not invented here” syndrome. ;-)

Maybe I’m a boring coder doing uninteresting things, but while I can see scope for enhancing CMHG, I’m afraid I haven’t run into this yet: there had been frustrations with having to write assembler veneers for common RISC OS APIs.

I have needed to write my own veneers for a couple of projects that did some low level trickery, but that’s hardly a common API and I would not have expected CMHG to have supported such things.

It would be nice, however, to either have CMHG open sourced so it can be tweaked, or to have an option where it can output an assembler version of its output (like the compiler with -s flag) so the actual header code can be edited if necessary. Certainly the idea of keeping that stuff as a black box seems a bit ridiculous these days when CLib, RISCOSLib, etc is available to be examined and fixed where necessary. ;-)

Cmunge has a few subtle differences to CMHG.

For instance the date embedded in the module header is taken from the timestamp of the description file by CMHG, but Cmunge uses the current date.

I changed my copy of Cmunge to put this right, but TBH I was less than impressed with the poor coding of Cmunge – it looks like it was written in a rush to meet some other deadline for something else.

I was less than impressed with the poor coding of Cmunge

Ah, yes. Load up https://www.riscos.info/websvn/filedetails.php?repname=gccsdk&path=%2Ftrunk%2Fgcc4%2Friscos%2Fcmunge%2Fwritefile.c and search for FIXME and ponder.

Jeffery – looks like CMunge doesn’t support help entries as commands. I wonder how many things make use of that?

looks like it was written in a rush to meet some other deadline for something else.

To be fair, CMHG could be worse. We don’t know. ;-)

Hmm, yes that source looks like it could do with a bit of a tidy up.

Since the operation of CMunge/CMHG is mostly “read one text file, write out another text file” I’m wondering whether a more flexible approach would be sensible – have a file (or set of files) containing the different assembler code snippets that should be used in each scenario. That would allow for a fair bit of customisation without the need to touch the source code. Essentially the CMunge/CMHG binary would just be a wrapper around a Handlebars -like text templating system.

That would allow for a fair bit of customisation without the need to touch the source code.

Once you have a really powerful customization system, it gets indistinguishable from source code…