On Tue, Nov 2, 2010 at 6:09 PM, Clifford Yapp <[email protected]> wrote: > On Tue, Nov 2, 2010 at 12:24 PM, Aaron Turner <[email protected]> wrote: >> >> Michael brings up a good point and I'd take it one step further. >> Rather then re-creating the laundry list of Autoconf macros, I'd >> rather just see a few macros like: >> >> CMAKE_CHECK_C99_COMPATIBILITY >> CMAKE_CHECK_PLATFORM_BITS >> CMAKE_CHECK_POSIX_COMPATIBILITY >> CMAKE_CHECK_BSD_COMPATIBILITY >> >> Which are basically are best practices for checking your compiler for >> C99, etc and if your platform is 32 or 64 bits. These macros would >> provide both individual feature results and a single yes/no for each >> group. > > I agree those would be good ideas, but I think the way to do them is > to have the individual macros (most of which will probably map to AC > macros, since that's more or less what their job is) and then have > parent macros along the lines of the ones you describe. This lets > people do the high level calls if they want/need all of the tests for > a given question, and still lets people pick and choose if they only > need a subset of the full tests.
That's fine. But IMHO most people would be better served just testing for C99 or C89, etc then picking and choosing. Note: I'm not saying the macro's shouldn't enumerate each feature individually, but it's easier and less error prone to group them intelligently. > Remember some situations (old corporate computers that can't be > replaced for policy reasons) may still have code bases that require > the older tests - they should not be included by default in the above > parent macros (which can just set them to their default success/fail > state as appropriate), but some situations are likely to still need > them. I'd say don't implement the obsolete ones unless they either > already are done or there is clear demonstrated user need for them, > but don't rule them out. Sure no argument there- the more canned tests the better. From an ROI perspective though, IMHO, we're better off concentrating on the newer standards and then working backwards. >> Ideally cmake would also provide a sample config.h template with the >> appropriate #cmakedefine entries. > > That's a possibility, but another option might be to generate the > config.h.in file based on the tests - I'm doing this with BRL-CAD via > some wrapper macros and it seems to be doing fine - sort of a poor > man's autoheader. "config.h template" == "config.h.in" so yeah, we're saying the same thing I suspect. :) But yeah, a Cmake version of autoheader would be really nice. -- Aaron Turner http://synfin.net/ Twitter: @synfinatic http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Windows Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin "carpe diem quam minimum credula postero" _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
