Re: [PATCH] build: avoid warning from coverity about lbitset_elt_find

[Akim Demaille]

Le 13 janv. 2012 à 12:00, Jim Meyering a écrit :

> Hi Akim,

Hi!

> I just tried to cherry-pick that commit from my
> private branch onto master, but it failed due to ChangeLog
> differences.  I can deal with that easily, but...
> What do you think about generating ChangeLog from git log like
> we do for coreutils, grep, gzip, diffutils, etc.?

I am personally very much in favor of it.  But I'd like to be
sure that Joel is too (hi Joel, happy new year!).

>> Would these bitset operations make sense in gnulib?  I
>> had taken them from submitted patches for GCC, but IIRC,
>> they never made it into GCC.
> 
> gnulib currently has no bit-set primitives, so they would definitely fill a 
> gap.
> Are you volunteering to package them?  ;-)

Well, I'm willing to spend some time again on Bison, so that
could be part of it.  But I don't expect to do that soon :)

> The bootstrap script in gnulib already does this:
> 
>  # Remove any dangling symlink matching "*.m4" or "*.[ch]" in some
>  # gnulib-populated directories.  Such .m4 files would cause aclocal to fail.
>  # The following requires GNU find 4.2.3 or newer.  Considering the usual
>  # portability constraints of this script, that may seem a very demanding
>  # requirement, but it should be ok.  Ignore any failure, which is fine,
>  # since this is only a convenience to help developers avoid the relatively
>  # unusual case in which a symlinked-to .m4 file is git-removed from gnulib
>  # between successive runs of this script.
>  find "$m4_base" "$source_base" \
>    -depth \( -name '*.m4' -o -name '*.[ch]' \) \
>    -type l -xtype l -delete > /dev/null 2>&1

Great!  But why just m4?  Why not removing all the links that
go into gnulib/ before adding the fresh ones?

> If you can wait a little while, I'll probably upgrade bison's
> bootstrap to use the latest from gnulib.  I know that bison's
> prefix-gnulib-mk usage would need a little tweak (just run
> it manually on lib from bootstrap_epilogue), but other than that,
> it might be trivial, since I've done the same to 4 or 5 other packages
> recently.

Well, if you do have some time to spend on this, be our guest :)
Otherwise, rest assured that I'll probably do this in the near
future, so there is really no hurry.

Thanks!