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

[Miguel]

Hi again,

Bruno Haible wrote:
> Hello Kiyoshi,
> 
> Kiyoshi KANAZAWA wrote:
> > textstyle.h, textstyle/stdbool.h, textstyle/version.h &
> > textstyle/woe32dll.h are installed every time run 'make', even if
> > after make completed.
> > 
> > This is caused by ".PHONY:", because textstyle-headers-installed is
> > not a real file.  

Thank you very much, Kiyoshi, that was exactly the doubt I've already
expressed with the first patch.

> Even with this hint, I don't understand why Miguel's patch did not
> work out w.r.t. "make distcheck".

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.

I've been away from the computer all day and I couldn't test it until
now, but "it works for me"(TM).  Also, I'd like to explain better the
problem and the make POV, not only as a small comment in the code, as
the more understanding we have, the better we will solve any related
issue.

Make Point Of View:
------

1. Make parses the desired target and its dependencies recursively, and
generates the DAG of the required steps.
1.1. As per its specification, rules like this:
----
all: file1 file2 file3
        do-something
file1 file2: file3
        generate-both-files
----
are actually interpreted as this:
----
all: file1 file2 file3
        do-something
file1: file3
        generate-both-files
file2: file3
        generate-both-files
-----

1.1.1. This is not a translation problem[2], as this is *not* what make
sees. The language interpreter (as a virtual machine, not the
implementation itself) would see something like the following ASCII
drawing in terms of "uml-like objects":

+---------+                                            +---------+
|   all   |                                            |  file3  |
+---------+                                            +---------+
| depend =|=======++==++=============================> | depend =|> nil
| recipe =|=++    ||  ||                               | recipe =|> nil
+---------+ ||    ||  ++===============>+---------+    +---------+
            \/    ++===> +---------+    |  file2  |      /\ /\
       do-something      |  file1  |    +---------+      || ||
                         +---------+    | depend =|======++ ||
                         | depend =|=X  | recipe =|==++ X===++
                         | recipe =|=++ +---------+  ||
                         +---------+ ||              \/
                                     \/    generate-both-files
                          generate-both-files

2. Each node of the DAG is a target itself, so serialization is
introduced per-level: child target construction "happens-before"[4]
the construction of the current node, recursively.

2.1. The introduced order allows the parallel generation of file1 and
file2.  It is not a bug that make does not know the content of its
recipe more than VPATH details.  It provides the variables $< and $@ to
solve these problems, but there are two targets declared and two
references to generate-both-files in the graph.  I'm pretty sure
that solving its actual identity---correctly, in any case---is
equivalent to the Entscheidungsproblem (Hilbert/Turing/Church.)

2.1.1. In sequential execution make just finds file2 (or file1, the
order is not imposed by the language since it has parallelism and GNU
encourages its usage) as a matter of luck after generating file, so it
doesn't execute generate-both-files twice because it passes the
requirement checks (the file exists and it is newer than its
dependencies, this check is always ignored for PHONY targets, that
was the problem with my first patch AFAIU.)

3. Generic rules for bison do work with parallel compilations, because
they only introduce one dependency (the .c file, not the .h), as the
rule is introduced by the standard pattern ".y.c".

Reasons behind this implementation:
------
1. I tried to keep the dependency chain for the generated header files,
as they are used for more generations, even though they are redundant
and only one file is needed.

2. The rule involving .o and .lo files is removed, as it could cause
trouble with automake[4], and it is replaced with the dependency on
the .h file.

3. I left textstyle.h as the only target for the installation, the other
files are dependencies. I'm not happy with this target yet, but I agree
that the duplication of the code from libtextstyle is not the way to
go[5].

4. I tried to minimize the changes.
------

What do you think?

Happy hacking,
Miguel

--------------------------------------------------------------------------
[1] I don't have access to FPC right now, and hello-pascal needs it, so
I created a link to true.  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.  I've not even investigated this one, I have to
check it better.
[2]
http://pubs.opengroup.org/onlinepubs/009695399/utilities/make.html#tag_04_84_13_01
[3] https://en.wikipedia.org/wiki/Happened-before [4]
https://www.gnu.org/software/automake/manual/html_node/Extending.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?

0001-build-Fix-parallel-compilation.patch
Description: Text Data