From: Andrew R. <aro...@ya...> - 2006-08-31 11:13:05
|
At 10:12 PM 30/08/2006 -0700, you wrote: >When you say "manually" do you mean setting CMAKE_INCLUDE_PATH and >CMAKE_LIBRARY_PATH appropriately? No, I didn't have them set up properly before. >I have headers and libraries installed in >non-standard locations on my Debian stable and Ubuntu Dapper boxes so I >always must use those environment variables. However, I set those >environment variables with a script. Once that script is set up it is always >easy to prepare for CMake use. I actually meant setting the absolute library locations from within the CMake GUI for each of the libraries to point right to the directories they were in, not setting CMAKE_INCLUDE_PATH or CMAKE_LIBRARY_PATH to find them. After setting them correctly it is working now. >Let's take FindFreetype.cmake as a concrete example that we can look at in >a bit of detail to clear up what is bothering you. > >(1) There is a search for freetype/config/ftheader.h using FIND_PATH. That >search is guided by the CMAKE_INCLUDE_PATH environment variable. > >(2) There is a search for the "freetype" library using FIND_LIBRARY. That >search is guided by CMAKE_LIBRARY_PATH. If I recall correctly, on Linux what >is returned in FREETYPE_LIBRARY is the absolute path+name of the .so form of >the library, that is /usr/lib/libfreetype.so. CMake is smart enough to turn >that absolute path+name into the -lfreetype link option. Normally, it also >supplies the appropriate -L option as well, but not in this case because it >knows /usr/lib is a standard library location on Linux and therefore not >needed as a -L option. > >Could you post exactly what happens in the windows case for the freetype >library search? None of the logs showed what happened in the search - it all happened in the status bar of the Gui, but it works now I have set it up properly. >I assume if the *.dll and *.dll.a forms of that library were in the same >directory, then you point CMAKE_LIBRARY_PATH to that directory and CMake >does the right think and returns the absolute path+name of the *.dll.a form >in the FREETYPE_LIBRARY variable, and CMake does the right thing with that >when linking. (Please confirm that if you have a case of *.dll and *.dll.a >in the same directory.) Generally speaking, the .dll and the .dll.a's wont be in the same directory. Where Cmake was falling over before was, for example, in picking up different versions of libz, of which I have about six different versions all over my computer (almost every package that uses it, uses it's own version which isn't interchangeable). Some were in the default search path Cmake was using (in the absence of CMAKE_LIBRARY_PATH), and once Cmake found a matching .dll file it stopped looking for any stubs or anything else. >If the *.dll and *.dll.a forms of the library are in >different directories, then I assume you just point CMAKE_LIBRARY_PATH to >the *.dll.a directory rather than the *.dll directory, and everything >proceeds without problems. Yes, that is how I solved it. >Thus, I don't understand why you seem to have >some reservations about using CMAKE_INCLUDE_PATH and CMAKE_LIBRARY_PATH to >guide searches on windows, but that may just be due to my inexperience with >windows. Don't those environment variables work the way I have inferred for >that platform from my Linux experience? They do, I had not set it up correctly, and assumed CMake would have automatically searched the default library paths of GCC if it could not find what it was looking for (as autotools did). -Andrew |