Re: using macro ...

[raespi]

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>' )