[CMake] Converting from autoconf to cmake problem

Aaron Turner synfinatic at gmail.com
Tue Nov 2 22:39:02 EDT 2010


On Tue, Nov 2, 2010 at 6:09 PM, Clifford Yapp <cliffyapp at gmail.com> wrote:
> On Tue, Nov 2, 2010 at 12:24 PM, Aaron Turner <synfinatic at gmail.com> 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"


More information about the CMake mailing list