From: Alan W. I. <ir...@be...> - 2010-02-18 22:19:58
|
Hi Arjen: I just learned today on the CMake list, that CMAKE_MODULE_PATH was actually interpreted as a list. Based on that information, I was able to completely reorganize our language (Ada, D, and Fortran) support files in a way that should allow us to support both CMake-2.6.x and CMake-2.8.x. The basic idea is CMAKE_MODULE_PATH is assigned different list values depending on whether the PLplot builder has CMake-2.6.x or CMake-2.8.x installed. Two of the list elements are common between CMake-2.6.x and CMake-2.8.x, but one is different. That reorganization (revision 10805) was a rather large commit because all the changes had to be done atomically in order for PLplot builds to keep working. That commit needs a lot more testing since I have so far only made sure it worked for the default Linux build with Linux Ada, D, and gfortran compilers with shared libraries. You should look at the commit message to see the directories that are involved. The two important groups of directories from your (Fortran support) perspective are cmake/modules/language_support/cmake-2.6 cmake/modules/language_support/cmake-2.6/Platform cmake/modules/language_support/cmake-2.8 cmake/modules/language_support/cmake-2.8/Platform The former group has all your 2.6-related Fortran stuff. Please remove everything from cmake-2.6/Platform that is already supported natively by CMake-2.6.x. My guess from your discussion with Brad is you will be able to remove everything from there other than the file to support the Compaq Visual Fortran compiler for CMake-2.6.x. Please confirm that with tests on all your Windows platforms. The latter group of directories has no files at the moment. If I am interpreting the long discussion between you and Brad properly, you have a file ready to put into cmake-2.8/Platform to support the Compaq Visual Fortran compiler for CMake-2.8.x, and, of course, that will need testing by you as well. N.B. when you delete files from cmake-2.6/Platform and add a file to cmake-2.8/Platform, you will have to do the obvious corresponding maintenance of cmake/modules/language_support.cmake and examples/CMakeLists.txt. Both those CMake-related files do some processing of all the language support files so there are explicit lists of file names that have to be maintained exactly consistent with what files are present in the cmake/modules/language_support tree. I look forward to your Fortran language support commits (the deletions and the one addition I mentioned above if I have interpreted your discussions with Brad correctly) and heavy testing of those commits on various Windows platforms _both_ for CMake-2.6.x and CMake-2.8.1-RC3. Obviously, this is a fair amount of work but I hope you can do it essentially immediately. I know you prefer to work slowly and methodically, but my motivation for asking for quick results from you is I would really like to see all our Fortran support issues straightened out with thorough testing by the time CMake-2.8.1 is released, and that is going to be quite soon according to what Bill Hoffman said on the CMake list today. Of course, if your testing does find an issue with CMake-2.8.1-RC3, then Bill will probably hold the release to get the issue straightened out, but he won't know to do that unless you do your tests immediately. Of course, if you miss the CMake-2.8.1 deadline, there is always CMake-2.8.2, but then that means we have to tell our users to avoid both CMake-2.8.0 and CMake-2.8.1 for Windows Fortran, and I am sure you would prefer not to do that. 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-02-19 07:56:11
|
Hi Alan, okay, I am going to test this, I hope I will be able to do it this weekend. That will have to be for at least CMake 2.6 and 2.8.1, focusing on bare Windows (MSVC+CVF), MinGW and Cygwin (both gcc+gfortran). It sounds rather promising! Regards, Arjen On 2010-02-18 23:19, Alan W. Irwin wrote: > Hi Arjen: > > I just learned today on the CMake list, that CMAKE_MODULE_PATH was actually > interpreted as a list. Based on that information, I was able to completely > reorganize our language (Ada, D, and Fortran) support files in a way > that should allow us to support both CMake-2.6.x and CMake-2.8.x. The > basic > idea is CMAKE_MODULE_PATH is assigned different list values depending on > whether the PLplot builder has CMake-2.6.x or CMake-2.8.x installed. Two > of the list elements are common between CMake-2.6.x and CMake-2.8.x, but > one is different. > > That reorganization (revision 10805) was a rather large commit because all > the changes had to be done atomically in order for PLplot builds to keep > working. That commit needs a lot more testing since I have so far only > made > sure it worked for the default Linux build with Linux Ada, D, and gfortran > compilers with shared libraries. > > You should look at the commit message to see the directories that are > involved. The two important groups of directories from your (Fortran > support) perspective are > > cmake/modules/language_support/cmake-2.6 > cmake/modules/language_support/cmake-2.6/Platform > > cmake/modules/language_support/cmake-2.8 > cmake/modules/language_support/cmake-2.8/Platform > > The former group has all your 2.6-related Fortran stuff. Please remove > everything from cmake-2.6/Platform that is already supported natively by > CMake-2.6.x. My guess from your discussion with Brad is you will be > able to > remove everything from there other than the file to support the Compaq > Visual Fortran compiler for CMake-2.6.x. Please confirm that with > tests on all your Windows platforms. > > The latter group of directories has no files at the moment. If I am > interpreting the long discussion between you and Brad properly, you have a > file ready to put into cmake-2.8/Platform to support the Compaq Visual > Fortran compiler for CMake-2.8.x, and, of course, that will need testing by > you as well. > > N.B. when you delete files from cmake-2.6/Platform and add a file to > cmake-2.8/Platform, you will have to do the obvious corresponding > maintenance of cmake/modules/language_support.cmake and > examples/CMakeLists.txt. Both those CMake-related files do some processing > of all the language support files so there are explicit lists of file names > that have to be maintained exactly consistent with what files are > present in > the cmake/modules/language_support tree. > > I look forward to your Fortran language support commits (the deletions and > the one addition I mentioned above if I have interpreted your discussions > with Brad correctly) and heavy testing of those commits on various Windows > platforms _both_ for CMake-2.6.x and CMake-2.8.1-RC3. Obviously, this is a > fair amount of work but I hope you can do it essentially immediately. > > I know you prefer to work slowly and methodically, but my motivation for > asking for quick results from you is I would really like to see all our > Fortran support issues straightened out with thorough testing by the time > CMake-2.8.1 is released, and that is going to be quite soon according to > what Bill Hoffman said on the CMake list today. Of course, if your testing > does find an issue with CMake-2.8.1-RC3, then Bill will probably hold the > release to get the issue straightened out, but he won't know to do that > unless you do your tests immediately. Of course, if you miss the > CMake-2.8.1 deadline, there is always CMake-2.8.2, but then that means we > have to tell our users to avoid both CMake-2.8.0 and CMake-2.8.1 for > Windows > Fortran, and I am sure you would prefer not to do that. > > 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-02-21 11:27:15
|
Hi Alan, here are the preliminary results for the new set-up: I have worked with the current repository _out of the box_ Using CMake 2.6: Windows: all is working fine (except for a few missing Fortran bindings - I will add those) MinGW and Cygwin: the library plplotf77d.dll.a is not created! This prohibits the building of the examples. The same happens for Fortran 95. I think they have to do with the exporting of the routines (the .def file). I will have to check this - a compiler/linker option? Using CMake 2.8.1rc3: Windows: Compaq compiler is recognised, but there is no proper compiler module file. MinGW: the FORTRAN 77 examples are built without a problem, but with the Fortran 95 examples the linker complains: symbols such as __gfortran_os_error are doubly defined. (Note: the compiler and linker on my system are still the same as a year ago when all definitely worked, so some other change is causing this.) Cygwin: have not tried yet - requires building CMake for Cygwin first. (I found some small errors in plgradient.c and plfill.c that caused gcc to complain - repaired those) Well, these are the preliminary tests. Now I have to check the causes. Regards, Arjen |
From: Arjen M. <arj...@de...> - 2010-02-21 13:00:01
|
On Sun, 21 Feb 2010 12:27:06 +0100 Arjen Markus <arj...@de...> wrote: > > Cygwin: have not tried yet - requires building CMake for > Cygwin first. I have built CMake 2.8.1rc3 under Cygwin and to my surprise it finds g77 before gfortran, so that the Fortran 95 support is turned off. The compiler test executable reports: compiler:[GNU] platform:[Cygwin] There is nothing to indicate either gfortran or g77, so I think that the ambiguity is solved the wrong way! (Building seems to going fine - but under Cygwin things are building considerably slower) > > (I found some small errors in plgradient.c and plfill.c > that caused gcc to complain - repaired those) > Committed the .def files - pspal0 and plspal1 were not exported. Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2010-02-21 18:23:20
|
On 2010-02-21 12:27+0100 Arjen Markus wrote: > Hi Alan, > > here are the preliminary results for the new set-up: Thanks, Arjen, for testing all the Windows platform accessible to you. I plan to implement a table in README.release that summarizes test results and which also gives you (and anybody else that does such tests) proper credit for this work. What tests are you doing for each platform? The possibilities are just a build test; ctest (for build tree); test_noninteractive for build tree; test_noninteractive for install tree; test_interactive for build tree; and test_interactive for install tree. I am not sure anybody has yet tried the test_interactive target for Windows so it may not work, but if ctest works, then the test_noninteractive target should work as well (although I would like that prediction to be tested). > > I have worked with the current repository _out of the box_ It's good to start with the current svn trunk version of PLplot, but once you are completely satisfied with the results on CMake-2.6, aren't there some files made redundant by CMake-2.6.x (everything not related to the Compaq compiler?) in cmake/modules/language_support/cmake-2.6/Platform that you can remove? If so, please do that removal, double-check with a final set of complete CMake-2.6 tests, and commit the removal. > [...]Using CMake 2.8.1rc3: > > Windows: Compaq compiler is recognised, but there is no > proper compiler module file. I thought you had already made a good test of the Compaq compiler with the cvs version of CMake. So is there some file you forgot to put into cmake/modules/language_support/cmake-2.8/Platform? Assuming that is the case, do test that file on your local computer, but please don't commit it to our svn trunk version since ideally you would like CMake to carry this file rather than us. So after your tests, you should ask Brad to put this file into the CVS version of CMake and (once that is done) also ask Bill to propagate the file from CVS to cmake-2.8.1. 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-02-22 20:31:14
|
On Sun, 21 Feb 2010 10:23:13 -0800 (PST) "Alan W. Irwin" <ir...@be...> wrote: >> >> Windows: Compaq compiler is recognised, but there is no >> proper compiler module file. > > I thought you had already made a good test of the Compaq >compiler with the > cvs version of CMake. So is there some file you forgot >to put into > cmake/modules/language_support/cmake-2.8/Platform? > > Assuming that is the case, do test that file on your >local computer, but > please don't commit it to our svn trunk version since >ideally you would like > CMake to carry this file rather than us. So after your >tests, you should ask > Brad to put this file into the CVS version of CMake and >(once that is done) > also ask Bill to propagate the file from CVS to >cmake-2.8.1. > I put the Windows-df.cmake file in the proper directory under the name Windows-Compaq-Fortran.cmake (in accordance with the 2.8 convention) and this worked fine. So the bare Windows platform (with MSVC 6.0 and CVF) works fine with this addition. Regards, Arjen |
From: Arjen M. <arj...@de...> - 2010-02-22 07:56:15
|
Hi Alan, On 2010-02-21 19:23, Alan W. Irwin wrote: > On 2010-02-21 12:27+0100 Arjen Markus wrote: > >> Hi Alan, >> >> here are the preliminary results for the new set-up: > > Thanks, Arjen, for testing all the Windows platform accessible to you. I > plan to implement a table in README.release that summarizes test results > and > which also gives you (and anybody else that does such tests) proper credit > for this work. > > What tests are you doing for each platform? The possibilities are just > a build test; ctest (for build tree); test_noninteractive for build tree; > test_noninteractive for install tree; test_interactive for build tree; and > test_interactive for install tree. I am not sure anybody has yet tried > the test_interactive target for Windows so it may not work, but if ctest > works, then the test_noninteractive target should work as well (although > I would like that prediction to be tested). > ctest on Windows is hindered by the need for a bash shell. I do have a Windows version of bash, but in this series of tests I have not used it. My testing procedure was simple: - Start a DOS-box with the required environment settings (giving three different platforms) - Run the selected version of CMake with a minimum number of arguments (two versions) - inspecting the output messages - Run make or nmake to build PLplot for that platform - inspecting the messages as they come along. - Run several examples manually. Running ctest takes somewhat longer but it would be more thorough of course. As I ran into some severe problems, it did not make much sense to run ctest. >> >> I have worked with the current repository _out of the box_ > > It's good to start with the current svn trunk version of PLplot, but once > you are completely satisfied with the results on CMake-2.6, aren't there > some files made redundant by CMake-2.6.x (everything not related to the > Compaq compiler?) in cmake/modules/language_support/cmake-2.6/Platform that > you can remove? If so, please do that removal, double-check with a final > set > of complete CMake-2.6 tests, and commit the removal. I checked: CMake-2.6 does not include the files Cygwin/Windows-GNU-Fortran.cmake that are needed, unless they are available in the latest of that series. > >> [...]Using CMake 2.8.1rc3: >> >> Windows: Compaq compiler is recognised, but there is no >> proper compiler module file. > > I thought you had already made a good test of the Compaq compiler with the > cvs version of CMake. So is there some file you forgot to put into > cmake/modules/language_support/cmake-2.8/Platform? Yes, but I did not want to tamper with CMake rightaway. > > Assuming that is the case, do test that file on your local computer, but > please don't commit it to our svn trunk version since ideally you would > like > CMake to carry this file rather than us. So after your tests, you should > ask > Brad to put this file into the CVS version of CMake and (once that is done) > also ask Bill to propagate the file from CVS to cmake-2.8.1. > That is my idea - yesterday I simply ran out of time to patch CMake with that and test that platform. (I am still not sure why the errors I reported occur - there are no obvious changes in the CMakeLists.txt files or the .cmake file that I can see. I will have to compare with a previous version of PLplot to see where they are coming from) Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2010-02-22 08:26:25
|
On 2010-02-22 08:56+0100 Arjen Markus wrote: >> It's good to start with the current svn trunk version of PLplot, but once >> you are completely satisfied with the results on CMake-2.6, aren't there >> some files made redundant by CMake-2.6.x (everything not related to the >> Compaq compiler?) in cmake/modules/language_support/cmake-2.6/Platform that >> you can remove? If so, please do that removal, double-check with a final >> set >> of complete CMake-2.6 tests, and commit the removal. > > I checked: CMake-2.6 does not include the files > Cygwin/Windows-GNU-Fortran.cmake that are needed, unless they are > available in the latest of that series. Never mind. I misremembered Brad's message on this issue, and your results (needing the above files for 2.6.x) are consistent with what he said. How about cmake/modules/language_support/cmake-2.6/Platform/Windows-df.cmake? There is a file of that name in CMake (donated by you long ago?) that is identical between 2.6.0 and 2.8.1-RC3 (and presumably every version between), but which is different from the PLplot version. If the PLplot version is better, should that revised version of Windows-df.cmake be submitted to CMake to be released as 2.8.1 so we can (eventually) drop our own version of that file? 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-02-22 08:52:48
|
On 2010-02-22 00:26-0800 Alan W. Irwin wrote: > How about cmake/modules/language_support/cmake-2.6/Platform/Windows-df.cmake? > > There is a file of that name in CMake (donated by you long ago?) that is > identical between 2.6.0 and 2.8.1-RC3 (and presumably every version > between), but which is different from the PLplot version. If the PLplot > version is better, should that revised version of Windows-df.cmake be > submitted to CMake to be released as 2.8.1 so we can (eventually) drop our > own version of that file? P.S. with the current location of cmake/modules/language_support/cmake-2.6/Platform/Windows-df.cmake, that file will be used for CMake-2.6.x, but not CMake-2.8.x. If you want it to be used regardless of CMake version, then it should be moved to cmake/modules/language_support/cmake/Platform/Windows-df.cmake. If you agree this is correct, then please do the appropriate svn move command. This fix might solve some of your CMake-2.8 test issues. 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-02-22 09:07:57
|
On 2010-02-22 00:52-0800 Alan W. Irwin wrote: > On 2010-02-22 00:26-0800 Alan W. Irwin wrote: > >> How about cmake/modules/language_support/cmake-2.6/Platform/Windows-df.cmake? >> >> There is a file of that name in CMake (donated by you long ago?) that is >> identical between 2.6.0 and 2.8.1-RC3 (and presumably every version >> between), but which is different from the PLplot version. If the PLplot >> version is better, should that revised version of Windows-df.cmake be >> submitted to CMake to be released as 2.8.1 so we can (eventually) drop our >> own version of that file? > > P.S. with the current location of > cmake/modules/language_support/cmake-2.6/Platform/Windows-df.cmake, that > file will be used for CMake-2.6.x, but not CMake-2.8.x. If you want it to > be used regardless of CMake version, then it should be moved to > cmake/modules/language_support/cmake/Platform/Windows-df.cmake. > > If you agree this is correct, then please do the appropriate svn move > command. This fix might solve some of your CMake-2.8 test issues. Argh. The above idea won't work. Instead, you should svn copy the file to cmake/modules/language_support/cmake-2.8/Platform/Windows-df.cmake 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-02-22 09:28:22
|
Hi Alan, the differences between these files have to do with the /force option. This forces the linker to produce an executable or DLL even in the presence of conflicting runtime libraries. I am not sure it is no longer needed - in the past it has turned out nearly impossible to get a consistent set of runtime libraries so that all the complaints disappear - especially if there are third-party libraries involved. I will follow your advice about copying that particular file into cmake-2.8/Platform. Regards, Arjen On 2010-02-22 10:07, Alan W. Irwin wrote: > On 2010-02-22 00:52-0800 Alan W. Irwin wrote: > >> On 2010-02-22 00:26-0800 Alan W. Irwin wrote: >> >>> How about >>> cmake/modules/language_support/cmake-2.6/Platform/Windows-df.cmake? >>> >>> There is a file of that name in CMake (donated by you long ago?) that is >>> identical between 2.6.0 and 2.8.1-RC3 (and presumably every version >>> between), but which is different from the PLplot version. If the PLplot >>> version is better, should that revised version of Windows-df.cmake be >>> submitted to CMake to be released as 2.8.1 so we can (eventually) >>> drop our >>> own version of that file? >> >> P.S. with the current location of >> cmake/modules/language_support/cmake-2.6/Platform/Windows-df.cmake, that >> file will be used for CMake-2.6.x, but not CMake-2.8.x. If you want >> it to >> be used regardless of CMake version, then it should be moved to >> cmake/modules/language_support/cmake/Platform/Windows-df.cmake. >> >> If you agree this is correct, then please do the appropriate svn move >> command. This fix might solve some of your CMake-2.8 test issues. > > Argh. The above idea won't work. Instead, you should svn copy the file to > cmake/modules/language_support/cmake-2.8/Platform/Windows-df.cmake > > 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 > __________________________ > |