[Top][All Lists]

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

Re: Passing an argument to configure script of subproject

From: Richard Ash
Subject: Re: Passing an argument to configure script of subproject
Date: Wed, 02 Jun 2010 21:14:42 +0100

On Wed, 2010-05-26 at 23:43 +0200, ithilgore wrote:
> The problem is that in order to share libfoo between the two projects (that
> is both can fetch it as an external svn object), projectA needs to pass a
> certain flag to the configure script of libfoo. This flag/argument would be
> something like --disable-bar where bar is something that projectA doesn't
> have (It's actually another library that can be optionally linked with
> libfoo but is by default linked with and needed by projectB)
> The question is: How can you pass an optional argument to the configure
> script of libfoo by projectA? This argument should be passed externally
> only by projectA so the solution of using "configure.gnu" residing inside
> libfoo wouldn't work because that way projectB would then call it too
> (since libfoo should be a shared svn object between the two projects).
> projectA uses a with a AC_CONFIG_SUBDIRS directive to call the
> configure script of libfoo. projectB does the same too.
> By searching a bit in the configure script I saw that there is a certain
> variable "ac_sub_configure_args" which if hacked in the configure script
> itself and filled with a value, then that value is passed along on all
> configure scripts called by AC_CONFIG_SUBDIRS. However, I found no way of
> doing it normally by defining the variable in the file. On the
> other hand, this variable is then passed to all configure scripts of other
> libraries that reside under projectA. So the question can be summed up to:
> is there a way to pass that variable only to the configure script of libfoo
> without affecting the other subprojects?

I haven't found one. I'm vaguely (and unsuccessfully so far) trying to
get round to proposing some pretty major changes to how
AC_CONFIG_SUBDIRS works - so what you describe is possible, and so that
when the sub-configure script gets run is controllable, and the results
can be used in the rest of the configure script.

I'm not an m4 programmer however, so whether I can get anything included
into upstream autoconf is another question.


reply via email to

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