Ralf Wildenhues wrote: > * Jim Meyering wrote on Thu, Oct 15, 2009 at 09:06:16PM CEST: >> Subject: [PATCH] don't let environment settings perturb build >> >> Setting the envvars, LIB_CLOCK_GETTIME, LIB_EACCESS or LIB_NANOSLEEP >> could cause a configure-time and/or build-time malfunction. >> Typically, a configure-time function-in-library test is performed >> via code like this: >> >> LIB_VAR= >> AC_SUBST([LIB_VAR]) >> prefix_saved_LIBS=$LIBS >> AC_SEARCH_LIBS([FUNC], [LIB_NAME], >> [test "$ac_cv_search_FUNC" = "none required" || >> LIB_VAR=$ac_cv_search_FUNC]) >> LIBS=$prefix_saved_LIBS >> >> However, in each of the files affected by this change, the LIB_VAR= >> initialization was omitted. Thus, when set in the environment, its >> value would propagate into generated Makefiles when FUNC is not found >> in LIB_NAME.
Hi Ralf, > Wouldn't it be just as consistent to just document that LIB_<VAR> can be > used to override the respective macro, for systems on which a library > other than one known to the macro, may be needed? Most of the uses I saw already had the initialization. I fixed the few that did not. Add the fact that I've never needed (or heard of a need) to pre-seed to override AC_SEARCH_LIBS results, and that was enough for me. > That would be in line with how many Autoconf macros work: the AC_SUBSTed > variable may be overridden by the knowledgeable end user, who may know > better than the macro author. > > Aside, have you experienced a configure-time and/or build-time > malfunction with this? > >> * m4/clock_time.m4 (gl_CLOCK_TIME): Initialize AC_SUBST'd var. >> * m4/euidaccess.m4 (gl_PREREQ_EUIDACCESS): Likewise. >> * m4/nanosleep.m4 (gl_FUNC_NANOSLEEP): Likewise. No. However, I prefer to insulate code and tests from the vagaries of the environment whenever possible/reasonable.