Re: [bug-gettext] gettext-0.20 has parallel make install issues

[Bruno Haible]

Hi Miguel,

Thanks; this patch is better: it passes "make distcheck".

However, it is still not 100% correct.

1) Paul Smith found this problem:
   <https://lists.gnu.org/archive/html/bug-make/2019-05/msg00020.html>

2) It splits the rule for po-gram-gen.c po-gram-gen.h this way:

  po-gram-gen.h: po-gram-gen.c
  po-gram-gen.c: po-gram-gen.y

But the rule's statements create po-gram-gen.c with a newer timestamp
than po-gram-gen.h:

$ ls -l --full-time po-gram-gen.[hc]
-rw-rw-r-- 1 bruno bruno 64034 2019-02-05 03:16:47.165550561 +0100 po-gram-gen.c
-rw-rw-r-- 1 bruno bruno  3445 2019-02-05 03:16:47.161550537 +0100 po-gram-gen.h

With my limited testing, I have not been able to spot wrongdoings of
'make' due to this ordering. But I would feel safer if the rule was split
this way:

  po-gram-gen.c: po-gram-gen.h
  po-gram-gen.h: po-gram-gen.y

Likewise for the other bison rule:

$ ls -l --full-time cldr-plural.[hc]
-rw-rw-r-- 1 bruno bruno 60469 2019-02-05 03:16:47.321551486 +0100 cldr-plural.c
-rw-rw-r-- 1 bruno bruno  3011 2019-02-05 03:16:47.313551439 +0100 cldr-plural.h

> I've attached a patch that should solve the issue...  Should because
> I've cheated a little bit---I don't want to lie---and my distcheck
> "forgot" examples folder and autopoint-3 test, but my issues with
> these sources are unrelated[1] and I'm confident as the patch does not
> touch any of them.

Indeed, these parts of the builds are unrelated.

> [1] I don't have access to FPC right now, and hello-pascal needs it

Yes, the file HACKING mentions this requirement.

> The second problem is that git describe is
> assigns 0.19.8.1.520-672cb-dirty as my version, instead of
> 0.20.xxx-672cb-dirty.

This will be fixed once you do a fresh "git clone" of the gettext repository.
Explanation: https://lists.gnu.org/archive/html/bug-gnulib/2019-05/msg00080.html

> [5] Although that list is code duplication too.  If this is working,
> I'd like to substitute that MOSTLYCLEANFILES and the other headers with
> a -local rule, calling uninstall-*HEADERS, just the reverse rule to the
> current one.  Should I try?

This looks like overkill. If we need to have the list of these 4 files in one
place in this Makefile.am anyway, I see no point in invoking a recursive make
target rather than just erasing the files in a simple command.

Bruno