Defmod Extension

[Tony van der Hoff]

Hi team,


1. I propose to extend DefMod to accept macro definitions in swi files,
so that I can define some macros to use for filling in the various
offset fields in (for instance) toolbox object templates.

The syntax would be MACRO: <whatever> <DESCRIPTION_OPTION> MEND
There would be no checking of the contents of <whatever>.

I recognise that it would be nicer to somehow generate these macros
automatically by enhancing the syntax for declaring structures, but I
suspect that that would over-complicating matters for not much gain.

An alternative would be to add these macros to types.h, but I believe
that would be messy, and I'd prefer to keep them in the module for which
they're intended.

My proposal is therefore to add the appropriate tokens to the lexer and
parser, and store the result in a new structure, def_m, defined as
typedef
   struct def_m
   {
      char id [def_ID_LIMIT + 1];
      char *expansion;
      char *description;
   }

and emit this, as appropriate, from cheader and cstrong.

Has anyone got any objections/better ideas/helpful hints?


2. A further revision I propose to make to DefMod will be to alter
cstrong to split up the manuals into constants, types, swis, and macros
for each module, and also alphabetically sort each entry in the index,
so as to make the larger ones more manageable.

Again, is this the best way to go about it?


3. As pointed out by users, we seem to have lost our way a little when
we changed the handling of variable-size structures, in that there is
still no base structure (with no variable members) defined, other than
in the macro, which doesn't appear in the stronghelp manual, and things
which were supposed to be just headers contain a single data member.

To correct the situation, I have done the following:

a. The macro is emitted to stronghelp, and cross referenced where used.

b. A structure, with the name suffixed by _base is now generated, and
emitted to the c header and stronghelp, as well as the legacy struct,
e.g.

struct wimp_window_base
{ wimp_WINDOW_MEMBERS
};

This gets a bit silly for, say, toolbox_action_header, where we now have
toolbox_action_header_base; this would really have been better named
toolbox_action_base, but for backwards compatibility I see no other
simple solution.

Again, any comments are welcome.

-- 
Tony van der Hoff         |  mailto:OSLib at mk-net.demon.co.uk
Buckinghamshire, England  |  http://www.mk-net.demon.co.uk/oslib/
----------------------------------------------------------------