[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.
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
- LIBDEPS vs. module Link: directive,
Eric Blake <=