Re: [Groff] automake for man-pages

[Keith Marshall]

On 13/08/15 22:19, Bertrand Garrigues wrote:
> ...  The only thing is that after the 'else' the 3 lines
> 
>   man1_MANS += $(PREFIXMAN1)
>   man1_MANS += $(PREFIXMAN5)
>   man1_MANS += $(PREFIXMAN7)
>   
> are incorrect, it should be of course
> 
>   man1_MANS += $(PREFIXMAN1)
>   man5_MANS += $(PREFIXMAN5)
>   man7_MANS += $(PREFIXMAN7)

Surely a typo here?  Those two assignment groups look identical to me.

> I've left man files as .man in the source tree because it was the case
> before the Automake migration.  I you prefer to have files in the source
> tree that have a suffix corresponding to the section they belong to
> (gpinyin.1.man instead of gpinyin.man for example) it should be possible
> but more complicated because we would have to defined more suffix rules
> to build the final man files from .1.man, .5.man and .7.man (we would
> have to define a new suffix I think, ...

While I'm very much in favour of avoiding increased complexity, is this
really the case?  Surely, the source suffix remains as ".man", and the
".[157]" could become part of the stem?  Thus, if the original source
files "foo.man" and "bar.man" were to be renamed as "foo.1.man" and
"bar.5.man" respectively, then one suffix rule will suffice:

   .SUFFIXES: .man

   .man:
         [command(s) to generate $@ from address@hidden

   all-manpages: foo.1 bar.5

and make will generate the "foo.1" and "bar.5" manpages directly, in
place in the build directory, ready to propagate to the install tree,
with a simple $(INSTALL_DATA).  Surely, this actually represents a
*simplification* of the current strategy, where the initial generation
is as the intermediate "foo.n" and "bar.n" files, and the installation
rule then has to rename those to "foo.1" and "bar.5" respectively?

-- 
Regards,
Keith.