autoconf
[Top][All Lists]
Advanced

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

Re: Smart --with-package=DIR (for absentminded users)


From: Thomas Lavergne
Subject: Re: Smart --with-package=DIR (for absentminded users)
Date: Fri, 06 Jul 2007 08:32:19 +0200
User-agent: Thunderbird 1.5.0.7 (X11/20060913)

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.




reply via email to

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