On 09/10/2012 01:41 PM, Jim Meyering wrote:
> Stefano Lattarini wrote:
>
>> On 09/10/2012 12:46 PM, Jim Meyering wrote:
>>> Stefano Lattarini wrote:
>>>> Hi Jim.
>>>>
>>>> On 09/10/2012 09:41 AM, Jim Meyering wrote:
>>>>> We can't have build-from-tarball requiring perl (via help2man)
>>>>> or regenerating a distributed .1 file when its .c file has not changed.
>>>>>
>>>>> From 57da212a95054cc230ffb00f38ea655c798926f8 Mon Sep 17 00:00:00 2001
>>>>> From: Jim Meyering <meyer...@redhat.com>
>>>>> Date: Sun, 9 Sep 2012 19:27:25 +0200
>>>>> Subject: [PATCH] build: do not require help2man at build-from-tarball time
>>>>>
>>>>> But do retain full dependencies when building from a git clone.
>>>>> We do this by converting the full dependency (of the .1 file on
>>>>> the binary we run with --help) into a dependency on the .c file.
>>>>> * Makefile.am (do-not-require-help2man): New rule.
>>>>> (dist-hook): depend on it.
>>> ...
>>>> I believe this is incorrect. Think of what happens if a user building from
>>>> the tarball modifies, say, 'src/ls.c', and then runs "make -j8" to rebuild
>>>> everything: make will see that it has to rebuild the man page 'man/ls.1'
>>>> (because its prerequisite 'src/ls.c' has changed), but won't see that it
>>>> has to rebuild 'src/ls' before re-running 'help2man' ro generate that man
>>>> page; so, if 'man/ls.1' is rebuilt before 'src/ls' (which can happen with
>>>> concurrent make), our user will get either a build error (if 'src/ls' was
>>>> non-existent) or, worse, a man page with an up-to-date timestamp but an
>>>> out-of-date content. And what's even worse is that this problem will be
>>>> present also for users who have perl installed!
>>>>
>>>> So we are breaking correctness for all tarball users only to accommodate
>>>> those few crippled systems lacking a decent perl.
>>>>
>>>> I think the right way to go is "graceful degradation": we should keep the
>>>> correct dependency for man pages ("man/ls.1: src/ls"); and if perl is not
>>>> present, we should use, instead of help2man, a shell script that just
>>>> emit a "placeholder" man page stating that a real man page couldn't be
>>>> built due to lack of perl, and redirecting the user back to either the
>>>> info documentation or the '--help' output.
>>>>
>>>> WDYT?
>>>
>>> Hi Stefano,
>>>
>>> Thanks for reviewing that.
>>>
>>> I have mixed feelings. If someone is modifying sources and expecting
>>> to be able to rebuild, they'd better have developer tools like perl.
>>>
>> Agreed. And the major problem I see with your patch is exactly that it
>> could cause issues for savvy users on powerful systems having all the
>> required tools, just to cater to users on crippled systems.
>>
>>> On the other hand, I dislike distributing a deliberately hamstrung
>>> Makefile.in, even though this wart is only in a generated file, that
>>> could easily be regenerated without the reduced dependency -- again,
>>> assuming proper tools.
>>>
>>> An added bonus of your approach: we would no longer need to distribute
>>> the man/*.1 files, and instead would generate them unconditionally, even
>>> from tarballs.
>>>
>>> Do you feel like writing the patch, and especially documenting what
>>> would amount to a new, soft, build-from-tarball dependency on Perl?
>>>
>> I'd like to do that, but no promise about the time it will take (could
>> be one day, could be two weeks).
>
> Actually, I'd like something slightly different, but I'm not sure
> it's possible even with GNU make.
>
> I want each *existing* .1 file to depend solely on its corresponding .c file.
> However, when a .1 file does not exist, *then* I want it to depend on
> its corresponding executable.
>
This sounds overly complex IMHO, and just for a negligible gain.
But of course it's your call.
> I.e., I do *not* want to rebuild an existing .1 file
> solely because we have a newer binary, when the .1 file
> is newer than its dependents (.c and .version).
> I started work on a prefix to the .x.1 rule in man/local.mk,
> but it relies on test's -nt operator. With a shell lacking
> that feature,
>
Just out of curiosity: is that feature in POSIX?
Anyway, maybe it could be emulated with "find -newer" or something
similar...
> or when things are out of date, the regular commands
> would run. Otherwise, it would simply touch the .1 file and exit
> successfully.
>
> AFAIK, there is no way in GNU make to specify dependencies that vary
> depending on the existence of a target. Does anyone know otherwise?
> I.e., a rule that would apply when foo.1 does not exist, vs. another
> one (with different dependents) that would apply when it does exist.
>
What about this (untested)?
ifeq ($(wildcard target)$(wildcard $(srcdir)/target),)
target: prereq1
@echo target existed already
else
target: prereq2
@echo target did not exist
endif
That would only work assuming 'target' is relative to be builddir
(i.e., 'dir/file', not $(srcdir)/dir/file'), but might be enough.
Regards,
Stefano
