[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: using macro ...
From: |
Eric Blake |
Subject: |
Re: using macro ... |
Date: |
Fri, 08 Feb 2013 11:28:40 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 |
[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? 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? Would using AC_COMPUTE_INT be any less fragile than
directly grepping a platform header?
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature