coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] build: do not require help2man at build-from-tarball time


From: Stefano Lattarini
Subject: Re: [PATCH] build: do not require help2man at build-from-tarball time
Date: Mon, 10 Sep 2012 14:05:33 +0200

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 <address@hidden>
>>>>> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]