Re: [bug-libunistring] Improve parallel build.

[Bruno Haible]

Hello Ralf,

Ralf Wildenhues wrote on 2009-05-04:
> > >   Build intermediate objects using a parallelizable sub-make
> > >   invocation.
> > 
> > Unfortunately, I find this sub-make invocations horrible from a
> > maintainability point of view. ...
> 
> I agree that recursive 'make' invocations can be hard to understand,
> especially if they are not used for simple directory recursion.
> However, the underlying problem here, as I see it, is that the
> libunistring build does not have a direct acyclic graph structure,
> in that one file name is used for two different purposes: for example,
> memcmp2.o is both used as object to be added to the libunistring
> library, as well as intermediate file used to find out the names of
> exported identifiers.
> 
> Without this complication, it would be possible to write clean rules
> without the hacks which are used in the current config.h rule.

I agree that it would be cleaner to have a directed acyclic graph of
files and dependencies, and not erase files like memcmp2.o in unrelated
rules.

OTOH, I fear that if I do this, the config.h rule - that I wish should
stay a single rule - would become more complex, and additionally config.h
would be rebuilt after any source change (for example, when memcmp2.c
changed). I want to avoid this, because it takes a lot of time if
--disable-namespacing was not given.

> Quoting bits of the Automake manual (git master):
> 
>      To enable less verbose build rules, both the developer and the user
>      of the package have to take a number of steps.  The developer needs
>      to do either of the following:
> 
>         * Add the `silent-rules' option as argument to
>           `AM_INIT_AUTOMAKE'.
> 
>         * Call the `AM_SILENT_RULES' macro from within the
>           `configure.ac' file.
> 
>      If the developer has done either of the above, then the user of the
>      package may influence the verbosity at `configure' run time as
>      well as at `make' run time:
> 
>         * Passing `--enable-silent-rules' to `configure' will cause
>           build rules to be less verbose; the option
>           `--disable-silent-rules' is the default and will cause normal
>           verbose output.
> 
>         * At `make' run time, the default chosen at `configure' time
>           may be overridden: `make V=1' will produce verbose output,
>           `make V=0' less verbose output.
> 
>      For portability to different `make' implementations, package
>      authors are advised to not set the variable `V' inside the
>      `Makefile.am' file, to allow the user to override the value for
>      subdirectories as well.
> 
>      The current implementation of this feature relies on a non-POSIX,
>      but in practice rather widely supported `Makefile' construct of
>      nested variable expansion `$(VAR1$(V))'.  Do not use the
>      `silent-rules' option if your package needs to build with `make'
>      implementations that do not support it.  The `silent-rules' option
>      turns off warnings about recursive variable expansion, which are
>      in turn enabled by `-Wportability' (*note Invoking Automake::).

Thanks for this documentation. (Silly me for having talked about it
without reading its documentation first!) I agree that
  1) putting the power into the user's hands,
  2) making --disable-silent-rules the default
were the good choices to make.

Bruno