bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

adding vasprintf pulls in vasnprintf


From: Simon Josefsson
Subject: adding vasprintf pulls in vasnprintf
Date: Thu, 23 Aug 2007 18:16:00 +0200
User-agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux)

Hi!  GnuTLS uses vasprintf (in just one place...) so I depend on the
vasprintf module.  On glibc systems, vasprintf exists and is properly
detected:

checking for vasprintf... yes

However, the vasprintf module depends unconditionally on vasnprintf, see
gnulib/modules/vasprintf:

Depends-on:
vasnprintf

On glibc systems, vasnprintf does not exists:

checking for vasnprintf... no

Since there is an unconditional dependency on vasnprintf in the
vasprintf module, even though I do not need vasnprintf, the
gnulib-comp.m4 that gnulib-tool generate contains:

  gl_FUNC_VASNPRINTF

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.  Any ideas on how to solve this?

One solution would be for the vasprintf module to not depend on the
vasnprintf moulde explicitly, but list all the required files in the
Files: section.  This is the approach I took for the gc-* modules, where
it is simple to handle.  However, the vasnprintf module is quite large:

Files:
lib/float+.h
lib/printf-args.h
lib/printf-args.c
lib/printf-parse.h
lib/printf-parse.c
lib/vasnprintf.h
lib/vasnprintf.c
lib/asnprintf.c
m4/wchar_t.m4
m4/wint_t.m4
m4/longlong.m4
m4/intmax_t.m4
m4/stdint_h.m4
m4/inttypes_h.m4
m4/eoverflow.m4
m4/vasnprintf.m4

Depends-on:
alloca-opt
float
stdint
xsize

The files recursively needed by the vasnprintf depends-on modules (i.e.,
alloca-opt, float, stdint, xsize, and their dependencies recursively)
would need to be listed as well:

lib/alloca_.h
m4/alloca.m4
lib/float_.h
m4/float_h.m4
lib/stdint_.h
m4/stdint.m4
m4/longlong.m4
m4/ulonglong.m4
lib/xsize.h
m4/xsize.m4
m4/size_max.m4
lib/size_max.h
m4/include_next.m4
lib/wchar_.h
m4/wchar.m4
build-aux/link-warning.h

This becomes a maintenance nightmare: every time one of the recursive
dependencies of vasnprintf changes, the vasprintf module has to be
updated.  I'm thus reluctant to propose something like this.

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.

What do you think?

I'm not sure this is the best approach to solve it.

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

Thus, the vasnprintf module can't know if the vasprintf module will be
needed or not, since the latter M4 functions haven't been invoked yet.

/Simon




reply via email to

[Prev in Thread] Current Thread [Next in Thread]