Re: Is the 'diacrit' module still needed?

[Bernhard Voelker]

Hi Jim,

sorry for the delay.

On 3/23/21 3:34 AM, Jim Meyering wrote:
> On Mon, Mar 22, 2021 at 4:20 PM Bernhard Voelker
> <mail@bernhard-voelker.de> wrote:
>> +# Ensure that physical copies of gnulib files are in sync.
>> +sc_gnulib_copies_compare:
>> +       @cd $(srcdir) \
>> +         && diff COPYING  gnulib/doc/COPYINGv3 \
>> +         && diff bootstrap gnulib/build-aux/bootstrap \
>> +         && diff tests/init.sh gnulib/tests/init.sh \
> 
> Hi Berny,
> I like the idea.
> However, to impose it on everyone via a new sc_ rule, it'd have to work for
> arbitrarily-named gnulib (easy, use maint.mk's $(gnulib_dir)) and
> "tests" directories.

I have to confess I don't fully understand.

Are you saying you're having gnulib somewhere else than in the 'gnulib'
directory, i.e., different from how it is defined as a submodule in coreutils
(maybe using `bootstrap --gnulib-srcdir=...` or env GNULIB_SRCDIR=...)?

Or do you aim to add the sc_ rule to gnulib, so that other projects might
use it, too?  For that, those projects would have to define the list of
files they physically copy from gnulib.

> Handling "tests" is harder: sed has "testsuite", and automake has "t",
> but with a
> loop over a few hard-coded names like those, you could find a good
> candidate for this, too.
> In the search for a test directory, I'd default to a user-overridable
> (either "tests" or deliberately empty by default)
> dir name and if that's not specified, set it via the search through
> that hard-coded list of likely names.

Same here - I'm a bit lost.
Do you mean to have a generic search over the base names from the output
of 'git -C gnulib ls-files' to see if any of them are version-controlled
in coreutils?
This will not always work: e.g. we're using gnulib/doc/COPYINGv3
and track it as 'COPYING', i.e., with a different base name.

Re. the current list for coreutils, I see only 3 files physically copied
from gnulib and tracked in Git - see the diff above.

> For extra credit (to be run manually when out of sync), add a companion rule
> that will perform the update and git-commit the result with a proper log 
> entry.

FWIW:
Some while ago, I proposed [1] to add the target 'update-gnulib-to-latest'.
Padraig liked [2] it.
Eric suggested [3] to make it more generic and propose this to gnulib.
So I did that [4,5], but Bruno was not fully convinced[6].

[1] https://lists.gnu.org/r/coreutils/2018-07/msg00032.html
[2] https://lists.gnu.org/r/coreutils/2018-07/msg00033.html
[3] https://lists.gnu.org/r/coreutils/2018-07/msg00036.html
[4] https://lists.gnu.org/r/coreutils/2018-12/msg00007.html
[5] https://lists.gnu.org/r/bug-gnulib/2019-03/msg00011.html
[6] https://lists.gnu.org/r/bug-gnulib/2019-04/msg00001.html

> Please use diff -u, not just "diff".

Sure, once we've agreed on a direction.

Thanks & have a nice day,
Berny