[CMake] Converting from autoconf to cmake problem

[Clifford Yapp]

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.

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.

> 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.

CY