Re: [bug-libunistring] Improve parallel build.

[Bruno Haible]

Hello Ralf,

> The missing dependency of config.h upon exported.sh is a bug

Certainly not. exported.sh gets rebuilt every time './config.status'
is run, and virtually never changes (because exported.sh.in is so tiny
that it's not going to be modified in several years). Such a
dependency would have the effect that each time './config.status'
is run, config.h is regenerated - which takes 30 seconds of time.

If the user wants to reconfigure for a different compiler or
32/64-bit mode, he needs to run "make distclean" first. This is
well-known and documented in INSTALL. "make distclean" will
erase config.h, hence it will be rebuilt.

> Timings on a two-way system:
> [sec]           before  after the patch
> serial          86      84
> parallel        63      53

I have just added a patch that saves even more build time: Not a 20%
speedup, but a 34% speedup. It's an option --disable-namespacing that
disables the entire config.h compilations. Additionally, --disable-static
gives an additional 38% speed increase:

Times of "make" in wall-clock time:
[sec]           before    --disable-namespacing    + --disable-static
serial           128               84                      50
parallel (-j 4)   91               47                      29

To make it clear: The namespace cleanliness of the resulting library
is an *essential* feature for someone who takes a released tarball and
installs it. It an *optional* feature for someone who modifies the
source code and builds the library 10 times in a row.

>       Build intermediate objects using a parallelizable sub-make
>       invocation.

Unfortunately, I find this sub-make invocations horrible from a
maintainability point of view. In CLN, the main Makefile was operating
through recursive "make" invocations in the same directory, and the new
maintainer was completely unable to understand and fix problems with it.

In the case of your patch, I additionally fear that some command-line length
thresholds are exceeded on weird systems (IRIX, Tru64), either in the
backquote, or as arguments to 'make', or as arguments to exported.sh and
'nm'.

> GNU make will execute rules containing the string '$(MAKE)'
> even when in dry-run mode

Eeek. I did not know about this misfeature. One more reason to avoid
sub-make invocations other than into subdirectories.

> Another nice side effect of this patch is that it is more visible what
> is going on.

Good point. Increased transparency is welcome. I add an 'echo' of the
commands being executed.

> (This will be even more visible when used in combination 
> with Automake-1.10c's silent-rules option.)

Well, I don't see why I should use this silent-rules option. It provides
for "prettier" output, but actually reduces transparency. If a user sees

    CC foobar.c

followed by an error message of the compiler, how is he supposed to
know how to produce the preprocessed output? I found out that I could do
"make -n foobar.o", then it would print me the command line.

Is that silent-rules option more for the maintainer for the package,
or more for the user who installs the package without being familiar with
it? It seems to me that the silent-rules option is equally bad for either
type of user.

> - parse $MAKEFLAGS inside the rule, which is a bit tricky,

Too tricky. Let's not go that route.

> On another note, if it were not for the gl_LTLIBOBJS then it would be
> possible to
> - have another, uninstalled library containing all objects with to-be-
>   renamed symbols, created with per-target CPPFLAGS like
>   -Dgenerate_symbols (which causes all object names to be distinct),
> - have config.h #include another header if generate_symbols is not
>   defined, and put all the renames in that other header,
> and then even full dependency tracking could work, in the sense that an
> update to a source file would trigger rebuilding of the helper object,
> the helper library, the header, and then the real object and library  
> only, without rebuilding any other objects.

I see how that would enable dependency tracking. Nice idea. But it's
actually not needed: During normal development, I will use
--disable-namespacing.

Bruno