It is precisely this kind of problem that leads to many shops building their own 'compile processor'.
We have a fairly mature one which enables optional use of any of these:
- Run an arbitrary command before or after compiling.
- Specify compile command parameters.
- Run a command based on the existence (or not) of objects.
- Apply standard authorities to the resulting object.
- Distribute the object to other LPARs/servers.
It also sets some default parameters on the compile commands based on our policies.
I recently enhanced it to allow compiling from stream files, including types not natively supported by the OS. This added the need for additional directives such as providing description text (seeing as there is no member text to use).
The problem described here is a common one which we would solve with the following comment:
/*@ PRE: DSPOBJD OBJ(*LIBL/*ALL) OBJTYPE(*ALL) OUTPUT(*OUTFILE) OUTFILE(QTEMP/ALLDATAXX) OUTMBR(*FIRST *REPLACE) */
We have our processor defined as a command which is registered to RDi and VSCode as the compile command to use for all object types.
I know this doesn't solve the problem for you now, but there may be products on the market to do this sort of thing, or there is no time like the present to start building your own. In the latter case, start simple and build it over time. You could begin with only CL support and pre-commands. Adding stream file support to ours was a big undertaking but made much easier by having a mature base to start with.
------------------------------
Allister Jenks
------------------------------