[CMake] Help with libintl/configure tests

Bill Hoffman bill.hoffman at kitware.com
Wed Apr 23 21:59:36 EDT 2008


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


More information about the CMake mailing list