Guy, have you had any chance to look at this again? On Thu, 2005-09-22 at 09:42 -0500, David Smith wrote: > On Wed, 2005-09-21 at 21:27, Guy Harris wrote: > > On Sep 21, 2005, at 2:13 PM, David Smith wrote: > > > > > OK, here's a cleaner solution. It does this the "right" way using a > > > cached config variable. > > > > So should that be applied to the configure.in *before* your previous > > patch? > > > > If so, does it mean that there's no need to have the user say where > > the library and headers are installed, even for cross-compiles? > > Sorry for the confusion. This patch completely replaces my last patch. > > Now, when a user wants to cross compile, he sets up ac_cv_ssleay_path in > the environment. > > # export ac_cv_ssleay_path=/path/to/SSLeay/libraries > # configure > > The solution is really the same as the last one, but this solution is > done in the "proper" autoconf way, instead of setting up a mechanism > outside of autoconf. > > The trick here is the use of AC_CACHE_CHECK. Here's the description of > AC_CACHE_CHECK (which really just wraps up AC_CACHE_VAL) from the info > file: > > ============================================================== > - Macro: AC_CACHE_VAL (CACHE-ID, COMMANDS-TO-SET-IT) > Ensure that the results of the check identified by CACHE-ID are > available. If the results of the check were in the cache file > that was read, and `configure' was not given the `--quiet' or > `--silent' option, print a message saying that the result was > cached; otherwise, run the shell commands COMMANDS-TO-SET-IT. If > the shell commands are run to determine the value, the value will > be saved in the cache file just before `configure' creates its > output files. *Note Cache Variable Names::, for how to choose the > name of the CACHE-ID variable. > > The COMMANDS-TO-SET-IT _must have no side effects_ except for > setting the variable CACHE-ID, see below. > > - Macro: AC_CACHE_CHECK (MESSAGE, CACHE-ID, COMMANDS-TO-SET-IT) > A wrapper for `AC_CACHE_VAL' that takes care of printing the > messages. This macro provides a convenient shorthand for the most > common way to use these macros. It calls `AC_MSG_CHECKING' for > MESSAGE, then `AC_CACHE_VAL' with the CACHE-ID and COMMANDS > arguments, and `AC_MSG_RESULT' with CACHE-ID. > > The COMMANDS-TO-SET-IT _must have no side effects_ except for > setting the variable CACHE-ID, see below. > ============================================================== > > Here's the associated example from the info file: > > ============================================================== > AC_DEFUN([AC_SHELL_TRUE], > [AC_CACHE_CHECK([whether true(1) works], [ac_cv_shell_true_works], > [ac_cv_shell_true_works=no > true && ac_cv_shell_true_works=yes]) > if test $ac_cv_shell_true_works = yes; then > AC_DEFINE([TRUE_WORKS], 1 > [Define if `true(1)' works properly.]) > fi > ]) > ============================================================== > > So, what goes on here is this. > > In the native build case, ac_cv_ssleay_path won't be set in the > environment. So, the code to find the right directory will be run. > > In the cross build case, the user is responsible to setting up > ac_cv_ssleay_path in the environment. When this section of configure is > hit, configure realizes that ac_cv_ssleay_path is already set, and will > skip the code to find the right directory. > > In both cases, the final code to set V_INCLS and LDFLAGS is set with the > value of ac_cv_ssleay_path (assuming it isn't 'no'). > -- David Smith [EMAIL PROTECTED] Red Hat, Inc. http://www.redhat.com 256.217.0141 (direct) 256.837.0057 (fax)
- This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
