bug-gnulib
[Top][All Lists]
Advanced

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

Re: [PATCH] don't let environment settings perturb build


From: Ralf Wildenhues
Subject: Re: [PATCH] don't let environment settings perturb build
Date: Sat, 31 Oct 2009 09:26:43 +0100
User-agent: Mutt/1.5.20 (2009-08-09)

Hello Jim, all,

sorry for chiming in late.

* 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.

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?

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.

Cheers,
Ralf




reply via email to

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