El 02/08/2013 01:28 PM, Eric Blake escribió:
[please don't top-post on technical lists]
On 02/08/2013 11:09 AM, raespi wrote:
Studying a bit more the code, this weird macro gets called like so:
AC_SUBST_INT_HEX(T_FPU, native/task.h)
This line substitutes a variable in a file task_mode.hh.in ( notice the
.in at the end ):
typedef flag<@T_FPU@> fpu_flag;
This behavior sounds like whoever wrote AC_SUBST_INT_HEX was calling
AC_SUBST_UNQUOTED([T_FPU], [$value], [documentation])
somewhere inside.
And fetches the value of the T_FPU macro ( XNFPU ) in the native/task.h
file:
#define T_FPU XNFPU
And this part (figuring out what to pass for the $value of the
AC_SUBST_UNQUOTED) sounds like it is doing something as naive as:
value=`sed -n 's/.*#.*define.*T_FPU[ ]*//p' native/task.h`
The resulting file task_mode.hh gets generated like so:
typedef flag<XNFPU> fpu_flag;
Do you know if XNFPU is a numeric constant? Is the generated file
actually using a symbolic constant instead of the numeric value of that
constant?
yes it is in another header file:
#define XNFPU 0x00100000
Also, grepping native/task.h in order to reuse one of its
values in the generated task_mode.hh file feels inherently fragile -
that sounds like it is platform-specific, as it is not a standard header.
Can you look at the resulting configure file to see what really got
emitted, if you are trying to reverse-engineer what AC_SUBST_INT_HEX
expanded to?
the resulting configure file generated this:
T_FPU=T_FPU
but I imagine it not to be the desired output. It surely works, but I
think that storing the original numeric value would be less troublesome
since I don't have to include their header files in everyone of the .in
files.
Would using AC_COMPUTE_INT be any less fragile than
directly grepping a platform header?
something like ?
AC_COMPUTE_INT( T_FPU, "T_FPU", include='<native/task.h>' )
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
https://lists.gnu.org/mailman/listinfo/autoconf
