Re: Why hasn't this ARFLAGS patch not been merged yet?

[Michael Felt]

I suppose in a GNU only world, this would be okay. However, my man page for
ar still says:

       -u
            Copies only files that have been changed since they were last
copied (see the -r flag discussed previously).

while the option -D is not found.

address@hidden:[/data/prj/python/python-2.7.8.2]ar -D
Usage:  ar [-X{32|64|32_64|d64|any}] [-clsvCT] [-g|o] {-h|p|t|x}
                [--] Archive [File ...]
        ar [-X{32|64|32_64|d64|any}] [-clsvCT] [-g|o] {-m|r[u]}
                [{-a|b|i} {PositionName}] [--] Archive File ...
        ar [-X{32|64|32_64|d64|any}] [-clsvCT] [-g|o] {-d|q}
                [--] Archive File ...
        ar [-X{32|64|32_64|d64|any}] [-clvCT] {-g|o|s|w} [--] Archive

so, I think adding -D as a default will break "all" for me.

If the patch differentiates between GNU environment and Not GNU - then
nothing said. But, "things" which have been the standard for 10's of years
should not be changed suddenly (why change at all if it is all scripted? I
am not looking for more job security - I prefer productivity :smile: )

Michael

On Sat, Oct 31, 2015 at 9:42 PM, Kim Walisch <address@hidden> wrote:

> Hi,
>
> I have two open source projects (primesieve and primecount) which use
> the GNU build system. Both currently print a warning during make
> (tested on Ubuntu 15.10 and Fedora 22):
>
> ar: `u' modifier ignored since `D' is the default (see `U')
>
> For primesieve I have opened an issue on GitHub
> https://github.com/kimwalisch/primesieve/issues/16 with more details.
>
> A patch has been proposed by Pavel Raiskup to fix this issue
> http://www.mail-archive.com/address@hidden/msg07705.html
> on the 2nd June 2015 but as far as I can see the patch has not been
> merged into the master branch yet.
>
> I think that many (maybe even most?!) projects using the GNU Build
> System are affected by this issue. So my question is why hasn't this
> patch not yet been accepted?
>
> I am asking because I wonder if I should add a workaround in my
> configure.ac. But this is obviously not a good solution i.e. it is
> better to fix this issue in one upstream project instead of many
> downstream projects.
>
> Thanks,
> Kim
>