Hi Branden,
"G. Branden Robinson" <[email protected]> writes:
>> I suspect you need to do something like this:
>>
>> $ git clean -xdf
>> $ git submodule deinit --all --force
>> $ ./bootstrap && ./configure && make
>
> Yup, that did the trick! Excellent. I hope to have a report for you
> about a measurable consequence of improved coreutils 9.11 performance.
Cool, glad to hear.
>> Specifically, I think your lib/mbbuf.{c,h} files are out of date. They
>> look like they are from before Pádraig's cut changes. If so that also
>> means Gnulib files are certainly outdated as well and may break
>> things.
>
> Seems you're right. Is it too much to hope for gnulib to add an
> Autoconf test that detects its own staleness in this respect? Not quite
> the right list to ask, I know, but you may already know the answer and
> if not, I know where to direct my query.
Moving to bug-gnulib, in case anyone else wants to comment. The Venn
diagram of people that subscribe to bug-gnulib and coreutils is probably
a single circle. But maybe my estimates are wrong.
The feature you request seems useful, but I don't see how it would be
possible to implement (at least, in a way that is usable). It would have
to handle the case where Gnulib is a submodule like in coreutils. In
that case you have the commit of the submodule on the remote, the commit
of the submodule in your clone, and the files imported from
'gnulib-tool' (stored in lib/ in coreutils). So we would have to check
that the local and remote commit are the same. However, we could have,
for example, canceled bootstrap before it invoked 'gnulib-tool'.
Therefore, we also have to check that each file that 'gnulib-tool' was
supposed to import is in lib/ and that it is equivalent to the version
in the git checkout.
All of that would be quite slow I imagine, and that still leaves the
case of Inetutils which uses GNULIB_REVISION without a submodule. It
would also have to not break Bruno's packages which use an autopull.sh
and autogen.sh script instead of the bootstrap script.
> Or was the multibyte buffer code replacement/update sufficiently deep,
> subtle, and/or uncommon that this problem is unlikely to hit others?
Coreutils makes use of 'gnulib-tool --local-dir', which I have not seen
used much elsewhere [1]. It allows us to define our own modules that are
statically linked to the programs. However, since they are not a part of
Gnulib we have the freedom to make breaking changes and such. As a part
of making 'cut' multi-byte aware, Pádraig made a lot of changes and
improvements to a module I wrote.
Collin
[1] https://www.gnu.org/software/gnulib/manual/gnulib.html#Extending-Gnulib
