[CMake] OS X architecture changes interfere with CheckTypeSize()?

[David Cole]

On Wed, Aug 11, 2010 at 2:52 PM, Erik Lindahl <lindahl at cbr.su.se> wrote:

> Hi Sean,
>
> On Aug 11, 2010, at 8:08 PM, Sean McBride wrote:
>
> > On Wed, 11 Aug 2010 18:08:35 +0200, Erik Lindahl said:
> >
> >> All the CheckTypeSize() tests then seem to run directly when e.g. ccmake
> >> is invoked, and they thus set all SIZEOF_XXX defines to the 64-bit
> >> values (e.g. 8 for "long int").
> >
> > Why do you need to know the size of 'long'?  Its size is not guaranteed
> > by the language spec.  If you're writing portable code, you should not
> > assume any more than the language guarantees.
> >
> > If you need an integer of a specific size, use types like int32_t or
> > int64_t.  These are part of C99 and C++0x.  If they don't exist on some
> > platform you need to support, they are easy to typedef.
>
> That's exactly the reason we test it at configure time - e.g. to find a
> data type to use for 4-byte integers, and whether there is any 8-byte type
> present for ~50 different OS/compiler combinations.
>
> However, let's leave the "why" aside for now - I already worked around the
> specific issue.
>
> Still, there are tons of other things at configure time that might depend
> on your architecture, and CMake has plenty of routines for such tests, so
> hopefully we can agree that if CMake allows the user to
>
> (1) change the OS X architecture and
> (2) check for things at configuration time,
>
> it's also a pretty reasonable goal to try and get the correct result from
> those test - isn't it?  :-)
>
> Thus, back to my question: Wouldn't it make sense in this case to force the
> user to set the OS X architecture(s) at the same time as the compiler,
> and/or invalidate the cache when it changes? (just as CMake already does for
> the compilers)?
>
>
>
Yes... that would make sense. The thing that's missing now is the notion
that some cache values depend on other cache values. And when the inputs
change, re-evaluations need to take place on the next configure.

It would be better to be able to express such cache-clearing behavior as a
"this variable depends on that one" sort of mechanism. Otherwise, you have
to reset *everything* in the cache when one thing in the cache changes. And,
in general, you can't do that, because you don't know if the cache values
came from an original command line invocation with -D arguments that
shouldn't now be changed, or if they came from the user and they'll be mad
if you change them, or if they came from a script that depends on the result
matching the script's specification.....

It's a vexing problem, but for now, I think it's safe to say that your only
option with existing CMake is to specify it correctly the first time. Or if
not, to recognize that a manual rm -rf is in order.


HTH,
David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20100811/a2c2de23/attachment.htm>