My "build_projects" CMake project now contains ExternalProject_Add build configurations for 5 different software projects which build cleanly on Linux using the default "Unix Makefiles" generator on that platform and which build cleanly on the MinGW/MSYS/Wine platform using the "MSYS Makefiles" generator.
I have now tried running the build_projects cmake configuration using the "MinGW Makefiles" generator, but those builds need many executables from MSYS (such as mkdir.exe, cat.exe, tr.exe, unzip.exe, etc.,) in order for them to work properly. So most of MSYS needs to be on the PATH. For this case "MinGW Makefiles" complains that sh.exe is on the PATH so I worked around that issue by making a special copy of msys/1.0/bin called msys/1.0/bin_without_sh that has sh.exe removed and putting msys/1.0/bin_without_sh on the PATH rarther than msys/1.0/bin. I also take care to always use mingw32-make.exe (the MinGW version of make) rather than make.exe (the MSYS version of make) for this case. This trick to get "MinGW Makefiles" to work with most of MSYS on the PATH has worked perfectly in the past for PLplot builds so I expected it to work also for the present case (where the 5 projects being built so far with build_projects do not include PLplot yet and are each smaller than PLplot.) That expectation was correct for 4 of the 5 projects, but the fifth one (a libharu build) has an error concerning the "mkdir.exe -p" command that fails for some unknown reason with an error message of "Path not found."). Some questions: 1. Is that demand from the "MinGW Makefiles" generator that sh.exe not be on the PATH necessary any more? The reason I ask this is the strings command does indicate that mingw32-make.exe contains a reference to sh.exe, but all the Makefiles generated by "MinGW Makefiles" specify SHELL = cmd.exe so it seems unlikely that mingw32-make.exe would get confused by those Makefiles if sh.exe were on the PATH. 2. In light of the fact that SHELL is set to cmd.exe in the Makefiles, is it possible the above trick to get "MinGW Makefiles" to work may simply be a workaround for a "MinGW Makefiles" generator issue and is otherwise not necessary from the mingw32-make.exe perspective? The four good builds I have now with this trick and the good build of PLplot I had in the past with this trick would support that idea. Of course, there is one build (libharu) that currently has an issue for "MinGW Makefiles" that does not occur for "MSYS Makefiles" (or "Unix Makefiles" on Linux). Of course, that issue could be due to something else other than MSYS (without sh.exe) being on the PATH so I am continuing to investigate. But to eliminate or confirm that MSYS (without sh.exe) is the issue for the bad "MinGW Makefiles" libharu build, your comments on the above two questions would be most appreciated. 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 __________________________ -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
