Re: splitting MANS into pieces to avoid long install-man command lines

[Stefano Lattarini]

On 02/01/2012 06:33 PM, Brice Goglin wrote:
> Hello,
>
Hi Brice.

> We have a very long list of manpages to install in man3 in the hwloc
> project [1]. Somebody recently reported a failure of some platform
> because the install-man command-line was too long. Indeed we have a
> single man3_MANS variable with maaaany manpages. I tried to split it
> into pieces as explained in [2] but this doesn't appear to work. From
> what I see in the automake code, only man_MANS and man[0-9]_MANS
> variables are processed as manpages. Anything else such as man3_foo_MANS
> seems ignored.
>
Unfortunately true, and a known bug; see:

  <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10695>
  <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7656>

> How may I solve this? Is there anything better than the following ideas:
> * Split into many different man3_foo_DATA variables inside the same
> Makefile.am because any variable ending with _DATA is processed. it
> works but installing manpages as DATA might cause other problems?
>
Not sure about this...  I *think* that it should work, as long as your man
pages already have the correct suffix (e.g., manpages going in section 3 are
named like 'foo.3', not like 'foo.man') and you don't care that they are not
installed when you call "make install-man", but only when you call "make
install-data"...  But as I said, I don't feel like offering any certainty.

> * Split my doc directory into subdirectories with a smaller part of my
> big man3_MANS in each subdirectory. Looks ok, but not very nice because
> these new subdirectories are not used for anything else.
>
Personally, I'd use this second solution; it is uglier but safer.  But if
that other, previous solution works for you (and I see from the links below
it is already implemented in your repo), by all means stick to it.

> FWIW, the current man3_MANS variable is visible at [3]. All section 3
> manpages are generated at the same time with doxygen.
> 
> Thank you
> Brice Goglin
> 

HTH,
  Stefano