On 2010-03-26 12:12+0100 Arjen Markus wrote: > Hi Alan, > > On 2010-03-24 18:12, Alan W. Irwin wrote: > >> Obviously, I must be missing something since both of you guys see changed >> behaviour for MinGW due to this reorganization for CMake-2.6.x. Arjen >> defined the problem as >> cmake/modules/language_support/cmake-2.6/Platform/Windows-GNU-Fortran.cmake >> was being ignored. If that is really true, it should only take a few >> minutes of debugging >> cmake/modules/language_support/cmake-2.6/CMakeFortranInformation.cmake by >> inserting message statements in the svn trunk version of that file to see >> why >> cmake/modules/language_support/cmake-2.6/Platform/Windows-GNU-Fortran.cmake >> is being ignored. >> >> Good luck with that debugging, and please let me know how it goes because >> you certainly have my curiosity aroused about why the above simple >> changes do not work on MinGW. >> > > I have put some print statements in the file > CMakeFortranInformation.cmake and that was most revealing: > > In the IF-block IF(CMAKE_Fortran_COMPILER_ID) the files that are > being checked are: > > F:/plplot-svn/build-mingw-test-cmake/language_tests/Fortran/CMakeFiles/CMakeTmp/cmake/modules/language-support/cmake-2.6/Platform/Windows-GNU-Fortran.cmake > > and: > f:/cmake/share/cmake-2.6/Modules/Platform/Windows-GNU-Fortran.cmake > > The first is formed from the variable CMAKE_SOURCE_DIR, which has > acquired a very unexpected value (at least to me): > F:/plplot-svn/build-mingw-test-cmake/language_tests/Fortran/CMakeFiles/CMakeTmp/ > the last part in this name does not exist. > > The second file that is checked, does not exist either. > > There is a file Windows-g77.cmake in the CMake installation and that is > used in the end (the Fortran compiler identification is g77, despite > the gfortran.exe executable that is being run, but that may be a red > herring - my version of gfortran on this machine does not work properly) > > I hope this sheds more light on the situation.
It does, indeed. Thanks for this additional information. With regard to the second file, I wouldn't be too concerned about the nonexistence of f:/cmake/share/cmake-2.6/Modules/Platform/Windows-GNU-Fortran.cmake. That logic remains unchanged from previously (see the diff I posted previously in this thread) so I think that logic is just doing its job. With regard to the first file, language support infrastructure in CMake often breaks what you can count on for other parts of CMake. In this case, it appears to redefine CMAKE_SOURCE_DIR in an unanticipated way on MinGW (but not on Linux). To work around this issue in revision 10881 I have replaced all occurrences of CMAKE_SOURCE_DIR with CMAKE_HOME_DIRECTORY. This alternative works fine on Linux, and I am hoping that MinGW CMake Fortran support will not modify this variable. Will you and Hazen please test this revision? If it works, fine, if not, there are other alternatives for finding the top-level source directory for PLplot. 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); PLplot scientific plotting software package (plplot.org); 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 __________________________ ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
