As an experiment on the MinGW/MSYS/wine platform I tried to build cmake from the bash.exe command line as follows:
cmake -G "MSYS Makefiles" \ "-DCMAKE_INSTALL_PREFIX=/z/home/wine/newstart1/cmake/install" \ /z/home/software/cmake/cmake-$CMAKE_VERSION >& cmake.out make >& make.out where CMAKE_VERSION=2.8.5, the above cmake command is executed with the windows binary version of cmake-2.8.5 you can download from kitware, make is the MSYS version, and I am using the 20110802 version of MinGW/MSYS. That make command errored out part way through with the following messages: [ 35%] Building C object Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read.c.obj z:/home/software/cmake/cmake-2.8.5/Utilities/cmlibarchive/libarchive/archive_read.c:572:1: error: conflicting types for 'archive_read_data' z:/home/software/cmake/cmake-2.8.5/Utilities/cmlibarchive/libarchive/archive.h:386:30: note: previous declaration of 'archive_read_data' was here z:/home/software/cmake/cmake-2.8.5/Utilities/cmlibarchive/libarchive/archive_read.c:651:1: error: conflicting types for 'archive_read_data_into_buffer' z:/home/software/cmake/cmake-2.8.5/Utilities/cmlibarchive/libarchive/archive.h:411:22: note: previous declaration of 'archive_read_data_into_buffer' was here make[2]: *** [Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read.c.obj] Error 1 make[1]: *** [Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/all] Error 2 make: *** [all] Error 2 If you compare the types of archive_read_data and archive_read_data_into_buffer in archive_read.c versus archive.h, the *.c versions are ssize_t archive_read_data(struct archive *_a, void *buff, size_t s) int archive_read_data_into_buffer(struct archive *a, void *d, ssize_t len) while the *.h versions are __LA_DECL __LA_SSIZE_T archive_read_data(struct archive *, void *, size_t); __LA_DECL int archive_read_data_into_buffer(struct archive *, void *buffer, __LA_SSIZE_T len); So it appears on the MinGW/MSYS/wine platform at least that something is screwed up with the __LA_DECL and/or __LA_SSIZE_T macros. This is a regression on successful cmake builds on MinGW/MSYS/wine that I have done before. However, I am not sure whether it is the new MinGW/MSYS (the new 20110802 version versus 20101030), the new wine (1.3.27 versus 1.3.9), or the new CMake version (2.8.5 versus 2.8.3) that is the culprit here, but we should know more about that if somebody can tell me where the above macros are #defined. Note, I can do some experimentation with MinGW/MSYS/wine, but it should be intelligently focussed rather than brute force because the whole platform has a huge latency (literally a second) for every time cmake, make, or g++ are executed (and probably most other commands as well, although I have found at least one command in that environment [echo done from bash] that is just as fast as on Linux). As we know, cmake itself and well as the Makefile approach it configures tends to split stuff up into many little commands so when you multiply 1 second latency time the number of those commands, all cmake runs and make runs slow down dramatically when compared to the Linux platform. So, for example, I had to wait an hour or so for the above cmake command to finish that configured the cmake build. I have complained in the past about 0.1 second latencies for wine-1.3.9, but the current wine-1.3.27 seems to be ten (!) times worse in this regard. Despite this current latency drawback, the cmake/MinGW/MSYS/wine platform is quite useful for testing for Windows build issues if you don't want to spend a lot of time/effort/money on installing Microsoft Windows on your computer. For example, the above could be a MinGW/MSYS build issue that also occurs for Microsoft Windows for cmake-2.8.5 and the 20110802 version of MinGW/MSYS (the version that is automatically downloaded now by the automated MinGW/MSYS installer you can download using wget "http://sourceforge.net/projects/mingw/files/Automated MinGW Installer/mingw-get-inst/mingw-get-inst-20110802/mingw-get-inst-20110802.exe" Has anybody tried that version of MinGW/MSYS on Microsoft Windows to build cmake-2.8.5? It is possible the same build-time error will show up under those conditions. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ _______________________________________________ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers