bug-gnulib
[Top][All Lists]
Advanced

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

LIBDEPS vs. module Link: directive


From: Eric Blake
Subject: LIBDEPS vs. module Link: directive
Date: Mon, 31 Mar 2008 16:41:11 +0000 (UTC)
User-agent: Loom/3.14 (http://gmane.org/)

Back in 2006, gnulib-tool added support to generate the variable 
LIB<FOO>_LIBDEPS that could be used in Makefile.am to pull in any libraries 
required by gnulib but not the main program.
http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=a262d09e

However, this doesn't seem to work unless the module description takes pains to 
edit gl_libdeps.  And right now, only crypto/gc, striconv, and striconveh do 
so.  This bit me in M4, where strtod now triggers a replacement that requires 
POW_LIB (-lm) on many more platforms than what it used to do, so I had to edit 
my Makefile.am to add $(POW_LIB) to m4_LDADD even though it was already using 
$(LIBM4_LIBDEPS).

On the other hand, there is the more recent addition of the Link: directive in 
modules, which was added to make gnulib-tool output mention that clients of a 
gnulib library might need to add $(POW_LIB) to their Makefile.am.  Would it be 
possible to make the existence of the Link: directive smart enough to auto-
update the gl_libdeps magic so POW_LIB and friends get added to 
LIB<FOO>_LIBDEPS?  That way, projects that are okay with using the simpler 
$(LIB<FOO>_LIBDEPS) notation will not need any Makefile.am edits, no matter 
what dependent library changes are required as gnulib is updated.

-- 
Eric Blake






reply via email to

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