bug-gnulib
[Top][All Lists]
Advanced

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

Re: rules, rules, and more (code policy) rules


From: Simon Josefsson
Subject: Re: rules, rules, and more (code policy) rules
Date: Sat, 11 Feb 2006 12:17:52 +0100
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux)

Jim Meyering <address@hidden> writes:

> Simon Josefsson <address@hidden> wrote:
>> I'm going through Coreutils GNUmakefile and Makefile.maint to identify
>> useful rules.  Some question pop up:
>>
>> 1)
>>
>> Is this rule generally safe?  Does it assume GNU tar?  Is there a real
>> problem solved by this, or is it just "nice"?
>>
>> # Make tar archive easier to reproduce.
>> export TAR_OPTIONS = --owner=0 --group=0 --numeric-owner
>
> Those options help minimize unnecessary differences between tar archives.
>
>> Further, shouldn't automake set this, if it is safe?
>
> They're all gnu-tar-specific.

Doesn't automake test for GNU-tools?  It could test for GNU tar and
use those parameters when available too.  It seems cleaner to me, and
with no apparent disadvantage.  It would benefit all automake projects
automatically.

If automake would have a TAR_OPTIONS variable or similar, this
wouldn't be as important.  But right now, it seems it is impossible to
add parameters to 'tar' as invoked by automake.  The only workaround
is the TAR_OPTIONS environment variable, but you can't set environment
variables in makefiles in a portable way.

>> 2)
>>
>> The following is not safe, --rsyncable is a new feature.
>>
>> # Do not save the original name or timestamp in the .tar.gz file.
>> GZIP_ENV = '--no-name --best --rsyncable'
>>
>> Perhaps this, and the previous case, should be moved to a m4 macro, to
>> find out whether the parameters are supported or not.  Thoughts?
>
> Rather, how about keeping the tests stand-alone?
> For example, here's the change I've just made so that the rule
> works even when gzip doesn't support the --rsyncable option:

Your solution for the GZIP example solves everything, I believe.  Your
snippet can be included in a gnulib.mk, and would not cause any
problems for anyone.

Still, I think the TAR stuff is different.  You can't set TAR_OPTIONS
in gnulib.mk, because it is not portable.  I see a couple of options:

1) Move the tar options stuff to automake proper.
2) Make automake adhere to a TAR_OPTIONS make variable.
3) Write a wrapper-script for 'tar' that is included, which
   will set those variables if possible.

Thanks.




reply via email to

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