On 9/26/06, Brandon J. Van Every <[EMAIL PROTECTED]> wrote:
> A CMake compiled from MSYS (as opposed to cygwin) seems to be > a native Windows App with limited knowledge of stuff like /usr/local. Data point: I use MinGW / MSYS as my primary build environment. I use a CMake that was compiled with Visual Studio .NET 2003, i.e. standard issue CMake 2.4.
I tried versions I build with MSYS/MinGW and VC6 and just now the official build from the cmake website, but I haven't seen any difference in their behaviour (as should be expected).
I do not invoke CMake from a MSYS command line. I use a shortcut and run it from outside MSYS. It picks up MSYS just fine. I don't have the path problems you mention.
Maybe I should give an example of what works (and what doesn't). Running cmake from MSYS like so [EMAIL PROTECTED] /d/adonthell/adonthell/build $ start cmake -DADONTHELL_DATADIR="." -G "MSYS Makefiles" -i .. gives: [snip] Variable Name: SDLMIXER_INCLUDE_DIR Description: Path to a file. Current Value: SDLMIXER_INCLUDE_DIR-NOTFOUND Variable Name: SDLMIXER_LIBRARY Description: Path to a library. Current Value: D:/Programme/msys/local/bin/SDL_mixer.dll Variable Name: SDL_INCLUDE_DIR Description: Path to a file. Current Value: SDL_INCLUDE_DIR-NOTFOUND Variable Name: SDL_LIBRARY Description: Where the SDL Library can be found Current Value: mingw32;D:/Programme/msys/local/bin/SDL.dll [snip] The pattern I see here is that cmake can find the DLLs that ended up in the bin directory, because /usr/local/bin is in my $PATH: $ echo $PATH .:/usr/local/bin:/mingw/bin:/bin:/d/oracle/ora81/bin: \ /c/Programme/Oracle/jre/1.1.7/bin:/c/WINNT/system32: \ /c/WINNT:/c/WINNT/System32/Wbem:/d/TIBCO/TIBRV6.9/BIN: \ /c/Programme/Gemeinsame Dateien/GTK/2.0/bin: \ /c/Programme/cvsnt:/d/Programme/apache-ant-1.6.5/bin:/mingw/bin But cmake cannot find the headers, (or libraries in /usr/local/lib), because it does know nothing about the UNIX-like structure of MSYS. So the problem is not that there is something wrong when running cmake from a MSYS shell instead of a Windows command prompt. It behaves exactly the same as far as I can tell. The "problem" is that it could do better in a MSYS development environment than it currently does, by taking the unixish nature of MSYS into account.
In the meantime, you might consider using CMake "in the standard way" to get around your problems.
Well, I can specify all those libs and headers cmake couldn't figure out manually, but I had hoped for it to work without user intervention, just like on a proper UNIX. I know that only developers will probably ever want to compile my application on Windows themselves, so it shouldn't matter if the process is a bit rough. But I thought that this would be an opportunity for improving an otherwise great tool, so I wanted to let you know. (Being selfish here, I know ;-)) Cheers, Kai _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
