[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
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
