[Top][All Lists]

[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.

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 

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]