DBD from self-describing record types does not include dbCommon.dbd

[Ralph Lange]

One of my colleagues stumbled over a recently introduced issue:

For the new self-describing records, the generated dbd has the dbCommon.dbd part expanded (e.g. see the definitions in .../src/std/O.Common/aiRecord.dbd), while all classical records types are including dbCommon.dbd at this point (e.g. see the definitions in .../src/std/rec/biRecord.dbd).

We prefer the old style, as this is used in our case (reading the DBD definitions to create structures in a user level GUI tool) to distinguish between "common fields" and "specific fields" that appear in separate GUI tabs.
Fully blown-up DBD files do not carry this information anymore.

[mdavidsaver (mdavidsaver)]

So the installed *Record.dbd are now expanded. I agree that it is better not to do this.

I guess that dbdExpand.pl needs an option not to expand.

[Andrew Johnson (anj)]

I'm first trying to understand why touching any Record.dbd file causes /all/ of the Record.c and dev*.c files to be recompiled, not just the ones you would expect. For some reason make thinks that the newly recreated Record.h file is a prerequisite of all the Record.o files.

[mdavidsaver (mdavidsaver)]

I think the make rules go something like this:

> stdRecords += aaiRecord
> stdRecords += aaoRecord
> ...
> DBDINC += $(stdRecords)
> DBDINC_NAME = $(patsubst %.h,%,$(patsubst %.dbd,%,$(DBDINC)))
> INC += $(addsuffix .h,$(DBDINC_NAME))
> COMMON_INC += $(filter $(COMMON_DIR)/%, $(foreach file, $(INC), ...
> %$(OBJ): %.c $(COMMON_INC) $(INSTALL_INC)

[Andrew Johnson (anj)]

Bingo!
$(COMMON_INC) and $(INSTALL_INC) should be order-only prerequisites, a new syntax for me:
  %$(OBJ): %.c | $(COMMON_INC) $(INSTALL_INC)
Oh the wonder of all the features available in GNUmake!

Now on to the bug itself...

[Andrew Johnson (anj)]

A 'do not expand' flag would not be easy to add since the dbdExpand.pl program currently parses the whole .dbd.pod input file and then writes out the resulting DBD structure as a new file. There is no concept of an include file in the stored DBD representation, and it would not be easy (or particularly sensible) to add one.

Alternative approaches that I prefer:
1. Encode the information that a field came from dbCommon into the prompt or promptgroup attributes of the fields in it, or something similar. The promptgroup attribute seems to be the right place to keep this, although it's not currently extensible.
2. Write a new program to convert .dbd.pod files into .dbd files that only removes the POD text and writes out everything else verbatim. Adjust the build rules to use this instead.

The second option will less disruptive to external software since it doesn't change the DBD definition at all, but I think the first one makes more sense in the long-term; the promptgroup attribute is where this kind of metadata really should live IMHO.

I will work on implementing #2 for now, any comments?

[Ben Franksen (bfrk)]

What I don't understand is why we cannot simply let all record types implicitly inherit the fields from dbCommon.dbd, period. A very simple built-in rule. No extra syntax is needed, nor the ugly low-level "include" statement, no problem arises for Ralph and colleagues. Semantics are trivial ("behaves as before with the include").

[Andrew Johnson (anj)]

This fixes the problem.
I wanted to remove the rule that creates the .dbd.d files from .dbd.pod but that causes a different rule to run dbdExpand.pl -D with no input files to try and generate the .dbd.d file, so I had to leave it in but doing almost nothing.
We evidently forgot to make .d and generated .dbd files precious, so this patch also does that.

Ralph, please confirm, then I will commit this.

[Ralph Lange (ralph-lange)]

Yes, this patch fixes the problem.

Thanks - please go ahead and commit this.