Re: adding vasprintf pulls in vasnprintf

[Bruno Haible]

Hi Simon,

> This causes vasnprintf.lo to be built, even though I don't need it!
> 
> address@hidden:~/src/gnutls/lgl$ ls *.lo
> asnprintf.lo  gc-libgcrypt.lo    md2.lo          printf-parse.lo  
> vasnprintf.lo
> dummy.lo      gc-pbkdf2-sha1.lo  printf-args.lo  read-file.lo
> address@hidden:~/src/gnutls/lgl$ 
> 
> Note that vasprintf.lo is not built.
> 
> This situation seems sub-optimal.

We have lived with it so far; the only negative effect (other than a few
milliseconds of build time) is that you get some dead code in the shared
library.

> Another solution would be for us to add a new statement in modules/*
> files: 'Depends-on-optionally'.  Then the vasprintf module could have
> this patch:
> 
> -Depends-on:
> +Depends-on-optionally:
>  vasnprintf
> +
> +Depends-on:
>  stdio
> 
> Gnulib-tool would do exactly the same as it does today for 'Depends-on',
> that is pull in all the required modules and their dependencies
> recursively, however, it would _not_ add the configure.ac statements
> from the required modules into gnulib-comp.m4.

You also need to specify somewhere under which conditions the dependency
becomes real. In the static library case, it has been the linker who
detects this automatically. Now, you need to specify it. Where and how
should this be specified?

> Still another alternative may be for the modules/vasnprintf file to
> contain a more complex configure.ac statement, that wouldn't call the
> vasnprintf M4 function all the time.  However, it seems the generated
> gnulib-comp.m4 is sorted alphanumerically rather than in
> module-dependency order:
> 
>   gl_FUNC_VASNPRINTF
>   gl_FUNC_VASPRINTF

This can be solved through some macrology.

In general, sorting in alphabetic order guarantees reproducible results.
There is no such thing as "module-dependency order" in general since there
may be circular dependencies among modules.

Bruno