>> Out of curiosity, Eli, why did you find it necessary to move
>> stringclass.h to an earlier position in the include order? Is it
>> not a symptom of either a flawed design, or an implementation
>> fault, if that matters? Is there a MinGW issue which may need
>> investigation? Or is it simply that you've introduced a dependency
>> on stringclass.h within lib.h? (In which case, would it not have
>> been better to have lib.h itself include stringclass.h?)
>
> It's IMO a Groff problem that is not specific to MinGW:
> stringclass.h is not idempotent.
Indeed, this is true for (almost) all groff header files. For some
reason, Clark decided to code it that way, not providing guards
against loading header files multiple times. I haven't changed that.
Werner
