[EMAIL PROTECTED] (Karl Berry) writes:
> Does all that sound reasonable?
Yes, though to be honest I don't yet understand the need for libopts.
> I guess define a new module. I confess I am not clear on the exact
> steps to do this.
The most important step is to write a file that goes into the modules/
directory, which uses the same syntax as the other files. You also
need to modify MODULES.html.sh.
> (I guess "; then" would be preferred to "<newline>then"?)
Yes, that's the usual style. But shouldn't this be using
AC_CACHE_CHECK instead?
> + f=`autoopts-config cflags` 2>/dev/null
> + test X"${f}" = X && f=`libopts-config cflags` 2>/dev/null
Generally speaking, the gnulib style is to avoid messing with CFLAGS.
Can this stuff be put into config.h instead?
> + LIBS="${LIBS} ${f}"
Similarly, it's better not to set LIBS. Instead, I would set (say)
LIB_LIBOPTS, which the user can mention as needed, in their makefiles.
> + AC_DEFINE([HAVE_LIBOPTS],[1],[define if we can find libopts])
But 'autoopts-config cflags' doesn't tell you whether you can find
libopts. Only finding libopts is likely to do that. The macro should
be using AC_LINK_IFELSE (say) to make sure that libopts is a library
that can be linked to.
Debian, for example, distinguishes between the libopts9 package, and
the libopts9-dev package. So some of libopts might well be present,
while other parts are absent.
> + CFLAGS="${CFLAGS} ${f}"
> + f=`autoopts-config ldflags` 2>/dev/null
On my host, "autoopts-config ldflags" outputs "-Wl,-R/usr/lib
-L/usr/lib -lopts", which it seems to me is more likely to cause
trouble than to fix it. Perhaps this is a libopts bug, perhaps not,
but either way it's not a good sign.
> + test X"${f}" = X && f=`libopts-config ldflags` 2>/dev/null
There are two commands, autoopts-config and libopts-config?
_______________________________________________
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
