Re: Patch: RFA: new option

[Alexandre Duret-Lutz]

>>> "Derek" == Derek Robert Price <address@hidden> writes:

[...]

 >> info files do not appear in any variable.  Same issue with
 >> flex and bison output.
 >> 

 Derek> No, but they could be.  This could eliminate the problem with html and
 Derek> txt targets breaking recursive operation with homegrown makefiles that
 Derek> we were just discussing, unless the Makefile.am author wanted to deal
 Derek> with it.

This sounds nice.  It's not clear to me how to do that, though.

 Derek> For example, pdf_TEXINFOS could be required to build pdfs.  Same with
 Derek> html_TEXINFOS, txt_TEXINFOS, ps_TEXINFOS, info_TEXINFOS, etc.

>From my point of view, Info_fOOBARS means "install these FOOBARS
in $(infodir)".  This is how bin_PROGRAMS, lib_LTLIBRARIES, data_DATA,
or python_PYTHON work.  For some primaries it means a bit more, for
instance _LTLIBRARIES and _PYTHON will install more than just the
files being listed.

"info_TEXINFOS = bar.texi" is a bit different because it won't
install bar.texi in $(infodir).  However it will install
something derived from this file there (`bar*' or `bar.info*',
whatever it is called inside `bar.texi').

I don't think we should change the meaning of this prefix.  It
should remain a destination.  Right now we don't have any
directory name such as htmldir, txtdir, psdir, or dvidir.

What can be changed however is the suffix (a.k.a. primary).
Maybe it would make sense to have

  info_TEXINFOS = bar.texi
  noinst_TEXIPDF = $(info_TEXINFOS)
  pkgdata_TEXIHTML = $(info_TEXINFOS)
  bar_texi_DEPENDENCIES = included.texi

(That would mean install the Info manual in $(infodir), just
build the pdf version, and install the html into $(pkgdatadir).
I've used bar_texi_DEPENDENCIES instead of bar_TEXINFOS because
that really looks more natural to me.)

It's a bit different from what we have now.  Right now users are
expected to run `make ps' or `make pdf' or another rule to build
whatever format they prefer.  The above syntax would cause
info/pdf/html to be built *always* (which in turns probably
means we should check for the tools' availability).

 Derek> Prepending dist_ or nodist_ could change the default
 Derek> dist behavior and syntax like

 Derek> txt_TEXINFOS = $(info_TEXINFOS)

 Derek> could be used to avoid respecifying files.

Note that like me you have been assuming that your variables
contains *.texi files.  So the *.info, *.ps, or *.pdf still are
not explicit.

Does 

   nodist_info_TEXINFOS = bar.texi

mean that bar.info* should not be distributed, or that bar.texi
should not be distributed?  The patch I mentioned assume the
latter, because this is closer to how nodist_ is used elsewhere.

Here are the possible scenarios that I'd like to support:

  a) bar.texi and bar.info both distributed
  b) bar.texi is distributed, but not bar.info
  c) neither bar.texi nor bar.info are distributed

That's three states, so a single nodist_/dist_ switch cannot be enough.
So far my idea was to use nodist_/dist_ to select whether *.texi
would be distributed, and rely on the EXTRA_DIST/CLEANFILES hackery
to decide about unmentioned files.

Thoughts?
-- 
Alexandre Duret-Lutz