Hello list,
I wonder if anyone could take a look at the following issue I'm having over
the expansion of the first expaqnsion of AC_CHECK_HEADER.
The first expansion of AC_CHECK_HEADER rightly brings in code to check for
the pre-requisites needed to perform the check (C preprocessor, compiler,
standard headers, etc.) if the checking code hasn't already been generated
(via previous use of relevant AC_PROG_... or AC_HEADER_STDC macros). My
problem is that this code is being generated at an inconvenient point for me
(within a for loop which means it is multiply executed).
I can move the generated code out of the for loop if I use an AS_FOR, but
that causes further problems. If, as intended, I use the AS_FOR macro rather
than the iterator variable, I run into problems because the substitution
isn't putting {} around the iterator variable. Specifically:
I'm trying to do a
for var in $list
do
AS_VAR_COPY([var2],[var3_${var}_details]])
:
:
which generates an assignment of
eval var2=\$var3_${var}_details
if I use
AS_FOR([AC_MY_VAR],
[var],
[$list],
[AS_VAR_COPY([var2],
[var3_]AC_MY_VAR[_details]
)
:
:
]
)
the assignment generated is
eval var2=\$var3_$var_details
which isn't really what is required
I presume, by definition I really should be using the AC_MY_VAR macro rather
than iterator variable ($var) directly (although that does actually work in
this instance; at the moment...). Is this assumption flawed, or can anyone
suggest a way to force the substitution I require? I know I can use an
intermediate variable to first accept the value of AC_MY_VAR and then use
the new variable in
the AS_VAR_COPY. I'm just wondering if someone knows of a clever technique
(to do it without the extra variable) that I can add to the mental toolbox.
I suppose, the other question is whether there is an argument for the macro
substitution from AS_FOR enclosing the variable in curly braces.
Going back to the original issue (the pre-requisite checking introduced by
AC_CHECK_HEADER), another possible solution to my problem is to ensure this
checking is manually performed up front. Actually, I'd argue this is the
method that should be used anyway; the configure script specifically
checking for everything that is required, rather than relying on the
implicit checks catching things the programmer hasn't directly considered.
The problem I am having with with this approach is that checking for the
likely suspects (CPP, compiler, etc.) isn't exhausting all the implicit
checks. The first call to AC_CHECK_HEADER still generates code to check for
certain system headers. These appear under the heading "# On IRIX 5.3,
sys/types and inttypes.h are conflicting.". The code also defines the
ac_includes_default variable but as that assignment is placed in the
DEFAULTS section, its code placement isn't directly an issue. This checking
code is being brought in by the expansion of
_AC_INCLUDES_DEFAULT_REQUIREMENTS. Now, I can obviously include this macro
in my initial setup-checking code and this does move the checks to a more
suitable location in my configure script. However, am I right in assuming it
isn't a good idea to be using internal macros? If not, is there a reason
this is only internal?
Thanks for your attention and apologies for the length of this email.
Regards,
John.
--
View this message in context: http://old.nabble.com/Positioning-code-from-first-expansion-of-AC_CHECK_HEADER-tp30444236p30444236.html
Sent from the Gnu - Autoconf - General mailing list archive at Nabble.com.
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
