Re: [Groff] odd interaction between .bl and .(c in -me macros

2012-01-02 Thread Tadziu Hoffmann
> You could instead patch "bl" to do this itself [...] I just noticed that we have to restrict embedding of macros to non-top-level diversions only, because whatever is embedded at the top level is passed on to the postprocessor, which in this case (understandably) complains that it doesn't unde

[Groff] ISO/IEC 9899:2011

2012-01-02 Thread Kristaps Dzonsons
Hello, The enclosed patch accepts `-isoC-2011' to print the now-official standard name, ISO/IEC 9899:2011, for mdoc. If it looks alright, I'll update mandoc(1) similarly. Note that this uses `-isoC-2011' instead of `-isoC-11'. Maybe this is confusing, but I drew from how POSIX symbols incr

Re: [Groff] ISO/IEC 9899:2011

2012-01-02 Thread Werner LEMBERG
> The enclosed patch accepts `-isoC-2011' to print the now-official > standard name, ISO/IEC 9899:2011, for mdoc. If it looks alright, > I'll update mandoc(1) similarly. Applied, thanks. Werner

Re: [Groff] another parallel build race failure

2012-01-02 Thread Werner LEMBERG
> Given that font/dev and the contrib examples are in different child > processes of the recursive make system, it doesn't seem possible to > solve this using clean Makefile dependencies; so i fear the order > must be enforced by splitting the shell command invoking recursive > make in the top lev

Re: [Groff] MAKE_K_FLAG

2012-01-02 Thread Werner LEMBERG
> Pascal Stumpf drew my attention to the fact that the following line > in the top-level Makefile.in is causing trouble: > > MAKE_K_FLAG=`case "$(MAKEFLAGS)" in *k*) echo ' -k ';; esac` > > The problem is that *any* k character anywhere in MAKEFLAGS, for > example coming from something like >