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 configure.ac 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 configure.ac 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. Richard _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
