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 [email protected]]
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.
