Tim Holy wrote:
Hi,
I volunteer on a project called Tux4Kids, which creates free & open-source
educational software for children. I'm trying to develop a CMake build for
TuxMath, our arithmetic arcade game, so that we can better-support MacOSX.
I'm definitely a CMake newbie---this is my first experience with it. Thanks to
CMake's nice design and good documentation, I was able to quickly and quite
painlessly develop a build for most of our source tree. Thanks!
Then I got to the internationalization bit. We currently have an
automake-based build that, on platforms like MacOSX and Win32, builds the
getttext-runtime library libintl as a static library (because we can't
guarantee that this library is available on anything but Linux). I'm having a
lot of trouble getting that working with CMake, and I think it's because I
just don't understand it well enough. (I don't understand automake well
enough, either---other people did that.) However, I have also based a lot of
what I'm doing on LyX, which has a well-developed (over the course of several
years) CMake infrastructure, and I see weird things happening there, too.
libintl has a number of flags that need to be probed for. Here's
a "ConfigureChecksIntl.cmake" file that I'm working on, along with comments
about how things work out:
check_include_files(inttypes.h HAVE_INTTYPES_H) # works fine
check_symbol_exists(snprintf "stdio.h" HAVE_SNPRINTF) # agrees with automake
check_symbol_exists(asprintf "stdio.h" HAVE_ASPRINTF) # disagrees with AM
check_symbol_exists(wprintf "stdio.h" HAVE_WPRINTF) # disagrees with AM
check_symbol_exists(printf "stdio.h" HAVE_POSIX_PRINTF) # agrees with AM
# Alternate for HAVE_POSIX_PRINTF: which is right?
# This is stolen from the m4 file, but it doesn't yield the same answer as
# automake. Maybe I have character escape sequence problems?
check_c_source_compiles("
#include <stdio.h>
#include <string.h>
static char format[] = { '%', '2', '$', 'd', ' ', '%', '1', '$', 'd', '\0' };
static char buf[100];
int main ()
{
sprintf (buf, format, 33, 55);
}" HAVE_POSIX_PRINTF)
# Neither of the following 2 work properly, strangely
#check_symbol_exists(intmax_t "inttypes.h" HAVE_INTTYPES_H_WITH_UINTMAX)
check_symbol_exists(intmax_t "stdint.h" HAVE_INTTYPES_H_WITH_UINTMAX)
# This next one also disagrees with AM, and it causes compilation to fail
check_symbol_exists(uintmax_t "stdint.h" HAVE_STDINT_H_WITH_UINTMAX)
check_symbol_exists(LC_MESSAGES "locale.h" HAVE_LC_MESSAGES) # agrees with AM
check_type_size(intmax_t HAVE_INTMAX_T) # disagrees with AM
# This last macro was stolen from LyX
macro_bool_to_01(HAVE_UINTMAX_T HAVE_STDINT_H_WITH_UINTMAX)
The really weird thing is that those symbols "intmax_t" and "uintmax_t" fail
to be found. I've snipped out the part of stdint.h that seems relevant:
/* Largest integral types. */
#if __WORDSIZE == 64
typedef long int intmax_t;
typedef unsigned long int uintmax_t;
#else
__extension__
typedef long long int intmax_t;
__extension__
typedef unsigned long long int uintmax_t;
#endif
So, I don't understand why this isn't discovering that these types have been
declared. Can anyone offer some insight?
Best thing to do is to use --debug-trycompile. Remove the cache entries
for uinitmax_t from the CMakeCache.txt so the test will be run again.
Then run cmake --debug-trycompile. This will leave the test code around
and you can look at it and figure out why it is not working. Also, as a
first step you can look at CMakeError.log and CMakeOutput.log in the
CMakeFiles directory of your build tree, and it should show the compile
error that caused the symbols not to be found.
-Bill
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
