<div class="gmail_quote">On Wed, Aug 11, 2010 at 2:52 PM, Erik Lindahl <span dir="ltr"><<a href="mailto:lindahl@cbr.su.se">lindahl@cbr.su.se</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi Sean,<br>
<div class="im"><br>
On Aug 11, 2010, at 8:08 PM, Sean McBride wrote:<br>
<br>
> On Wed, 11 Aug 2010 18:08:35 +0200, Erik Lindahl said:<br>
><br>
>> All the CheckTypeSize() tests then seem to run directly when e.g. ccmake<br>
>> is invoked, and they thus set all SIZEOF_XXX defines to the 64-bit<br>
>> values (e.g. 8 for "long int").<br>
><br>
> Why do you need to know the size of 'long'? Its size is not guaranteed<br>
> by the language spec. If you're writing portable code, you should not<br>
> assume any more than the language guarantees.<br>
><br>
> If you need an integer of a specific size, use types like int32_t or<br>
> int64_t. These are part of C99 and C++0x. If they don't exist on some<br>
> platform you need to support, they are easy to typedef.<br>
<br>
</div>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.<br>
<br>
However, let's leave the "why" aside for now - I already worked around the specific issue.<br>
<br>
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<br>
<br>
(1) change the OS X architecture and<br>
(2) check for things at configuration time,<br>
<br>
it's also a pretty reasonable goal to try and get the correct result from those test - isn't it? :-)<br>
<br>
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)?<br>
<div class="im"><br><br></div></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.....</div>
<div><br></div><div>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.</div>
<div><br></div><div><br></div><div>HTH,</div><div>David</div><div><br></div></div>