From: Hazen B. <hba...@ma...> - 2010-03-21 19:00:31
|
I'm having trouble building the examples with f77 on mingw32. I'm getting this error message: [ 56%] Built target f77_examples mingw32-make[2]: *** No rule to make target `dll/libplplotf77d.dll.a', needed by `examples/f77/x01f.exe'. Stop. mingw32-make[1]: *** [examples/f77/CMakeFiles/x01f.dir/all] Error 2 mingw32-make: *** [all] Error 2 Looking in the dll directory I see: libplplotf77cd.dll.a and libplplotf77optsd.a There is also: libplplotf77cd.dll libplplotf77d.dll So maybe libplplotf77d.dll.a was supposed to be generated? I started with the following cmake command: "c:\program files\CMake 2.6\bin\cmake.exe" ..\plplot -G "MinGW Makefiles" -DSWIG_EXECUTABLE=C:\users\Hazen\Downloads\swigwin-1.3.40\swig.exe -DPKG_CONFIG_EXECUTABLE=C:\gtk\bin\pkg-config.exe -DBUILD_TEST=ON -DCMAKE_INSTALL_PREFIX=C:\plplot path=c:\Python26;c:\MinGW\bin;C:\Qt\2009.04\qt\bin;C:\users\Hazen\plplot_build\dll;c:\gtk\bin -Hazen |
From: Arjen M. <arj...@de...> - 2010-03-22 08:13:39
|
Hi Hazen, I have seen this too - I have not been able to track it down yet, getting very confusing results with the various combinations of OS's, compiler versions and versions of PLplot and CMake. On Windows you need both a DLL and an import library and for some reason that last one is not being built (in other cases it has been the Fortran 95 equivalent). I will have to look into it again, but the combinatorics was overwhelming and my time has been limited last one or two weeks. Regards, Arjen On 2010-03-21 20:00, Hazen Babcock wrote: > I'm having trouble building the examples with f77 on mingw32. I'm > getting this error message: > > [ 56%] Built target f77_examples > mingw32-make[2]: *** No rule to make target `dll/libplplotf77d.dll.a', > needed by `examples/f77/x01f.exe'. Stop. > mingw32-make[1]: *** [examples/f77/CMakeFiles/x01f.dir/all] Error 2 > mingw32-make: *** [all] Error 2 > > Looking in the dll directory I see: > libplplotf77cd.dll.a > and > libplplotf77optsd.a > > There is also: > libplplotf77cd.dll > libplplotf77d.dll > > So maybe libplplotf77d.dll.a was supposed to be generated? > > I started with the following cmake command: > "c:\program files\CMake 2.6\bin\cmake.exe" ..\plplot -G "MinGW > Makefiles" > -DSWIG_EXECUTABLE=C:\users\Hazen\Downloads\swigwin-1.3.40\swig.exe > -DPKG_CONFIG_EXECUTABLE=C:\gtk\bin\pkg-config.exe -DBUILD_TEST=ON > -DCMAKE_INSTALL_PREFIX=C:\plplot > path=c:\Python26;c:\MinGW\bin;C:\Qt\2009.04\qt\bin;C:\users\Hazen\plplot_build\dll;c:\gtk\bin > > -Hazen > > ------------------------------------------------------------------------------ > 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 > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > |
From: Werner S. <sm...@ia...> - 2010-03-22 15:46:29
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Arjen, > > On Windows you need both a DLL and an import library and for some > reason that last one is not being built (in other cases it has > been the Fortran 95 equivalent). Not for MinGW. MinGW compiler is able to link against dll without import library (if dll was compiled with MinGW). Regards, Werner > > I will have to look into it again, but the combinatorics was > overwhelming and my time has been limited last one or two weeks. > > Regards, > > Arjen > > On 2010-03-21 20:00, Hazen Babcock wrote: >> I'm having trouble building the examples with f77 on mingw32. I'm >> getting this error message: >> >> [ 56%] Built target f77_examples >> mingw32-make[2]: *** No rule to make target `dll/libplplotf77d.dll.a', >> needed by `examples/f77/x01f.exe'. Stop. >> mingw32-make[1]: *** [examples/f77/CMakeFiles/x01f.dir/all] Error 2 >> mingw32-make: *** [all] Error 2 >> >> Looking in the dll directory I see: >> libplplotf77cd.dll.a >> and >> libplplotf77optsd.a >> >> There is also: >> libplplotf77cd.dll >> libplplotf77d.dll >> >> So maybe libplplotf77d.dll.a was supposed to be generated? >> >> I started with the following cmake command: >> "c:\program files\CMake 2.6\bin\cmake.exe" ..\plplot -G "MinGW >> Makefiles" >> -DSWIG_EXECUTABLE=C:\users\Hazen\Downloads\swigwin-1.3.40\swig.exe >> -DPKG_CONFIG_EXECUTABLE=C:\gtk\bin\pkg-config.exe -DBUILD_TEST=ON >> -DCMAKE_INSTALL_PREFIX=C:\plplot >> path=c:\Python26;c:\MinGW\bin;C:\Qt\2009.04\qt\bin;C:\users\Hazen\plplot_build\dll;c:\gtk\bin >> >> -Hazen >> >> ------------------------------------------------------------------------------ >> 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 >> Plp...@li... >> https://lists.sourceforge.net/lists/listinfo/plplot-devel >> > > ------------------------------------------------------------------------------ > 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 > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel - -- Dr. Werner Smekal Institut fuer Angewandte Physik Technische Universitaet Wien Wiedner Hauptstr 8-10/134 A-1040 Wien Austria DVR-Nr: 0005886 email: sm...@ia... (GPG: EDCAF4A79) web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJLp5DBAAoJEG1QQcXtyvSnc28H/RWBxvOTEUI+LcMX+vGss24s tcLd6d7winLZiqY9tg1P2jUbDMmV0GN85NkTKRwAu0kZepUsN0YHq/eDkle043+3 CSAniMG1Xs8pS84IiQpQkFiLXhHFkm9/W/NDU1eQR7U0fLVVeULDN20q4JW0+Jwd 3TJk5uEW8AzKCUKGb9VW6HPzmvT7LlzeIE55Fc5DEjWGHo/kI3yvpWulgKoz3cpC UXDPtYatAn0s7kDFhbgQjolrDfkfuKoFrdSk5cZNgHSI5sc2WhFHVBemsxJ1FR// DH39F19LHq0Pt3Hdz4QfkBCxt8uWe41H27LuIr+PVCv7gFTDuvtjAu4xYIAEVuA= =M+B1 -----END PGP SIGNATURE----- |
From: Arjen M. <arj...@de...> - 2010-03-22 15:49:50
|
Hi Werner, On 2010-03-22 16:46, Werner Smekal wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Arjen, >> On Windows you need both a DLL and an import library and for some >> reason that last one is not being built (in other cases it has >> been the Fortran 95 equivalent). > > Not for MinGW. MinGW compiler is able to link against dll without import > library (if dll was compiled with MinGW). > Now _that_ may explain why it works for CMake 2.6 and not for CMake 2.8! CMake 2.8rc3 seems to create a different list of dependencies than CMake 2.6. I could not figure out what was different in PLplot that caused the difference. Thanks, this ought to be helpful indeed. Regards, Arjen |
From: Arjen M. <arj...@de...> - 2010-03-23 08:21:44
|
Hi, some further testing revealed that the file "Windows-GNU-Fortran.cmake" is not used at all by CMake. I inserted a bogus command and expected CMake to complain but it did not. Regards, Arjen On 2010-03-23 08:46, Arjen Markus wrote: > Hi Werner, Alan, > > I tried the following set-up: > > - The latest source code from PLplot (yesterday afternoon) > - CMake 2.6.4 with the MinGW Makefiles generator > - gcc and gfortran, version 4.5.0 > > CMake itself runs fine, but the build fails on the import > library dll/libplplotf77.dll.a that is listed as one of the > dependencies for the FORTRAN 77 examples. > > I checked that our Windows-GNU-Fortran.cmake file contains > the option -Wl,--out-implib for building shared libraries, > but the _link_ command that is generated by CMake does not > have that option. Therefore no such file is being built. > > Right now, I have no clue where CMake is getting its > gfortran compiler and linker options from. I do see such > an option in the generated files for libplplotf77cd.dll, > but that uses the gcc compiler, not gfortran. > > Any thoughts? This is hindering my testing activities. > |
From: Alan W. I. <ir...@be...> - 2010-03-23 16:29:38
|
On 2010-03-23 09:21+0100 Arjen Markus wrote: > Hi, > > some further testing revealed that the file "Windows-GNU-Fortran.cmake" > is not used at all by CMake. I inserted a bogus command and expected > CMake to complain but it did not. Arjen, My questions below are strictly for CMake-2.6.4 since Fortran is handled differently (both for PLplot and CMake) for CMake 2.8.1. Just to reduce the combinatorial permutations Werner has to deal with still further (in case he wants to look for the same issue), please state whether you are testing MinGW or MinGW/MSYS and what Generator you are using. Has Fortran every worked for you before on MinGW? If so, then the next thing you should do is try to replicate that old working test using an older revision of PLplot (5.9.5?) The point of this test is to eliminate the possibility that some other system change you did (compiler change or whatever) is now causing the problems. Once you have "one foot on dry land" i.e., a PLplot revision that works for your present system, then the rest is tedious but straightforward. You simply have to try various PLplot revisions until you find the PLplot build-system change which introduced the issue on your platform. Once that revision is identified, the rest should be easy. Meanwhile, I will try an experiment here to see whether access to PLplot versions of Fortran Platform files works on Linux with CMake-2.6.4. 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2010-03-23 18:45:24
|
On 2010-03-23 09:29-0700 Alan W. Irwin wrote: > On 2010-03-23 09:21+0100 Arjen Markus wrote: > >> Hi, >> >> some further testing revealed that the file "Windows-GNU-Fortran.cmake" >> is not used at all by CMake. I inserted a bogus command and expected >> CMake to complain but it did not. > Meanwhile, I will try an experiment here to see whether access to PLplot > versions of Fortran Platform files works on Linux with CMake-2.6.4. I cannot confirm the above issue on Linux. Here is what I did to test that: I copied the CMake-2.6.4 version of Linux-GNU-Fortran.cmake to the appropriate location in our build system and inserted a message. Here is the diff between the two. software@raven> diff -au ~/cmake/install-2.6.4/share/cmake-2.6/Modules/Platform/Linux-GNU-Fortran.cmake cmake/modules/language_support/cmake-2.6/Platform/ --- /home/software/cmake/install-2.6.4/share/cmake-2.6/Modules/Platform/Linux-GNU-Fortran.cmake 2009-04-28 13:22:59.000000000 -0700 +++ cmake/modules/language_support/cmake-2.6/Platform/Linux-GNU-Fortran.cmake 2010-03-23 11:21:01.000000000 -0700 @@ -5,6 +5,7 @@ SET (CMAKE_Fortran_FLAGS_MINSIZEREL_INIT "-Os") SET (CMAKE_Fortran_FLAGS_RELEASE_INIT "-O3") SET (CMAKE_Fortran_FLAGS_RELWITHDEBINFO_INIT "-O2 -g") +message(STATUS "DEBUG: using the PLplot CMake-2.6 version of Fortran support") IF(NOT APPLE) SET (CMAKE_INCLUDE_SYSTEM_FLAG_Fortran "-isystem ") If I then did a normal PLplot build with cmake-2.6.4 that message got printed (twice because of our soft-landing system for compilers) to the cmake.out file. So fundamentally our build system is fine, and there must be some platform-specific reason why you are not accessing the PLplot version of Windows-GNU-Fortran.cmake. Now that result has been established, the further debugging of this issue on Windows should be straightforward. I suggest you temporarily insert message statements in cmake/modules/language_support/cmake-2.6/CMakeFortranInformation.cmake first to make sure that file is being used on Windows, and second to test why the existence tests there for the PLplot version of Windows-GNU-Fortran.cmake are not being satisfied. 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 __________________________ |
From: Arjen M. <arj...@de...> - 2010-03-24 07:36:16
|
Hi Alan, that sounds like a good plan. I can confirm that at some point I did have a working set-up for PLplot, CMake 2.6.x and MinGW. To be clear: - I use the GNU compiler suite configured and built for MinGW. - I run everything in an ordinary DOS-box (where the path is expanded to access the compiler suite and win-bash) - I do _not_ use the MSYS environment at the moment Regards, Arjen On 2010-03-23 19:44, Alan W. Irwin wrote: > On 2010-03-23 09:29-0700 Alan W. Irwin wrote: > >> On 2010-03-23 09:21+0100 Arjen Markus wrote: >> >>> Hi, >>> >>> some further testing revealed that the file "Windows-GNU-Fortran.cmake" >>> is not used at all by CMake. I inserted a bogus command and expected >>> CMake to complain but it did not. > >> Meanwhile, I will try an experiment here to see whether access to PLplot >> versions of Fortran Platform files works on Linux with CMake-2.6.4. > > I cannot confirm the above issue on Linux. > > Here is what I did to test that: > > I copied the CMake-2.6.4 version of Linux-GNU-Fortran.cmake to the > appropriate > location in our build system and inserted a message. Here is the diff > between the two. > > software@raven> diff -au > ~/cmake/install-2.6.4/share/cmake-2.6/Modules/Platform/Linux-GNU-Fortran.cmake > cmake/modules/language_support/cmake-2.6/Platform/ > --- > /home/software/cmake/install-2.6.4/share/cmake-2.6/Modules/Platform/Linux-GNU-Fortran.cmake > 2009-04-28 13:22:59.000000000 -0700 > +++ > cmake/modules/language_support/cmake-2.6/Platform/Linux-GNU-Fortran.cmake > 2010-03-23 11:21:01.000000000 -0700 > @@ -5,6 +5,7 @@ > SET (CMAKE_Fortran_FLAGS_MINSIZEREL_INIT "-Os") > SET (CMAKE_Fortran_FLAGS_RELEASE_INIT "-O3") > SET (CMAKE_Fortran_FLAGS_RELWITHDEBINFO_INIT "-O2 -g") > +message(STATUS "DEBUG: using the PLplot CMake-2.6 version of Fortran > support") > > IF(NOT APPLE) > SET (CMAKE_INCLUDE_SYSTEM_FLAG_Fortran "-isystem ") > > If I then did a normal PLplot build with cmake-2.6.4 that message got > printed (twice because of our soft-landing system for compilers) to the > cmake.out file. So fundamentally our build system is fine, and there must > be some platform-specific reason why you are not accessing the PLplot > version of Windows-GNU-Fortran.cmake. > > Now that result has been established, the further debugging of this > issue on > Windows should be straightforward. I suggest you temporarily insert message > statements in > cmake/modules/language_support/cmake-2.6/CMakeFortranInformation.cmake > first > to make sure that file is being used on Windows, and second to test why the > existence tests there for the PLplot version of Windows-GNU-Fortran.cmake > are not being satisfied. |
From: Hazen B. <hba...@ma...> - 2010-03-24 15:36:44
|
Arjen Markus wrote: > Hi Alan, > > that sounds like a good plan. I can confirm that at some point I did > have a working set-up for PLplot, CMake 2.6.x and MinGW. > > To be clear: > - I use the GNU compiler suite configured and built for MinGW. > - I run everything in an ordinary DOS-box (where the path is expanded > to access the compiler suite and win-bash) > - I do _not_ use the MSYS environment at the moment > > > Regards, > > Arjen Same setup here. I just bisected it, and the problem was introduced in v10805. -Hazen |
From: Arjen M. <arj...@de...> - 2010-03-24 15:45:23
|
Well, that turns out to be easy enough! I will look into the differences later. Regards, Arjen On 2010-03-24 16:42, Arjen Markus wrote: > Hi Hazen, > > thanks for this information - I will see what the differences are that > are causing this (if I can find out how to get the right version with > my SVN client ;)). > |
From: Alan W. I. <ir...@be...> - 2010-03-24 17:12:21
|
On 2010-03-24 16:45+0100 Arjen Markus wrote: > Well, that turns out to be easy enough! I will look into the differences > later. To Hazen and Arjen: Actually, you don't have to use svn to see what the revision 10805 differences are. The plplot_cvs mailing archive has them as well. Here is the first part of that commit message (by me). <quote> Reorganize language support using the CMAKE_MODULES_PATH list to have different language support depending on whether the cmake version is 2.6.x or 2.8.x. </quote> One of my previous posts in this thread proved that reorganization (in fact current svn trunk) does its job perfectly on Linux, i.e., if you introduce an additional Fortran Platform file for CMake-2.6.4, it is honored on Linux. >From the CMake-2.6.x Fortran perspective, what that reorganization did was (1) define CMAKE_MODULE_PATH as follows: set(CMAKE_MODULE_PATH ${PROJECT_SOURCE_DIR}/cmake/modules ${PROJECT_SOURCE_DIR}/cmake/modules/language_support/cmake ${PROJECT_SOURCE_DIR}/cmake/modules/language_support/cmake-2.6 ) (2) move cmake/modules/Platform/Windows-GNU-Fortran.cmake unchanged to cmake/modules/language_support/cmake-2.6/Platform (3) move cmake/modules/CMakeFortranInformation.cmake to cmake/modules/language_support/cmake-2.6 with the following changes to accommodate that changed location: --- /home/software/plplot_svn/HEAD/plplot_bisect/cmake/modules/CMakeFortranInformation.cmake 2010-02-27 11:56:55.000000000 -0800 +++ ./CMakeFortranInformation.cmake 2010-02-18 10:40:40.000000000 -0800 @@ -9,19 +9,20 @@ SET(CMAKE_BASE_NAME g77) ENDIF(CMAKE_COMPILER_IS_GNUG77) IF(CMAKE_Fortran_COMPILER_ID) - IF(EXISTS ${CMAKE_MODULE_PATH}/Platform/${CMAKE_SYSTEM_NAME}-${CMAKE_Fortran_COMPILER_ID}-Fortran.cmake OR EXISTS ${CMAKE_ROOT}/Modules/Platform/${CMAKE_SYSTEM_NAME}-${CMAKE_Fortran_COMPILER_ID}-Fortran.cmake) + # FIXME: PLplot specific path here that will be different for other projects. + IF(EXISTS ${CMAKE_SOURCE_DIR}/cmake/modules/language-support/cmake-2.6/Platform/${CMAKE_SYSTEM_NAME}-${CMAKE_Fortran_COMPILER_ID}-Fortran.cmake OR EXISTS ${CMAKE_ROOT}/Modules/Platform/${CMAKE_SYSTEM_NAME}-${CMAKE_Fortran_COMPILER_ID}-Fortran.cmake) SET(CMAKE_BASE_NAME ${CMAKE_Fortran_COMPILER_ID}-Fortran) - ENDIF(EXISTS ${CMAKE_MODULE_PATH}/Platform/${CMAKE_SYSTEM_NAME}-${CMAKE_Fortran_COMPILER_ID}-Fortran.cmake OR EXISTS ${CMAKE_ROOT}/Modules/Platform/${CMAKE_SYSTEM_NAME}-${CMAKE_Fortran_COMPILER_ID}-Fortran.cmake) + ENDIF(EXISTS ${CMAKE_SOURCE_DIR}/cmake/modules/language-support/cmake-2.6/Platform/${CMAKE_SYSTEM_NAME}-${CMAKE_Fortran_COMPILER_ID}-Fortran.cmake OR EXISTS ${CMAKE_ROOT}/Modules/Platform/${CMAKE_SYSTEM_NAME}-${CMAKE_Fortran_COMPILER_ID}-Fortran.cmake) ENDIF(CMAKE_Fortran_COMPILER_ID) -IF(EXISTS ${CMAKE_MODULE_PATH}/Platform/${CMAKE_SYSTEM_NAME}-${CMAKE_BASE_NAME}.cmake) +IF(EXISTS ${CMAKE_SOURCE_DIR}/cmake/modules/language-support/cmake-2.6/Platform/${CMAKE_SYSTEM_NAME}-${CMAKE_BASE_NAME}.cmake) # Use this file if it exists. SET(CMAKE_SYSTEM_AND_Fortran_COMPILER_INFO_FILE - ${CMAKE_MODULE_PATH}/Platform/${CMAKE_SYSTEM_NAME}-${CMAKE_BASE_NAME}.cmake) -ELSE(EXISTS ${CMAKE_MODULE_PATH}/Platform/${CMAKE_SYSTEM_NAME}-${CMAKE_BASE_NAME}.cmake) + ${CMAKE_SOURCE_DIR}/cmake/modules/language-support/cmake-2.6/Platform/${CMAKE_SYSTEM_NAME}-${CMAKE_BASE_NAME}.cmake) +ELSE(EXISTS ${CMAKE_SOURCE_DIR}/cmake/modules/language-support/cmake-2.6/Platform/${CMAKE_SYSTEM_NAME}-${CMAKE_BASE_NAME}.cmake) # This one apparently doesn't have to actually exist, see OPTIONAL below. SET(CMAKE_SYSTEM_AND_Fortran_COMPILER_INFO_FILE ${CMAKE_ROOT}/Modules/Platform/${CMAKE_SYSTEM_NAME}-${CMAKE_BASE_NAME}.cmake) -ENDIF(EXISTS ${CMAKE_MODULE_PATH}/Platform/${CMAKE_SYSTEM_NAME}-${CMAKE_BASE_NAME}.cmake) +ENDIF(EXISTS ${CMAKE_SOURCE_DIR}/cmake/modules/language-support/cmake-2.6/Platform/${CMAKE_SYSTEM_NAME}-${CMAKE_BASE_NAME}.cmake) INCLUDE(Platform/${CMAKE_SYSTEM_NAME}-${CMAKE_BASE_NAME} OPTIONAL) # This should be included before the _INIT variables are Note those changes only involve replacing CMAKE_MODULE_PATH (since it is now a list) with the explicit location instead. So as far as I can tell from CMake logic inspection, the reorganization should work identically to before for the MinGW platform, and certainly this reorganization works fine on Linux. 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. 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 __________________________ |
From: Arjen M. <arj...@de...> - 2010-03-25 07:35:49
|
Hi Alan, I did not have a chance yesterday afternoon to look into the differences (and so thanks for clarifying them), but when I wanted to have a closer look this morning, the laptop I put the revisions 10804 and 10805 on for comparison, happily started to boot, after a few seconds reinitialised the boot process and got stuck in that loop. In other words: my laptop needs some serious pampering :(. Anyway, given your explanation, I have enough material (modulo a convenient computer) to start digging up the culprit. Regards, Arjen On 2010-03-24 18:12, Alan W. Irwin wrote: > On 2010-03-24 16:45+0100 Arjen Markus wrote: > >> Well, that turns out to be easy enough! I will look into the differences >> later. > > To Hazen and Arjen: > > Actually, you don't have to use svn to see what the revision 10805 > differences are. The plplot_cvs mailing archive has them as well. > > Here is the first part of that commit message (by me). > > <quote> > Reorganize language support using the CMAKE_MODULES_PATH list to have > different language support depending on whether the cmake version is > 2.6.x or 2.8.x. > </quote> > > One of my previous posts in this thread proved that reorganization (in fact > current svn trunk) does its job perfectly on Linux, i.e., if you introduce > an additional Fortran Platform file for CMake-2.6.4, it is honored on > Linux. > >> From the CMake-2.6.x Fortran perspective, what that reorganization did >> was > > (1) define CMAKE_MODULE_PATH as follows: > > set(CMAKE_MODULE_PATH > ${PROJECT_SOURCE_DIR}/cmake/modules > ${PROJECT_SOURCE_DIR}/cmake/modules/language_support/cmake > ${PROJECT_SOURCE_DIR}/cmake/modules/language_support/cmake-2.6 > ) > > (2) move cmake/modules/Platform/Windows-GNU-Fortran.cmake unchanged to > cmake/modules/language_support/cmake-2.6/Platform > > (3) move cmake/modules/CMakeFortranInformation.cmake to > cmake/modules/language_support/cmake-2.6 with the following changes > to accommodate that changed location: > > --- > /home/software/plplot_svn/HEAD/plplot_bisect/cmake/modules/CMakeFortranInformation.cmake > 2010-02-27 11:56:55.000000000 -0800 > +++ ./CMakeFortranInformation.cmake 2010-02-18 10:40:40.000000000 -0800 > @@ -9,19 +9,20 @@ > SET(CMAKE_BASE_NAME g77) > ENDIF(CMAKE_COMPILER_IS_GNUG77) > IF(CMAKE_Fortran_COMPILER_ID) > - IF(EXISTS > ${CMAKE_MODULE_PATH}/Platform/${CMAKE_SYSTEM_NAME}-${CMAKE_Fortran_COMPILER_ID}-Fortran.cmake > OR EXISTS > ${CMAKE_ROOT}/Modules/Platform/${CMAKE_SYSTEM_NAME}-${CMAKE_Fortran_COMPILER_ID}-Fortran.cmake) > > + # FIXME: PLplot specific path here that will be different for other > projects. > + IF(EXISTS > ${CMAKE_SOURCE_DIR}/cmake/modules/language-support/cmake-2.6/Platform/${CMAKE_SYSTEM_NAME}-${CMAKE_Fortran_COMPILER_ID}-Fortran.cmake > OR EXISTS > ${CMAKE_ROOT}/Modules/Platform/${CMAKE_SYSTEM_NAME}-${CMAKE_Fortran_COMPILER_ID}-Fortran.cmake) > > SET(CMAKE_BASE_NAME ${CMAKE_Fortran_COMPILER_ID}-Fortran) > - ENDIF(EXISTS > ${CMAKE_MODULE_PATH}/Platform/${CMAKE_SYSTEM_NAME}-${CMAKE_Fortran_COMPILER_ID}-Fortran.cmake > OR EXISTS > ${CMAKE_ROOT}/Modules/Platform/${CMAKE_SYSTEM_NAME}-${CMAKE_Fortran_COMPILER_ID}-Fortran.cmake) > > + ENDIF(EXISTS > ${CMAKE_SOURCE_DIR}/cmake/modules/language-support/cmake-2.6/Platform/${CMAKE_SYSTEM_NAME}-${CMAKE_Fortran_COMPILER_ID}-Fortran.cmake > OR EXISTS > ${CMAKE_ROOT}/Modules/Platform/${CMAKE_SYSTEM_NAME}-${CMAKE_Fortran_COMPILER_ID}-Fortran.cmake) > > ENDIF(CMAKE_Fortran_COMPILER_ID) > -IF(EXISTS > ${CMAKE_MODULE_PATH}/Platform/${CMAKE_SYSTEM_NAME}-${CMAKE_BASE_NAME}.cmake) > > +IF(EXISTS > ${CMAKE_SOURCE_DIR}/cmake/modules/language-support/cmake-2.6/Platform/${CMAKE_SYSTEM_NAME}-${CMAKE_BASE_NAME}.cmake) > > # Use this file if it exists. > SET(CMAKE_SYSTEM_AND_Fortran_COMPILER_INFO_FILE > - > ${CMAKE_MODULE_PATH}/Platform/${CMAKE_SYSTEM_NAME}-${CMAKE_BASE_NAME}.cmake) > > -ELSE(EXISTS > ${CMAKE_MODULE_PATH}/Platform/${CMAKE_SYSTEM_NAME}-${CMAKE_BASE_NAME}.cmake) > > + > ${CMAKE_SOURCE_DIR}/cmake/modules/language-support/cmake-2.6/Platform/${CMAKE_SYSTEM_NAME}-${CMAKE_BASE_NAME}.cmake) > > +ELSE(EXISTS > ${CMAKE_SOURCE_DIR}/cmake/modules/language-support/cmake-2.6/Platform/${CMAKE_SYSTEM_NAME}-${CMAKE_BASE_NAME}.cmake) > > # This one apparently doesn't have to actually exist, see OPTIONAL > below. > SET(CMAKE_SYSTEM_AND_Fortran_COMPILER_INFO_FILE > > ${CMAKE_ROOT}/Modules/Platform/${CMAKE_SYSTEM_NAME}-${CMAKE_BASE_NAME}.cmake) > > -ENDIF(EXISTS > ${CMAKE_MODULE_PATH}/Platform/${CMAKE_SYSTEM_NAME}-${CMAKE_BASE_NAME}.cmake) > > +ENDIF(EXISTS > ${CMAKE_SOURCE_DIR}/cmake/modules/language-support/cmake-2.6/Platform/${CMAKE_SYSTEM_NAME}-${CMAKE_BASE_NAME}.cmake) > > INCLUDE(Platform/${CMAKE_SYSTEM_NAME}-${CMAKE_BASE_NAME} OPTIONAL) > > # This should be included before the _INIT variables are > > Note those changes only involve replacing CMAKE_MODULE_PATH (since it is > now > a list) with the explicit location instead. So as far as I can tell from > CMake logic inspection, the reorganization should work identically to > before > for the MinGW platform, and certainly this reorganization works fine on > Linux. > > 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. > > 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 > __________________________ > |
From: Alan W. I. <ir...@be...> - 2010-03-26 00:13:23
|
On 2010-03-25 15:48-0400 Hazen Babcock wrote: > Btw, if you ever want to join in the fun of Windows debugging, you can run > native Windows on a linux box pretty easily using the open-source package > VirtualBox. > > http://www.virtualbox.org/ > > You will need a copy of windows, but since it is pretty hard to get a PC > without one these days, you might already have this. > Hi Hazen: I hope you don't mind me bringing this bit of your off-list discussion with me back to the list because this topic should be of interest to a lot of those who subscribe to this list. To answer your implied question, I buy white boxes without O/S's preinstalled, and I don't want to actually go out and buy Windows. Microsoft already has enough money! :-) Also, that corporation continues to work actively and persistently against the software freedom that I love so I am voting with my dollars. That said, I have no objections to the Windows platform itself which is popular with both users and developers so I am glad there are active PLplot developers like you, Arjen, and Werner with access to and expertise with that platform who are testing PLplot on that platform, and I would like to help with that effort as much as possible. It turns out there _may_ be a straightforward way for me to join your PLplot windows testing efforts using WINE (http://www.winehq.org/) which is a Windows platform emulator that can be used with complete freedom (unlike the Microsoft proprietary version). Others here might also like to try WINE since it runs on both Linux and Mac OS X. I assume it would be just as convenient as virtualbox to run, and _a lot_ more convenient than a dual-boot system. WINE has been in development for more than a decade, and for most of that development time had a bad reputation as being immature. However, WINE has steadily improved all that time, and since its fairly recent 1.0 release I have read a lot of stories about how well it now emulates Windows. So in the future I would like to get into the MinGW/WINE testing game for PLplot using a generalization of the approach taken in http://m.linuxjournal.com/node/1005753?quicktabs_1=1. It seems to me such testing would expose most build-system issues with MinGW on pure Windows. Also, MinGW/WINE is a valid platform in its own right so it would be good to get PLplot working for that platform (if it doesn't work out of the box right now). So build-testing (and if that is successful, run-testing) PLplot on MinGW/WINE is on my agenda, but due to time pressures right now it will be quite a while until I can try that. If anyone else here wants to give it a try, please let me know what results you obtain. Make sure you use a recent WINE version since results from immature WINE versions are unlikely to be of interest. 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 __________________________ |
From: Arjen M. <arj...@de...> - 2010-03-26 11:12:14
|
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. Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2010-03-26 17:00:15
|
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 __________________________ |
From: Hazen B. <hba...@ma...> - 2010-03-26 23:40:29
|
Alan W. Irwin wrote: > > 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. This does not work for me, but that is probably not that helpful. Could you tell me what variables you would like to see the value of? I can tell you that CMAKE_HOME_DIRECTORY is: (1) c:/users/hazen/plplot_build/language_tests/Fortran (2) c:/users/hazen/plplot From inserting a message statement in line 13 of CMakeFortranInformation.cmake, which I guess gets called twice? My directory structure is: c:/users/hazen/plplot_build - the build directory. c:/users/hazen/plplot - SVN head. -Hazen |
From: Alan W. I. <ir...@be...> - 2010-03-27 00:20:28
|
On 2010-03-26 19:40-0400 Hazen Babcock wrote: > Alan W. Irwin wrote: >> >> 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. > > This does not work for me, but that is probably not that helpful. Could you > tell me what variables you would like to see the value of? I can tell you > that CMAKE_HOME_DIRECTORY is: > > (1) c:/users/hazen/plplot_build/language_tests/Fortran > (2) c:/users/hazen/plplot > > From inserting a message statement in line 13 of > CMakeFortranInformation.cmake, which I guess gets called twice? > > My directory structure is: > > c:/users/hazen/plplot_build - the build directory. > c:/users/hazen/plplot - SVN head. Yes, that does get called twice, once for a special project headed at c:/users/hazen/plplot_build/language_tests/Fortran (to test whether the Fortran compiler works for a mini test project) and once for the PLplot project headed at c:/users/hazen/plplot. So the results you are getting above are exactly what I expected. Could you please insert a message command in cmake/modules/language_support/cmake-2.6/Platform/Windows-GNU-Fortran.cmake to see whether that file is actually being read? If you are still not accessing that file, then please try some more message commands in CMakeFortranInformation.cmake to find out why not. I assume you are still somehow not accessing that file, because if as a result of revision 10881 you _are_ accessing that file, then is is a real puzzle why there are any issues left. As far as I know the only CMake-2.6 Fortran logic change for PLplot since the revision where you and Arjen had MinGW Fortran success involves the location of our special Platform directory for CMake-2.6. Therefore, if that location is being specified correctly, Windows-GNU-Fortran.cmake (unchanged from the previous version that worked) should be accessed and there should be nothing more to do. 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 __________________________ |
From: Arjen M. <arj...@de...> - 2010-03-29 07:43:57
|
Hi Alan, I think I found the cause of these problems: it turns out that the subdirectory language_tests is referred to in the CMake files as language-tests - so a minus sign instead of an underscore! No idea why this is a problem under MinGW and not under Linux, but this is the reason the build system falls back on the CMake files. Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2010-03-29 17:03:13
|
On 2010-03-29 08:43+0100 Arjen Markus wrote: > Hi Alan, > > I think I found the cause of these problems: > > it turns out that the subdirectory language_tests is > referred to in the CMake files as language-tests - so > a minus sign instead of an underscore! > Good spotting! I have now fixed this typo with revision 10882. (I also searched for any other occurrences of "language-support" but they all seem to be gone now). I believe (from Brad's message on the CMake list) that all should be well now. Can you (and Hazen) please confirm that? I hope as a result of this fix you will both be able to report good complete (including the test_noninteractive and test_interactive targets) tests of MinGW for CMake-2.6.x. > No idea why this is a problem under MinGW and not under > Linux, but this is the reason the build system falls > back on the CMake files. I have now found the explanation for this. In the Linux case, a CMake system version of Platform/Linux-GNU-Fortran.cmake exists which makes it possible (via how CMAKE_BASE_NAME is set) for the logic to find the PLplot version of this file despite the "language-support" typo, but in the MinGW case, no such system version of Platform/Windows-GNU-Fortran.cmake exists so the logic only works if the typo is corrected. I encourage both you and Hazen to follow the straightforward logic in CMakeFortranInformation.cmake if you want to confirm my explanation for yourselves. Ultimately, INCLUDE(Platform/${CMAKE_SYSTEM_NAME}-${CMAKE_BASE_NAME} OPTIONAL) includes the PLplot version of the file (_if_ CMAKE_BASE_NAME is set correctly) because of the way CMAKE_MODULE_PATH has been set in the top-level CMakeLists.txt file for the CMake-2.6.x case. 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 __________________________ |
From: Arjen M. <arj...@de...> - 2010-03-30 08:02:59
|
Hi Alan, it was not easy ;) I first followed the path via a file browser and was puzzled that the file (and directories) I was looking for did in fact exist. Later (during a break in yesterday's workshop) I simply copied the reported path and let the _system_ instead of my eyes find the file - and that failed! Only then - after careful examination - was I able to detect the minus/underscore mismatch. Anyway, I should be able to check the repair today. Regards, Arjen On 2010-03-29 19:03, Alan W. Irwin wrote: > On 2010-03-29 08:43+0100 Arjen Markus wrote: > >> Hi Alan, >> >> I think I found the cause of these problems: >> >> it turns out that the subdirectory language_tests is >> referred to in the CMake files as language-tests - so >> a minus sign instead of an underscore! >> > > Good spotting! I have now fixed this typo with revision 10882. (I also > searched for any other occurrences of "language-support" but they all seem > to be gone now). > > I believe (from Brad's message on the CMake list) that all should be well > now. Can you (and Hazen) please confirm that? I hope as a result of this > fix you will both be able to report good complete (including the > test_noninteractive and test_interactive targets) tests of MinGW for > CMake-2.6.x. > >> No idea why this is a problem under MinGW and not under >> Linux, but this is the reason the build system falls >> back on the CMake files. > > I have now found the explanation for this. In the Linux case, a CMake > system version of Platform/Linux-GNU-Fortran.cmake exists which makes it > possible (via how CMAKE_BASE_NAME is set) for the logic to find the PLplot > version of this file despite the "language-support" typo, but in the MinGW > case, no such system version of Platform/Windows-GNU-Fortran.cmake > exists so > the logic only works if the typo is corrected. I encourage both you and > Hazen to follow the straightforward logic in CMakeFortranInformation.cmake > if you want to confirm my explanation for yourselves. Ultimately, > > INCLUDE(Platform/${CMAKE_SYSTEM_NAME}-${CMAKE_BASE_NAME} OPTIONAL) > > includes the PLplot version of the file (_if_ CMAKE_BASE_NAME is set > correctly) because of the way CMAKE_MODULE_PATH has been set > in the top-level CMakeLists.txt file for the CMake-2.6.x case. > > 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 > __________________________ > |
From: Alan W. I. <ir...@be...> - 2010-03-29 17:43:12
|
On 2010-03-25 17:13-0700 Alan W. Irwin wrote: > So build-testing (and if that is successful, run-testing) PLplot on > MinGW/WINE is on my agenda, but due to time pressures right now it will be > quite a while until I can try that. If anyone else here wants to give it a > try, please let me know what results you obtain. Make sure you use a recent > WINE version since results from immature WINE versions are unlikely to be of > interest. I looked into this possibility a bit further. However, it turns out that all the Wine documentation assumes familiarity with Windows which I don't have, and so configuring and using wine would be quite intimidating for me. Is there anybody here with experience both on Unix (either Mac OS X or Linux) and Windows that would be willing to pioneer building and testing PLplot on MinGW/wine? I hope somebody does step forward because that platform is an important platform in its own right and also because it provides a free avenue for our Linux and Mac OS X developers to help out with Windows platform testing. If someone is willing to pioneer the MinGW/Wine platform and give a cookbook of what to do, I would be happy to help out with continued testing on that platform. 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 __________________________ |
From: Alan W. I. <ir...@be...> - 2010-04-02 08:45:19
|
On 2010-03-29 10:43-0700 Alan W. Irwin wrote: > On 2010-03-25 17:13-0700 Alan W. Irwin wrote: > >> So build-testing (and if that is successful, run-testing) PLplot on >> MinGW/WINE is on my agenda, but due to time pressures right now it will be >> quite a while until I can try that. If anyone else here wants to give it a >> try, please let me know what results you obtain. Make sure you use a recent >> WINE version since results from immature WINE versions are unlikely to be of >> interest. > > I looked into this possibility a bit further. However, it turns out that > all the Wine documentation assumes familiarity with Windows which I don't > have, and so configuring and using wine would be quite intimidating for me. The current status is that Clinton Stimpson on the cmake list has helped me to get started, and I now have a working build and test (test_noninteractive target) of PLplot for MinGW/MSYS under Wine! I have just posted a long message to the cmake list with all the details (see http://www.cmake.org/pipermail/cmake/2010-April/036246.html). So far the test_noninteractive target results are looking good for the MinGW/MSYS/Wine platform. To get into the MSYS bash environment under Linux you simply run, e.g., wineconsole /home/wine/mingw/MSYS/bin/bash.exe with default PATH set approprately in the Wine registry to find the downloaded and unpacked Windows versions of MinGW, MSYS, and CMake. Then in that MSYS bash environment, you execute, e.g. bash.exe-3.1$ cmake -G "MSYS Makefiles" -DDEFAULT_NO_BINDINGS=ON \ -DDEFAULT_NO_DEVICES=ON -DPLD_ps=ON -DBUILD_TEST=ON \ /z/home/software/plplot_svn/HEAD/plplot_cmake_qt >& cmake.out bash.exe-3.1$ PATH=$PATH:/z/home/wine/cmake/build_dir/dll bash.exe-3.1$ make -j4 test_noninteractive >& make_test.out Note the PATH extension puts the dll subdirectory on the PATH. That PATH extension is required on MinGW/MSYS to gain access to the dll's in the build tree. Also, note the -j4 option to the make command which insures the two cpu's on my box are fully utilized for this target. So far I have confined myself just to the latest development version of MinGW C, but it should be straightforward to download and install the corresponding MinGW Ada, C++, and gfortran components (MinGW Java is not available for the latest development version of MinGW) and expand the PLplot build and test appropriately. I also hope to extend the accessible device drivers using downloaded Windows versions of the GTK+ and Qt library stacks. If that all works, the result should be a pretty high-powered MinGW/MSYS version of PLplot that I can thoroughly test under Wine. I have been frustrated for years by not being able to deal directly with MinGW/MSYS bug reports concerning the build system so I am quite pleased to have this MinGW/MSYS Wine platform accessible to me now. Werner, Hazen, and Arjen cannot be expected to do all the testing work for MinGW/MSYS since they have access to other Windows platforms (proprietary compilers and Cygwin) and Mac OS X platforms that need regular testing as well. Thus, I highly recommend this Wine platform to anyone with Wine access here (i.e., anybody that is running Mac OS X on x86 hardware or running Linux) who wants to help out with our MinGW/MSYS effort. 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 __________________________ |
From: Hazen B. <hba...@ma...> - 2010-03-29 20:38:05
|
Alan W. Irwin wrote: > On 2010-03-29 08:43+0100 Arjen Markus wrote: > >> Hi Alan, >> >> I think I found the cause of these problems: >> >> it turns out that the subdirectory language_tests is >> referred to in the CMake files as language-tests - so >> a minus sign instead of an underscore! >> > > Good spotting! I have now fixed this typo with revision 10882. (I also > searched for any other occurrences of "language-support" but they all seem > to be gone now). > > I believe (from Brad's message on the CMake list) that all should be well > now. Can you (and Hazen) please confirm that? I hope as a result of this > fix you will both be able to report good complete (including the > test_noninteractive and test_interactive targets) tests of MinGW for > CMake-2.6.x. This works for me! Thanks you guys for fixing this. -Hazen |
From: chm <dev...@gm...> - 2010-03-30 01:51:33
|
I've been reviewing some of the driver codes in preparation for developing an OpenGL based PLplot driver. In working through qt.cpp, I was unable to find where the handler is created, i.e., from line 39: extern MasterHandler handler; I haven't done much C++ coding so expert nuances are sure to be missed. Thanks in advance, Chris |
From: Arjen M. <arj...@de...> - 2010-03-30 11:05:03
|
Hi Alan, Hazen, it looks as if it works for my installation too (at least the CMake part - there is something wrong with the compiler, but that is a different matter). Regards, Arjen On 2010-03-29 22:37, Hazen Babcock wrote: >> I believe (from Brad's message on the CMake list) that all should be well >> now. Can you (and Hazen) please confirm that? I hope as a result of >> this >> fix you will both be able to report good complete (including the >> test_noninteractive and test_interactive targets) tests of MinGW for >> CMake-2.6.x. > > This works for me! Thanks you guys for fixing this. > > -Hazen > > |