[PATCH] autoconf & warn CFLAGS clean up

Michael Biebl mbiebl at gmail.com
Wed Apr 25 05:37:32 PDT 2007


2007/4/25, Doug Goldstein <cardoe at gentoo.org>:
> So the current usage of checking whether the compiler supports a
> specific CFLAG kinda sucks because it involves writing out files to /tmp
> based on the current PID which is less than ideal (insert security
> conspiracy theories). It's basically an old copy and paste of D-Bus'
> configure.in
>
> Basically I think cairo has a nice way of making it happen so I've
> basically adapted their solution to HAL and tweaked a little here and there.
>
> Along the way I've also enabled a few extra CFLAGS that I tend to use on
> my own software so you'll notice HAL is a bit noiser when it gets
> compiled with this patch.
>
> The solution essentially uses AC_COMPILE_IFELSE, which is a built in
> autoconf macro rather then relying on writing a file to /tmp and
> compiling that.
>
> It also makes use of autoconf's caching abilities and if the MAYBE_WARN
> variable has not had any changes in it, then it will use the cached
> settings. To force a regen all you need to do is add a white space in
> there. That should help with developer needs as far as minimizing the
> length of autoconf runs.
>
> I plan on providing patches to clean up some of the new warnings
> generated by adding these flags.
>
> Also any suggestions are welcome.

What about creating a separate m4 macro for this compiler tests/flags,
putting it into a separate .m4 file, which can then be dropped into
the (to be created) m4/ directory.
This way the functionality would be nicely separated and easily
reusable in other projects, like PK, CK etc. Much better than copy and
paste. It also wouldn't clutter configure.in.

All you have to do, is to add "ACLOCAL_AMFLAGS = -I m4" to the
toplevel Makefile.am file.

Cheers,
Michael



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?


More information about the hal mailing list