Re: [PATCH] sed: remove obsolete advice from --help output

[Assaf Gordon]

Hello Jim,

> On Aug 14, 2016, at 20:05, Jim Meyering <address@hidden> wrote:
> 
> On Sun, Aug 14, 2016 at 4:32 PM, Jim Meyering <address@hidden> wrote:
>> While preparing the attached patch, I discovered a missing dependency bug.
>> To demonstrate, run "touch sed/sed.c; rm -f sed/sed; make", and witness this:
>> 
> [...]
> Here's the patch for the above along with a few other build-related issues:
> <sed-build-deps-and-distcheck.diff>

Regarding the man page regeneration:

I think this is the same issue I encountered with "make -j".

I suspect the "ideal" solution would've been to use gnu make's 
"order-only-prerequisites",
so that the man page needs to be rebuilt only of sed.c was modified, but wait 
until 'sed' binary is built:
   doc/sed.1: $(srcdir)/src/sed.c .version $(srcdir)/doc/sed.x | sed/sed
However, this will require 'gnu make' to build sed, so I guess is unacceptable.

If we require 'help2man' to build sed, it makes 'perl' a requirement (instead 
of just shell/make/compiler).
In coreutils there's the "dummy-man" script for cases 'perl' is missing.

An alternative which I've used in other projects is to build the man page only 
if the project is built from 'git'.
It is them packed inside the tarball, and installed as-is (assuming that most 
users who build from tarball have not changed sed.c at all, and there's no need 
to rebuild the man page).

Perhaps this is a bit overthinking, and just requiring perl is fine.


Regarding changes in the 'doc/sed.texi' target:
(I must confess I'm writing only based on reading the patch, I'll be able to 
try/test/verify tomorrow evening.)

The file 'doc/sed.texi' perhaps needs more changes: It is both auto-generated 
from 'doc/sed-in.texi' AND checked into the git repository.
When I converted to non-recursive makefiles, I kept it as 
'$(top_srcdir)/doc/sed.texi' to keep as much as possible as the old makefile 
system. If we change it now to 'doc/sed.texi' (which will of course work better 
in out-of-tree builds),
perhaps we should consider removing it completely from the git repository and 
always rebuild it?

Just my 2 cents...

Regards,
 - assaf