On 2013-10-19 18:57-0000 Arjen Markus wrote: > Hi, > > I had a strange problem while trying to build the Java bindings and examples. > I was forced to change from the 32-bits version of the MSVC/C++ compiler to > the 64-bits version, because my Java installation is a 64-bits one. > > However, this caused CMake to conclude that the Java jni.h header was > missing, whereas before it was simply found. After setting CMAKE_INCLUDE_PATH > to point to the right directory it still was impossible to build Plplot, as > the linker CMake had picked up was not the one from MSVC/C++, but a stray > ld.exe from a gfortran installation that was included in the path. > > I think this is a problem with CMake, but can anyone confirm this? > > How does CMake figure out what versions (32-bits/64-bits) to pick up? Is that > based solely on "c:\Program Files" versus "c:\Program Files (x86)"?
Hi Arjen: I don't think CMake has any internal capabilities to distinguish between 32-bit and 64-bit finds. Instead, it just follows the general CMake rules for finding system files. So if you want 64-bit files put those higher on the overall search path than the corresponding 32-bit files, or vice versa. This is the best general advice I can give for the case when CMake finds something unexpected that you don't want. First look at the relevant find module. Normally, those contain a wide variety of basic CMake commands like find_file that are used to find needed system files. (For the case of FindJava.cmake, the only find command I can find in there is find_program.) Then generate complete documentation of cmake using cmake --help-full That will produce a very large file which is substantially updated for each new version of cmake. That file will detail exactly what goes on when a basic find command is used to find anything. For example, at a certain place in the search hierarchy the find_program command checks the PATH environment variable. There are many other rather general possibilities for influencing what is found by cmake. But in general you usually get good results for _all_ find modules if you set the PATH, CMAKE_INCLUDE_PATH, CMAKE_LIBRARY_PATH, and sometimes PKG_CONFIG_PATH environment variables. At least that is my experience with the PLplot build system where I typically have libraries on which PLplot depends scattered all over in extremely non-standard locations. But if those environment variables are insufficient, first check with the relevant find module for specifics (FindJava.cmake in this case), and second check the cmake documentation for the elementary find commands used in that module to try to figure out how to fix the CMake find problem you have encountered. 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 __________________________ ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk _______________________________________________ Plplot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/plplot-devel
