I want to implement the --with-package=DIR option to my project's
configure script. The --with-package[=yes|no] thing is straightforward
using AC_ARG_WITH(). I have however some questions regarding others'
experience wth the =DIR part.
1. What should I do if the user is so dumb to actually give a DIR
which does not exist? IMHO, I should issue an AC_MSG_ERROR and
terminate the configuration: we cannot configure taking into account
the user's input. What do you think of that and is there a consensus
on how to handle such a situation.
AC_MSG_ERROR is what I'd go for.
Very good. Thanks Benoit. Any thoughts from other readers?
2. How can I detect that /path/to/foo helps in any way for accessing
foo.h and libfoo.a? Specifically, if library foo is available in the
system directories (e.g. /usr/include and /usr/lib), then providing
--with-foo=yes and --with-foo=/wrong/path/to/foo will have the same
effect.
>> [...]
The autoconf way of dealing with this is to test the user's input. If
you know that libfoo *must* come with a header, say, foo.h, you can test
whether this header is usable with AC_CHECK_HEADERS [1] for instance.
Then it is generally a good idea to test that the header "works".
> [...]
Similarily, you should test that you can link with libfoo and try to
compile (with AC_COMPILE_IFELSE [3] for instance) a small main that uses
one of the symbols of libfoo.
During these tests, you will have to add flags in CPPFLAGS (-I...) and
LDFLAGS (-L... -l...).
[...]
I hope this helps.
Thank you again Benoit. Your help is much appreciated and I learned
quite a lot on how to test the usability of library foo at configure
time. I had come with something quite similar but not that 'clean' and I
will revise my configure.ac taking into account your inputs.
However, your input does not exactly answer the concerns I expressed in
my original question 2) :-).
Which is that library foo (foo.h and libfoo.a) might exist in two or
more locations on the machine. And it might very well happen that one of
these versions resides in the 'system' directory for CC (e.g.
/usr/{include,lib}). In that case '--with-foo' is enough to pass all
your (and mine) previously introduced tests. Always in that case,
--with-foo=*/wrong/path/to/lib* will still pass our tests (using the
same default/system version of foo). That is because CFLAGS and LDFLAGS,
when 'useless' (or 'wrong'), have no effect on CC and LINKER (at least
for gcc). Specifically, the user might give
--with-foo=/home/loginname/local/ (thinking foo.h is in
/home/loginname/local/include) but his version of foo is in fact
installed in /home/loginname/local/foo/ (foo.h being in
/home/loginname/local/foo/include/).
So... any idea?
PS: I know my user should NOT have a local and modified version of foo
with the same file names and same version number. In my case he does AND
provides a /wrong/path/to/lib at configure time. We might as well damn
him and let him rot in hell. But we might as well not, if possible.
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
