On 2006-08-31 12:39+1000 Andrew Roach wrote:
> At 10:32 AM 30/08/2006 -0700, Alan wrote:
>> That introduces the question of what CMake considers to be the standard
>> install locations on Windows systems. Andrew, have you tried CMake yet t=
>> see whether it has a problem finding the system components you feel are
>> installed in a standard location?
> I have tried CMake, but really I am not sure what constitutes a "standard
> location". For MingW, the only real standard is the =85\mingw\lib directo=
> which comes with all of the stock libraries distributed with package.
> Personally, I prefer to keep an additional "lib" and "include" directory =
> =85\mingw\contrib, with any additional libraries that aren't in MingW's
> standard pack. Autotools always finds them because they are set in
> COMPILER_PATH and INCLUDE_PATH. CMake doesn't, so I have to do it manuall=
When you say "manually" do you mean setting CMAKE_INCLUDE_PATH and
CMAKE_LIBRARY_PATH appropriately? I have headers and libraries installed i=
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 alway=
easy to prepare for CMake use.
> One curious thing that I have noticed is that for the libraries, CMake mo=
> often than not picks up the DLLs in windows/system, which is unfortunate
> because while the *are* libraries, they aren't "stubs" (which end in
> ".dll.a" not ".dll"), and MingW can't link to them directly. So I have to
> go back and point it to where the stubs are. I am guessing that is CMake'=
> doing and not the scripts ?
I want to emphasize that all the many different find modules usually boil
down to calls to the CMake FIND_FILE, FIND_PATH, FIND_LIBRARY, and
FIND_PROGRAM commands. Those commands and the search strategies for them
(including what environment variables are used to guide the search) are
documented at http://www.cmake.org/HTML/Documentation.html.
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 wha=
is returned in FREETYPE_LIBRARY is the absolute path+name of the .so form o=
the library, that is /usr/lib/libfreetype.so. CMake is smart enough to tur=
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
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.) If the *.dll and *.dll.a forms of the library are i=
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. 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 fo=
that platform from my Linux experience?
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); PLplot scientific plotting software
package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the
Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project