Another approach that I'd like to try: avoiding the CMake "magic" compiles that 
it uses to determine endianness and bitness. Since those are unlikely to change 
on our hardware without our noticing, this would work fine. Is it possible? I 
saw a reference that suggested it was, but haven't found it in the doc yet.

It's big endian and 64-bit; ints are 32 bits, doubles are 64 bits. Not sure 
what else those compiles do?

(This also might let us use a current CMake, since IIRC it was the CMake step 
that hung.) And a note re this: I said before that we were doing out-of-source 
builds; I meant we're doing in-source builds. It's been years since I had to 
think about this, sorry.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Reply via email to