From: Andrew R. <and...@us...> - 2009-05-07 09:11:25
|
I think I have found a bug with our current cmake build system. For link flags cmake now (with cmake 2.6.3 at least) adds a tag describing which type of build this link flag is for. E.g. plpotf77cd_LIB_DEPENDS:STATIC=general;plplotd; On the whole we seem to handle the general tag correctly, although I can't see where this happens in plplot. For the qt drivers we get different libraries depending on the build type, e.g. qt_LIB_DEPENDS contains ;debug;/usr/lib/libQtSvg.so;optimized;/usr/lib/libQtSvg; This doesn't seem to cause any problems for the build, but if you look in pkgcfg/plplotd-qt.pc then debug and optimized appear in the libs list. This causes a build of the examples in the install tree to fail for anything which uses pkg-config plplotd-qt. Normally this does not show up (plplotd-qt.pc is not used). The problem becomes much more serious if you try and do a build with ENABLE_DYNDRIVERS=OFF, because then all the driver library dependencies end up in plplotd.pc, and so any plplot build using pkg-config will fail. Alan, I don't fully understand all the cmake logic involved here. Can you replicate this problem, and can you check to see if it is a problem with our code. I can't see why general gets stripped out, but not optimized or debug. Thanks Andrew |
From: Andrew R. <and...@us...> - 2009-05-07 09:54:14
|
Further to my previous report, this only seems to occur if you explicitly set the cmake build type, e.g. with -DCMAKE_BUILD_TYPE=Debug. This is probably why no-one has reported it before. Without this option the Qt library dependencies contain no type tags and so the problem does not occur. Not sure whether you would classify this as a cmake problem or a plplot problem. Either way it is irritating if you are trying to debug plplot problems. Andrew On Thu, May 07, 2009 at 10:11:10AM +0100, Andrew Ross wrote: > > I think I have found a bug with our current cmake build system. For link > flags cmake now (with cmake 2.6.3 at least) adds a tag describing which > type of build this link flag is for. E.g. > plpotf77cd_LIB_DEPENDS:STATIC=general;plplotd; > > On the whole we seem to handle the general tag correctly, although I can't > see where this happens in plplot. > > For the qt drivers we get different libraries depending on the build type, > e.g. qt_LIB_DEPENDS contains > ;debug;/usr/lib/libQtSvg.so;optimized;/usr/lib/libQtSvg; > > This doesn't seem to cause any problems for the build, but if you look in > pkgcfg/plplotd-qt.pc then debug and optimized appear in the libs list. This > causes a build of the examples in the install tree to fail for anything > which uses pkg-config plplotd-qt. Normally this does not show up > (plplotd-qt.pc is not used). The problem becomes much more serious if you > try and do a build with ENABLE_DYNDRIVERS=OFF, because then all the driver > library dependencies end up in plplotd.pc, and so any plplot build using > pkg-config will fail. > > Alan, I don't fully understand all the cmake logic involved here. Can you > replicate this problem, and can you check to see if it is a problem with > our code. I can't see why general gets stripped out, but not optimized or > debug. > > Thanks > > Andrew > > > ------------------------------------------------------------------------------ > The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your > production scanning environment may not be a perfect world - but thanks to > Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 > Series Scanner you'll get full speed at 300 dpi even with all image > processing features enabled. http://p.sf.net/sfu/kodak-com > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > |
From: Alan W. I. <ir...@be...> - 2009-05-07 19:20:55
|
On 2009-05-07 10:53+0100 Andrew Ross wrote: > > Further to my previous report, this only seems to occur if you explicitly > set the cmake build type, e.g. with -DCMAKE_BUILD_TYPE=Debug. This is > probably why no-one has reported it before. Without this option the Qt library > dependencies contain no type tags and so the problem does not occur. Not sure > whether you would classify this as a cmake problem or a plplot problem. > Either way it is irritating if you are trying to debug plplot problems. I confirm the issue for 2.6.0 so I assume it will appear for all 2.6.x. What is going on is for -DCMAKE_BUILD_TYPE=Debug, FindQt4.cmake embeds the debug, optimized, and general CMake keywords into the returned QT_LIBRARIES list. Those keywords have a special meaning for the CMake target_link_libraries command, but they screw up any other use of QT_LIBRARIES such as my use of it to create plplotd-qt.pc. FindQt4.cmake isn't the only CMake find module that uses those keywords, but I guess it's just the first one where PLplot has encountered the issue. So what is needed is a general parsing routine to take just the debug, optimized, or general part of LIBRARIES lists returned by Find modules that is appropriate for the CMAKE_BUILD_TYPE. This should be fairly straightforward, but still rather time-consuming to implement and test so I suggest we put off implementing this LIBRARIES parsing routine until post-release. For now, the safe thing to do is to avoid the use of -DCMAKE_BUILD_TYPE (which as far as I know has never worked properly on Linux) and instead if you want to debug just simply use the environment variable approach to control your compile flags, e.g., export CC='gcc -g' export CXX='g++ -g' export FC='gfortran -g' I routinely use this approach (with the added -fvisibility=hidden flag), and it works well. 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: Andrew R. <and...@us...> - 2009-05-07 20:49:05
|
On Thu, May 07, 2009 at 12:20:49PM -0700, Alan Irwin wrote: > On 2009-05-07 10:53+0100 Andrew Ross wrote: > >> >> Further to my previous report, this only seems to occur if you explicitly >> set the cmake build type, e.g. with -DCMAKE_BUILD_TYPE=Debug. This is >> probably why no-one has reported it before. Without this option the Qt library >> dependencies contain no type tags and so the problem does not occur. Not sure >> whether you would classify this as a cmake problem or a plplot problem. >> Either way it is irritating if you are trying to debug plplot problems. > > I confirm the issue for 2.6.0 so I assume it will appear for all 2.6.x. > What is going on is for -DCMAKE_BUILD_TYPE=Debug, FindQt4.cmake embeds the > debug, optimized, and general CMake keywords into the returned QT_LIBRARIES > list. Those keywords have a special meaning for the CMake > target_link_libraries command, but they screw up any other use of > QT_LIBRARIES such as my use of it to create plplotd-qt.pc. > > FindQt4.cmake isn't the only CMake find module that uses those keywords, but > I guess it's just the first one where PLplot has encountered the issue. So > what is needed is a general parsing routine to take just the debug, > optimized, or general part of LIBRARIES lists returned by Find modules that > is appropriate for the CMAKE_BUILD_TYPE. This should be fairly > straightforward, but still rather time-consuming to implement and test so I > suggest we put off implementing this LIBRARIES parsing routine until > post-release. > > For now, the safe thing to do is to avoid the use of -DCMAKE_BUILD_TYPE > (which as far as I know has never worked properly on Linux) and instead if > you want to debug just simply use the environment variable approach to > control your compile flags, e.g., > > export CC='gcc -g' > export CXX='g++ -g' > export FC='gfortran -g' > > I routinely use this approach (with the added -fvisibility=hidden flag), and > it works well. You are probably right. What I don't understand is why it works with the general tag (which is there even if you don't specify a build type, but not with the optimized or debug tags. Andrew |
From: Alan W. I. <ir...@be...> - 2009-05-07 23:52:33
|
On 2009-05-07 21:49+0100 Andrew Ross wrote: > You are probably right. What I don't understand is why it works with the > general tag (which is there even if you don't specify a build type, but > not with the optimized or debug tags. Well remember, the likes of plplotd_LIB_DEPENDS:STATIC=general;/usr/lib/libltdl.so;general;/usr/lib/libdl.so;general;/usr/lib/libm.so;general;csirocsa;general;csironn;general;qsastime;general;/usr/lib/libfreetype.so is a derived cached variable and nothing we use directly. Instead, we use *_LIBRARIES variables returned by Find modules. I just checked the FindQT4.cmake logic and there is no mention of "general" in there although there are mentions of "debug" and "optimized". Thus, QT_LIBRARIES cannot have an embedded "general" keyword so the present logic works fine so long as you don't specify CMAKE_BUILD_TYPE. I will know a lot more about this when I get a chance to dig into it post-release. 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: Andrew R. <and...@us...> - 2009-05-08 18:09:42
|
On Thu, May 07, 2009 at 04:52:28PM -0700, Alan Irwin wrote: > On 2009-05-07 21:49+0100 Andrew Ross wrote: > > > You are probably right. What I don't understand is why it works with the > > general tag (which is there even if you don't specify a build type, but > > not with the optimized or debug tags. > > Well remember, the likes of > > plplotd_LIB_DEPENDS:STATIC=general;/usr/lib/libltdl.so;general;/usr/lib/libdl.so;general;/usr/lib/libm.so;general;csirocsa;general;csironn;general;qsastime;general;/usr/lib/libfreetype.so > > is a derived cached variable and nothing we use directly. Instead, we use > *_LIBRARIES variables returned by Find modules. > > I just checked the FindQT4.cmake logic and there is no mention of "general" > in there although there are mentions of "debug" and "optimized". Thus, > QT_LIBRARIES cannot have an embedded "general" keyword so the present logic > works fine so long as you don't specify CMAKE_BUILD_TYPE. > > I will know a lot more about this when I get a chance to dig into it > post-release. I think I have a fix now. I'm just testing it with and without CMAKE_BUILD_TYPE set before I commit. It's relatively straightforward and works fine for Linux. It should do nothing when the debug and optimized tags are not present. Regards Andrew |
From: Alan W. I. <ir...@be...> - 2009-05-08 20:38:40
|
On 2009-05-08 19:09+0100 Andrew Ross wrote: > On Thu, May 07, 2009 at 04:52:28PM -0700, Alan Irwin wrote: >> On 2009-05-07 21:49+0100 Andrew Ross wrote: >> >>> You are probably right. What I don't understand is why it works with the >>> general tag (which is there even if you don't specify a build type, but >>> not with the optimized or debug tags. >> >> Well remember, the likes of >> >> plplotd_LIB_DEPENDS:STATIC=general;/usr/lib/libltdl.so;general;/usr/lib/libdl.so;general;/usr/lib/libm.so;general;csirocsa;general;csironn;general;qsastime;general;/usr/lib/libfreetype.so >> >> is a derived cached variable and nothing we use directly. Instead, we use >> *_LIBRARIES variables returned by Find modules. >> >> I just checked the FindQT4.cmake logic and there is no mention of "general" >> in there although there are mentions of "debug" and "optimized". Thus, >> QT_LIBRARIES cannot have an embedded "general" keyword so the present logic >> works fine so long as you don't specify CMAKE_BUILD_TYPE. >> >> I will know a lot more about this when I get a chance to dig into it >> post-release. > > I think I have a fix now. I'm just testing it with and without > CMAKE_BUILD_TYPE set before I commit. It's relatively straightforward and > works fine for Linux. It should do nothing when the debug and > optimized tags are not present. Oops. I decided to work on this this morning when time ran out for qsastime. Sorry we duplicated effort. For my implementation see revision 9944. It consists of a simple macro to parse a libraries list into its keyworded components, and use of that macro to decide on what component of QT_LIBRARIES to use. My tests of those changes (and the accompanying "before" and "after" QT_LIBRARIES results you see printed out from cmake) show that there is actually no Qt4 difference between debug, optimized, and general on my platform so I now get identical results for the Qt libraries regardless of CMAKE_BUILD_TYPE setting. However, this new logic obviously needs testing on platforms where there might be a difference in the various kinds of Qt4 libraries. With regard to qsastime, I have done some infrastructure changes that will make the final qsastime update much easier to do post-release. Those changes work for me, but they also obviously need testing between now and the (Sunday?) release on all accessible platforms. 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...> - 2009-05-10 15:43:07
|
On 2009-05-10 11:38+0100 Andrew Ross wrote: >> I don't completely trust QT_LIBRARIES_optimized because it appears to be >> incomplete (see above discussion). However, I have checked with "ldd -r >> qt.so" and "ldd -r qt_example" that -DCMAKE_BUILD_TYPE=Release works on >> Linux without any undefined variables for the downloadable Qt-4.5.1 >> available for 64-bit Linux. Indeed, even though plplotd-qt.pc does not have >> some of the missing libraries, they show up in ldd anyway (which is why >> there is no undefined symbols). So I am going to leave in this "Release" >> possibility for now. But if there are problems with >> -DCMAKE_BUILD_TYPE=Release and qt on any other platform (because of what I >> think is a bug in FindQt4.cmake), then I will only use >> QT_LIBRARIES_optimized as a last resort if both the QT_LIBRARIES_debug >> subset and the QT_LIBRARIES_general subset are empty. > > Alan, I agree with your analysis, although I hadn't noticed the bug you > mention which leads to multiple libraries listed after a single debug tag. > I must admit that all I looked at was the qt_LIB_DEPENDS in CMakeCache.txt > where all the non-QT libraries are marked as general. Do you see this as well? > If so, then I suspect that cmake treats any library without a tag as a general > option. If the general tag is not explicitly used at this stage it would explain > why The only relevant variable here is QT_LIBRARIES since that is what we (indirectly) use to generate the plplotd-qt.pc result. cmake now prints out QT_LIBRARIES (both before and after processing) so you can see exactly what is happening. > > 1) everything just "works" for the general case without any explicit removal > of the general tag. There is never a general keyword in QT_LIBRARIES. Here is the full list (taken from cmake output) I get if CMAKE_BUILD_TYPE is specified optimized;/home/software/qtsdk-2009.02/qt/lib/libQtSvg.so; debug;/home/software/qtsdk-2009.02/qt/lib/libQtSvg.so; optimized;/home/software/qtsdk-2009.02/qt/lib/libQtGui.so; debug;/home/software/qtsdk-2009.02/qt/lib/libQtGui.so;/usr/lib/libSM.so;/usr/lib/libICE.so;/usr/lib/libXrender.so;/usr/lib/libfreetype.so;/usr/lib/libfontconfig.so;/usr/lib/libXext.so;/usr/lib/libX11.so;/usr/lib/libm.so; optimized;/home/software/qtsdk-2009.02/qt/lib/libQtXml.so; debug;/home/software/qtsdk-2009.02/qt/lib/libQtXml.so; optimized;/home/software/qtsdk-2009.02/qt/lib/libQtCore.so; debug;/home/software/qtsdk-2009.02/qt/lib/libQtCore.so;/usr/lib/libgthread-2.0.so;/usr/lib/libglib-2.0.so;/usr/lib/librt.so;-lpthread;-ldl I have put in some carriage returns to make the result clearer, but I have kept the existing order (unlike the previous time I gave these results where I reordered them). Note the pattern is optimized followed by one library, debug followed by that same library, then the dependent libraries (if they exist for that library) which are counted as debug because of there position in the list. This pattern repeats for each general kind of Qt library. Note, /usr/lib/libSM.so is the first dependent library. If CMAKE_BUILD_TYPE is not specified I get the above results with the optimized stanzas dropped, and the debug keywords dropped (and no general keyword applied). In this case, the dependent libraries are classified as unkeyworded. These results seem exactly consistent with my analysis. Do you confirm these results on your own system with and without CMAKE_BUILD_TYPE being specified? 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: Andrew R. <and...@us...> - 2009-05-11 21:27:29
|
On Sun, May 10, 2009 at 08:42:56AM -0700, Alan Irwin wrote: > On 2009-05-10 11:38+0100 Andrew Ross wrote: > > >> I don't completely trust QT_LIBRARIES_optimized because it appears to be > >> incomplete (see above discussion). However, I have checked with "ldd -r > >> qt.so" and "ldd -r qt_example" that -DCMAKE_BUILD_TYPE=Release works on > >> Linux without any undefined variables for the downloadable Qt-4.5.1 > >> available for 64-bit Linux. Indeed, even though plplotd-qt.pc does not have > >> some of the missing libraries, they show up in ldd anyway (which is why > >> there is no undefined symbols). So I am going to leave in this "Release" > >> possibility for now. But if there are problems with > >> -DCMAKE_BUILD_TYPE=Release and qt on any other platform (because of what I > >> think is a bug in FindQt4.cmake), then I will only use > >> QT_LIBRARIES_optimized as a last resort if both the QT_LIBRARIES_debug > >> subset and the QT_LIBRARIES_general subset are empty. > > > > Alan, I agree with your analysis, although I hadn't noticed the bug you > > mention which leads to multiple libraries listed after a single debug tag. > > I must admit that all I looked at was the qt_LIB_DEPENDS in CMakeCache.txt > > where all the non-QT libraries are marked as general. Do you see this as well? > > If so, then I suspect that cmake treats any library without a tag as a general > > option. If the general tag is not explicitly used at this stage it would explain > > why > > The only relevant variable here is QT_LIBRARIES since that is what we > (indirectly) use to generate the plplotd-qt.pc result. cmake now > prints out QT_LIBRARIES (both before and after processing) so you can see > exactly what is happening. > > > > > 1) everything just "works" for the general case without any explicit removal > > of the general tag. > > There is never a general keyword in QT_LIBRARIES. > > Here is the full list (taken from cmake output) > I get if CMAKE_BUILD_TYPE is specified > > optimized;/home/software/qtsdk-2009.02/qt/lib/libQtSvg.so; > debug;/home/software/qtsdk-2009.02/qt/lib/libQtSvg.so; > optimized;/home/software/qtsdk-2009.02/qt/lib/libQtGui.so; > debug;/home/software/qtsdk-2009.02/qt/lib/libQtGui.so;/usr/lib/libSM.so;/usr/lib/libICE.so;/usr/lib/libXrender.so;/usr/lib/libfreetype.so;/usr/lib/libfontconfig.so;/usr/lib/libXext.so;/usr/lib/libX11.so;/usr/lib/libm.so; > optimized;/home/software/qtsdk-2009.02/qt/lib/libQtXml.so; > debug;/home/software/qtsdk-2009.02/qt/lib/libQtXml.so; > optimized;/home/software/qtsdk-2009.02/qt/lib/libQtCore.so; > debug;/home/software/qtsdk-2009.02/qt/lib/libQtCore.so;/usr/lib/libgthread-2.0.so;/usr/lib/libglib-2.0.so;/usr/lib/librt.so;-lpthread;-ldl > > I have put in some carriage returns to make the result clearer, but I have > kept the existing order (unlike the previous time I gave these results where > I reordered them). > > Note the pattern is optimized followed by one library, debug followed by > that same library, then the dependent libraries (if they exist for that > library) which are counted as debug because of there position in the list. > This pattern repeats for each general kind of Qt library. Note, > /usr/lib/libSM.so is the first dependent library. > > If CMAKE_BUILD_TYPE is not specified I get the above results with the > optimized stanzas dropped, and the debug keywords dropped (and no general > keyword applied). In this case, the dependent libraries are classified as > unkeyworded. > > These results seem exactly consistent with my analysis. Do you confirm these > results on your own system with and without CMAKE_BUILD_TYPE being > specified? I do, but my interpretation of the libraries after the debug is different to yours. I think the debug tag only applies to the first. The subsequent ones are untagged and therefore should be considered to apply to both optimized and debug. This would mean there was no bug. It's also consistent with how cmake seems to treat the libraries. In this case my original patch would work correctly. I need to delve deeper into the FindQt4.cmake to see if this is true. Andrew |
From: Alan W. I. <ir...@be...> - 2009-05-11 23:09:20
|
On 2009-05-11 22:27+0100 Andrew Ross wrote: >> These results seem exactly consistent with my analysis. Do you confirm these >> results on your own system with and without CMAKE_BUILD_TYPE being >> specified? > > I do, but my interpretation of the libraries after the debug is different to > yours. I think the debug tag only applies to the first. I just double-checked the 2.6.4 documentation, and you are right. 'A "debug", "optimized", or "general" keyword indicates that the library _immediately following it_ is to be used only for the corresponding build configuration' I had missed that "immediately following it" qualifier before. Thanks for persisting with this thread until I finally did notice that qualifier in the documentation. My conclusion in light of this new information is that FindQt4.cmake does everything correctly. For PLplot I could do a QT_LIBRARIES processing bug fix (which should only affect the -DCMAKE_BUILD_TYPE=Release possibility) based on this new information. However, it appears your fix already does the right thing and is more elegant as well so I have removed mine and reinstated yours (revision 9967). I don't think the deficiencies of my implementation are critical for 5.9.4 because -DCMAKE_BUILD_TYPE=Release works for 5.9.4 on Linux. (Therefore, Hazen, you will be glad to know no release is required for next weekend. :-) ) But it is good to get this issue completely straightened out so -DCMAKE_BUILD_TYPE=Release will work on non-Linux platforms as well in the future. 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...> - 2009-05-07 17:36:49
|
On 2009-05-07 10:53+0100 Andrew Ross wrote: > > Further to my previous report, this only seems to occur if you explicitly > set the cmake build type, e.g. with -DCMAKE_BUILD_TYPE=Debug. This is > probably why no-one has reported it before. Without this option the Qt library > dependencies contain no type tags and so the problem does not occur. Not sure > whether you would classify this as a cmake problem or a plplot problem. > Either way it is irritating if you are trying to debug plplot problems. > > Andrew > > On Thu, May 07, 2009 at 10:11:10AM +0100, Andrew Ross wrote: >> >> I think I have found a bug with our current cmake build system. For link >> flags cmake now (with cmake 2.6.3 at least) adds a tag describing which >> type of build this link flag is for. E.g. >> plpotf77cd_LIB_DEPENDS:STATIC=general;plplotd; >> >> On the whole we seem to handle the general tag correctly, although I can't >> see where this happens in plplot. >> >> For the qt drivers we get different libraries depending on the build type, >> e.g. qt_LIB_DEPENDS contains >> ;debug;/usr/lib/libQtSvg.so;optimized;/usr/lib/libQtSvg; >> >> This doesn't seem to cause any problems for the build, but if you look in >> pkgcfg/plplotd-qt.pc then debug and optimized appear in the libs list. This >> causes a build of the examples in the install tree to fail for anything >> which uses pkg-config plplotd-qt. Normally this does not show up >> (plplotd-qt.pc is not used). The problem becomes much more serious if you >> try and do a build with ENABLE_DYNDRIVERS=OFF, because then all the driver >> library dependencies end up in plplotd.pc, and so any plplot build using >> pkg-config will fail. >> >> Alan, I don't fully understand all the cmake logic involved here. Can you >> replicate this problem, and can you check to see if it is a problem with >> our code. I can't see why general gets stripped out, but not optimized or >> debug. >> Actually, tags leaking into plplotd-qt.pc should cause the build of examples/c++/qt_example to fail. I wonder why you didn't see that? If you exclude qt, does -DCMAKE_BUILD_TYPE=Debug actually work? There was a very long standing Linux bug in that (some needed flags were empty) which I reported. IIRC, it was just last year that Bill Hoffman still didn't have a fix. It would be great if that actually worked, but I haven't been using it because I didn't trust this method. Instead, I have always set the CC, CXX, and FC environment variables with appropriate compilation flags. I do hope you answer those questions to satisfy my curiosity, but I do realize those are beside the main point which is tags should never leak into plplotd-qt.pc. I will take a look at 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: Andrew R. <and...@us...> - 2009-05-07 20:47:35
|
On Thu, May 07, 2009 at 10:36:37AM -0700, Alan Irwin wrote: > On 2009-05-07 10:53+0100 Andrew Ross wrote: > >> >> Further to my previous report, this only seems to occur if you explicitly >> set the cmake build type, e.g. with -DCMAKE_BUILD_TYPE=Debug. This is >> probably why no-one has reported it before. Without this option the Qt library >> dependencies contain no type tags and so the problem does not occur. Not sure >> whether you would classify this as a cmake problem or a plplot problem. >> Either way it is irritating if you are trying to debug plplot problems. >> >> Andrew >> >> On Thu, May 07, 2009 at 10:11:10AM +0100, Andrew Ross wrote: >>> >>> I think I have found a bug with our current cmake build system. For link >>> flags cmake now (with cmake 2.6.3 at least) adds a tag describing which >>> type of build this link flag is for. E.g. >>> plpotf77cd_LIB_DEPENDS:STATIC=general;plplotd; >>> >>> On the whole we seem to handle the general tag correctly, although I can't >>> see where this happens in plplot. >>> >>> For the qt drivers we get different libraries depending on the build type, >>> e.g. qt_LIB_DEPENDS contains >>> ;debug;/usr/lib/libQtSvg.so;optimized;/usr/lib/libQtSvg; >>> >>> This doesn't seem to cause any problems for the build, but if you look in >>> pkgcfg/plplotd-qt.pc then debug and optimized appear in the libs list. This >>> causes a build of the examples in the install tree to fail for anything >>> which uses pkg-config plplotd-qt. Normally this does not show up >>> (plplotd-qt.pc is not used). The problem becomes much more serious if you >>> try and do a build with ENABLE_DYNDRIVERS=OFF, because then all the driver >>> library dependencies end up in plplotd.pc, and so any plplot build using >>> pkg-config will fail. >>> >>> Alan, I don't fully understand all the cmake logic involved here. Can you >>> replicate this problem, and can you check to see if it is a problem with >>> our code. I can't see why general gets stripped out, but not optimized or >>> debug. >>> > > Actually, tags leaking into plplotd-qt.pc should cause the build of > examples/c++/qt_example to fail. I wonder why you didn't see that? Sorry - I have seen this build fail, presumably for just this reason. > If you exclude qt, does -DCMAKE_BUILD_TYPE=Debug actually work? There was a > very long standing Linux bug in that (some needed flags were empty) which I > reported. IIRC, it was just last year that Bill Hoffman still didn't have a > fix. It would be great if that actually worked, but I haven't been using it > because I didn't trust this method. Instead, I have always set the CC, CXX, > and FC environment variables with appropriate compilation flags. Apart from the pkg-config issue it seems to work fine. Everything builds and I get a library with debug information in which can be used by gdb / valgrind. > I do hope you answer those questions to satisfy my curiosity, but I > do realize those are beside the main point which is > tags should never leak into plplotd-qt.pc. I will take a look at that. Andrew |
From: Alan W. I. <ir...@be...> - 2009-05-08 21:02:19
|
P.S. I now see you actually committed a fix to pkg-config.cmake. Since my changes dealt with the QT_LIBRARIES issue directly, I am wondering whether we should revert your change (because I am not quite sure whether that logic will always work properly) or just leave it in case some other library ever exhibits the same issue that has just been fixed for QT_LIBRARIES. I would like to keep my changes since they do address the QT_LIBRARIES issue in a way that I understand. We could also keep your changes since they peacefully coexists with mine. However, yours is no longer necessary so I leave it to you whether to revert it or not. 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: Andrew R. <and...@us...> - 2009-05-09 10:09:21
|
On Fri, May 08, 2009 at 02:01:59PM -0700, Alan Irwin wrote: > P.S. I now see you actually committed a fix to pkg-config.cmake. Since my > changes dealt with the QT_LIBRARIES issue directly, I am wondering whether > we should revert your change (because I am not quite sure whether that logic > will always work properly) or just leave it in case some other library ever > exhibits the same issue that has just been fixed for QT_LIBRARIES. > > I would like to keep my changes since they do address the QT_LIBRARIES issue > in a way that I understand. We could also keep your changes since they > peacefully coexists with mine. However, yours is no longer necessary so I > leave it to you whether to revert it or not. Alan, As you say, they should coexist. My patch simply removes any optimized tags and libraries for debug builds, and otherwise removes any debug tags and libraries. It then removes the remaining tags which are not needed for pkg-config. It works for me. I'll comment it out for now, but leave the code there, then if the need arises for other libraries we can easily reinstate. It's only a relatively small patch. Andrew |
From: Alan W. I. <ir...@be...> - 2009-05-09 20:18:21
|
On 2009-05-09 11:09+0100 Andrew Ross wrote: > On Fri, May 08, 2009 at 02:01:59PM -0700, Alan Irwin wrote: >> P.S. I now see you actually committed a fix to pkg-config.cmake. Since my >> changes dealt with the QT_LIBRARIES issue directly, I am wondering whether >> we should revert your change (because I am not quite sure whether that logic >> will always work properly) or just leave it in case some other library ever >> exhibits the same issue that has just been fixed for QT_LIBRARIES. >> >> I would like to keep my changes since they do address the QT_LIBRARIES issue >> in a way that I understand. We could also keep your changes since they >> peacefully coexists with mine. However, yours is no longer necessary so I >> leave it to you whether to revert it or not. > > Alan, > > As you say, they should coexist. My patch simply removes any optimized tags and > libraries for debug builds, and otherwise removes any debug tags and libraries. > It then removes the remaining tags which are not needed for pkg-config. It > works for me. I'll comment it out for now, but leave the code there, then if > the need arises for other libraries we can easily reinstate. It's only a > relatively small patch. Hi Andrew: I would like to discuss some of the background for my fix since there is a fair bit of interpretation and cmake code reading involved. At the end I have a question for you in regard to your regexes. If you dig into FindQt4.cmake and UseQt4.cmake, the latter shows that QT_LIBRARIES is made up of individual ${QT_${module}_LIBRARY} values and ${QT_${module}_LIB_DEPENDENCIES} values. FindQt4.cmake sets both ${QT_${module}_LIBRARY} and ${QT_${module}_LIBRARIES} forms but the latter form is completely ignored (which sure is a misleading form of variable name!) when forming QT_LIBRARIES. Furthermore, FindQt4.cmake sets the ${QT_${module}_LIB_DEPENDENCIES} form of variables. It appears that the Qt4 libraries are released as either RELEASE or DEBUG versions. The macro _QT4_ADJUST_LIB_VARS in FindQt4.cmake sets the LIBRARY form of variable to the RELEASE version of Qt4 library if that is all there is and similarly it sets that form of variable to the DEBUG version of Qt4 library if that is all there is. Finally, if both versions of Qt4 library exist, then there are two code paths possible. If CMAKE_BUILD_TYPE is set (to any value) then the LIBRARY form of variable is set to both the RELEASE and DEBUG versions of Qt4 libraries with each indicated by the keywords "optimized" and "debug". If the CMAKE_BUILD_TYPE is not set the LIBRARY form of variable is set to RELEASE version of the Qt4 libraries. For those cases where the debug keyword is used, it is used after the optimized keyword so that the appended ${QT_${module}_LIB_DEPENDENCIES} values are interpreted _only_ as debug libraries or generaly (no keyword) libraries, but not as optimized libraries. I think that is a bug, but I am not sure. The results obtained on my system support this partial analysis. If any value of CMAKE_BUILD_TYPE is specified via a cmake option, then the QT_LIBRARIES list delivered by FindQt4.cmake is (rearranged for clarity) optimized;/home/software/qtsdk-2009.02/qt/lib/libQtSvg.so; optimized;/home/software/qtsdk-2009.02/qt/lib/libQtGui.so; optimized;/home/software/qtsdk-2009.02/qt/lib/libQtXml.so; optimized;/home/software/qtsdk-2009.02/qt/lib/libQtCore.so; debug;/home/software/qtsdk-2009.02/qt/lib/libQtSvg.so; debug;/home/software/qtsdk-2009.02/qt/lib/libQtGui.so;/usr/lib/libSM.so;/usr/lib/libICE.so;/usr/lib/libXrender.so;/usr/lib/libfreetype.so;/usr/lib/libfontconfig.so;/usr/lib/libXext.so;/usr/lib/libX11.so;/usr/lib/libm.so; debug;/home/software/qtsdk-2009.02/qt/lib/libQtXml.so; debug;/home/software/qtsdk-2009.02/qt/lib/libQtCore.so;/usr/lib/libgthread-2.0.so;/usr/lib/libglib-2.0.so;/usr/lib/librt.so;-lpthread;-ldl If you do not specify CMAKE_BUILD_TYPE you get the debug version (without the debug keyword). Note, the extra set of libraries for the debug version (and general version) I attribute to the code quirk (or bug) I noted above for how ${QT_${module}_LIB_DEPENDENCIES} variables are just appended to what comes before with no regard to whether it has keywords or not. Regardless of this question, I have recently (revision 9948) made the QT_LIBRARIES logic a lot safer. Only in the case of a specific request for the Release CMake_BUILD_type and non-empty QT_LIBRARIES_optimized is that keyworded subset of QT_LIBRARIES used. Otherwise, I use the QT_LIBRARIES_debug subset (if non-empty) or the QT_LIBRARIES_general subset if that is non-empty. I don't completely trust QT_LIBRARIES_optimized because it appears to be incomplete (see above discussion). However, I have checked with "ldd -r qt.so" and "ldd -r qt_example" that -DCMAKE_BUILD_TYPE=Release works on Linux without any undefined variables for the downloadable Qt-4.5.1 available for 64-bit Linux. Indeed, even though plplotd-qt.pc does not have some of the missing libraries, they show up in ldd anyway (which is why there is no undefined symbols). So I am going to leave in this "Release" possibility for now. But if there are problems with -DCMAKE_BUILD_TYPE=Release and qt on any other platform (because of what I think is a bug in FindQt4.cmake), then I will only use QT_LIBRARIES_optimized as a last resort if both the QT_LIBRARIES_debug subset and the QT_LIBRARIES_general subset are empty. Getting back to your own (commented out) solution, it is good to have that in reserve in case some other Find module starts passing back keyworded library information. However, I am having trouble figuring out what your commented out regex's would do. I think you are just dropping the keywords rather than keyword + associated libraries like you state above. Could you let me know which interpretation of the regexes is correct? I actually think that dropping just the keywords is the safest course because if we ever need this logic the result of just dropping the keywords would be repeated libraries and extra unneeded libraries. That is a much more acceptable (and safer) result than potentially dropping a library that might be essential. 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: Andrew R. <and...@us...> - 2009-05-10 10:38:28
|
On Sat, May 09, 2009 at 01:18:17PM -0700, Alan Irwin wrote: > On 2009-05-09 11:09+0100 Andrew Ross wrote: > >> On Fri, May 08, 2009 at 02:01:59PM -0700, Alan Irwin wrote: >>> P.S. I now see you actually committed a fix to pkg-config.cmake. Since my >>> changes dealt with the QT_LIBRARIES issue directly, I am wondering whether >>> we should revert your change (because I am not quite sure whether that logic >>> will always work properly) or just leave it in case some other library ever >>> exhibits the same issue that has just been fixed for QT_LIBRARIES. >>> >>> I would like to keep my changes since they do address the QT_LIBRARIES issue >>> in a way that I understand. We could also keep your changes since they >>> peacefully coexists with mine. However, yours is no longer necessary so I >>> leave it to you whether to revert it or not. >> >> Alan, >> >> As you say, they should coexist. My patch simply removes any optimized tags and >> libraries for debug builds, and otherwise removes any debug tags and libraries. >> It then removes the remaining tags which are not needed for pkg-config. It >> works for me. I'll comment it out for now, but leave the code there, then if >> the need arises for other libraries we can easily reinstate. It's only a >> relatively small patch. > > Hi Andrew: > > I would like to discuss some of the background for my fix since there is a > fair bit of interpretation and cmake code reading involved. At the end I > have a question for you in regard to your regexes. > > If you dig into FindQt4.cmake and UseQt4.cmake, the latter shows that > QT_LIBRARIES is made up of individual ${QT_${module}_LIBRARY} values and > ${QT_${module}_LIB_DEPENDENCIES} values. FindQt4.cmake sets both > ${QT_${module}_LIBRARY} and ${QT_${module}_LIBRARIES} forms but the latter > form is completely ignored (which sure is a misleading form of variable > name!) when forming QT_LIBRARIES. Furthermore, FindQt4.cmake sets the > ${QT_${module}_LIB_DEPENDENCIES} form of variables. > > It appears that the Qt4 libraries are released as either RELEASE or DEBUG > versions. The macro _QT4_ADJUST_LIB_VARS in FindQt4.cmake sets the LIBRARY > form of variable to the RELEASE version of Qt4 library if that is all there > is and similarly it sets that form of variable to the DEBUG version of Qt4 > library if that is all there is. Finally, if both versions of Qt4 library > exist, then there are two code paths possible. If CMAKE_BUILD_TYPE is set > (to any value) then the LIBRARY form of variable is set to both the RELEASE > and DEBUG versions of Qt4 libraries with each indicated by the keywords > "optimized" and "debug". If the CMAKE_BUILD_TYPE is not set the LIBRARY > form of variable is set to RELEASE version of the Qt4 libraries. For those > cases where the debug keyword is used, it is used after the optimized > keyword so that the appended ${QT_${module}_LIB_DEPENDENCIES} values are > interpreted _only_ as debug libraries or generaly (no keyword) libraries, > but not as optimized libraries. I think that is a bug, but I am not sure. > > The results obtained on my system support this partial analysis. > If any value of CMAKE_BUILD_TYPE is specified via a cmake option, then > the QT_LIBRARIES list delivered by FindQt4.cmake is (rearranged for > clarity) > > optimized;/home/software/qtsdk-2009.02/qt/lib/libQtSvg.so; > optimized;/home/software/qtsdk-2009.02/qt/lib/libQtGui.so; > optimized;/home/software/qtsdk-2009.02/qt/lib/libQtXml.so; > optimized;/home/software/qtsdk-2009.02/qt/lib/libQtCore.so; > > debug;/home/software/qtsdk-2009.02/qt/lib/libQtSvg.so; > debug;/home/software/qtsdk-2009.02/qt/lib/libQtGui.so;/usr/lib/libSM.so;/usr/lib/libICE.so;/usr/lib/libXrender.so;/usr/lib/libfreetype.so;/usr/lib/libfontconfig.so;/usr/lib/libXext.so;/usr/lib/libX11.so;/usr/lib/libm.so; > debug;/home/software/qtsdk-2009.02/qt/lib/libQtXml.so; > debug;/home/software/qtsdk-2009.02/qt/lib/libQtCore.so;/usr/lib/libgthread-2.0.so;/usr/lib/libglib-2.0.so;/usr/lib/librt.so;-lpthread;-ldl > > If you do not specify CMAKE_BUILD_TYPE you get the debug version (without > the debug keyword). > > Note, the extra set of libraries for the debug version (and general version) > I attribute to the code quirk (or bug) I noted above for how > ${QT_${module}_LIB_DEPENDENCIES} variables are just appended to what comes > before with no regard to whether it has keywords or not. > > Regardless of this question, I have recently (revision 9948) made the > QT_LIBRARIES logic a lot safer. Only in the case of a specific request for > the Release CMake_BUILD_type and non-empty QT_LIBRARIES_optimized is that > keyworded subset of QT_LIBRARIES used. Otherwise, I use the > QT_LIBRARIES_debug subset (if non-empty) or the QT_LIBRARIES_general subset > if that is non-empty. > > I don't completely trust QT_LIBRARIES_optimized because it appears to be > incomplete (see above discussion). However, I have checked with "ldd -r > qt.so" and "ldd -r qt_example" that -DCMAKE_BUILD_TYPE=Release works on > Linux without any undefined variables for the downloadable Qt-4.5.1 > available for 64-bit Linux. Indeed, even though plplotd-qt.pc does not have > some of the missing libraries, they show up in ldd anyway (which is why > there is no undefined symbols). So I am going to leave in this "Release" > possibility for now. But if there are problems with > -DCMAKE_BUILD_TYPE=Release and qt on any other platform (because of what I > think is a bug in FindQt4.cmake), then I will only use > QT_LIBRARIES_optimized as a last resort if both the QT_LIBRARIES_debug > subset and the QT_LIBRARIES_general subset are empty. Alan, I agree with your analysis, although I hadn't noticed the bug you mention which leads to multiple libraries listed after a single debug tag. I must admit that all I looked at was the qt_LIB_DEPENDS in CMakeCache.txt where all the non-QT libraries are marked as general. Do you see this as well? If so, then I suspect that cmake treats any library without a tag as a general option. If the general tag is not explicitly used at this stage it would explain why 1) everything just "works" for the general case without any explicit removal of the general tag. 2) Your "bug" is not a bug, but your analysis of the output is not quite correct. > Getting back to your own (commented out) solution, it is good to have that > in reserve in case some other Find module starts passing back keyworded > library information. However, I am having trouble figuring out what your > commented out regex's would do. I think you are just dropping the keywords > rather than keyword + associated libraries like you state above. Could you > let me know which interpretation of the regexes is correct? I actually > think that dropping just the keywords is the safest course because if we > ever need this logic the result of just dropping the keywords would be > repeated libraries and extra unneeded libraries. That is a much more > acceptable (and safer) result than potentially dropping a library that might > be essential. For each case the first regex is essentially <tag>;*; which deletes the tag and the following library. The second regex only deletes the tag. This does not work if your intepretation is correct, but does work if my alternative is correct. In the worst case my version would leave extra libraries in place. Either way, the current implementation needs checking as it is possible not correct. Andrew |
From: Arjen M. <arj...@de...> - 2009-05-11 11:56:03
|
Hi Alan, Andrew, Werner, it may be nothing of consequence, but when I fixed the command-line issue with Fortran 77/95 last week, I could not find any pkg-config file for the platforms I looked at (notably MinGW). I may have missed it, but I was curious whether I should do something about it, as there is an extra library now under some circumstances. It may be that we only generate it for Cygwin (I have not yet checked that platform) - I just thought I'd mention it. Regards, Arjen Delft Hydraulics, GeoDelft, the Subsurface and Groundwater unit of TNO and parts of Rijkswaterstaat have joined forces in a new independent institute for delta technology, Deltares. Deltares combines knowledge and experience in the field of water, soil and the subsurface. We provide innovative solutions to make living in deltas, coastal areas and river basins safe, clean and sustainable. DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Alan W. I. <ir...@be...> - 2009-05-11 17:20:04
|
On 2009-05-11 13:55+0200 Arjen Markus wrote: > Hi Alan, Andrew, Werner, > > it may be nothing of consequence, but when I fixed the command-line > issue with Fortran 77/95 last week, I could not find any pkg-config > file for the platforms I looked at (notably MinGW). I may have missed > it, but I was curious whether I should do something about it, as > there is an extra library now under some circumstances. > > It may be that we only generate it for Cygwin (I have not yet checked > that platform) - I just thought I'd mention it. Here is what plplotd-f77.pc looks like for Linux libdir=/home/software/plplot_cvs/installcmake/lib includedir=/home/software/plplot_cvs/installcmake/include/plplot drvdir=/home/software/plplot_cvs/installcmake/lib/plplot5.9.3/driversd Name: PLplot F77 Description: Scientific plotting library (F77 bindings, double precision) Requires: plplotd Version: 5.9.3 Libs: -L${libdir} -lplplotf77d -lplplotf77cd Cflags: -I${includedir} You see that only the normal f77 PLplot libraries are mentioned (-lplplotf77d -lplplotf77cd). That works on Linux because your extra library is not used there, but for platforms/situations where your extra library is used, you should change bindings/f77/CMakeLists.txt to include that extra name in the same format when it configures plplotd-f77.pc. I don't think you omission of this is cause for concern for 5.9.4 since building the installed examples for the Windows platforms where your change matters is probably unexplored territory. However, I really do hope you and Werner explore that territory soon. Once set up, it should be a much easier environment for you guys to work in because everything is located in consistent locations in the install tree rather than scattered all over the build tree. Also, "make test" runs essentially the same scripts as ctest in the build tree so not too much extra effort (you need access to make, pkg-config, and bash) should be required to get things working for you in the installed examples tree. To test your changes out you must install pkg-config on your system (you probably have a WARNING about that now in your cmake output which is why no *.pc files are configured), and, at minimum, inspect the resulting plplotd-f77.pc that is configured to make sure it is okay. Do you need a reminder of the GTK+ location where you can obtain pkg-config for non-Cygwin windows? Of course, for Cygwin, you should have their pkg-config package (see http://cygwin.com/packages/pkg-config/) installed. To test whether you can actually build the installed examples you will need "make" for your Windows platforms. Werner, is there a MinGW version of that or do Windows users just have a Cygwin version available? Finally, I should note that if you don't like the pkg-config approach to deliver the build information you need in the installed examples tree there is another good possibility which is to store the needed compile and link information for library targets in a CMake export file using the INSTALL(EXPORT... cmake command. Then a tiny CMake project which simply included those files and which configured the required add_executable for each example with a foreach loop would be all that was required to build the examples. My attention was drawn to this possibility recently on the CMake list so I thought I would share it here, but I know nothing more about this then what I read in the cmake documentation. I don't have plans to do this myself, but if somebody else is interested I would certainly encourage the effort from the side-lines and also I would be happy to test the implementation of such a CMake-based approach to building our installed examples on Linux. 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...> - 2009-05-11 17:47:03
|
On 2009-05-11 10:19-0700 Alan W. Irwin wrote: > Finally, I should note that if you don't like the pkg-config approach to > deliver the build information you need in the installed examples tree there > is another good possibility which is to store the needed compile and link > information for library targets in a CMake export file using the > INSTALL(EXPORT... cmake command. Then a tiny CMake project which simply > included those files and which configured the required add_executable for > each example with a foreach loop would be all that was required to build the > examples. > > My attention was drawn to this possibility recently on the CMake list so I > thought I would share it here, but I know nothing more about this then what > I read in the cmake documentation. I don't have plans to do this myself, > but if somebody else is interested I would certainly encourage the effort > from the side-lines and also I would be happy to test the implementation of > such a CMake-based approach to building our installed examples on Linux. One additional piece of information.... There was a report from Brad King on the CMake list just a few minutes ago that using imported libraries in the suggested way didn't work quite correctly for CMake-2.6.3 and below, but this bug has been fixed for 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...> - 2009-05-11 19:19:39
|
On 2009-05-11 10:19-0700 Alan W. Irwin wrote: > My attention was drawn to this possibility [of a CMake-based build of the installed examples] recently on the CMake list so I > thought I would share it here, but I know nothing more about this then what > I read in the cmake documentation. I don't have plans to do this myself... Actually, I have been thinking about this some more, and I may try a proof-of-concept (build the installed C examples) this afternoon to see how it goes. If anyone else is working on this interesting idea as well, please keep in touch with me. 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...> - 2009-05-12 00:11:39
|
On 2009-05-11 12:19-0700 Alan W. Irwin wrote: > On 2009-05-11 10:19-0700 Alan W. Irwin wrote: > >> My attention was drawn to this possibility [of a CMake-based build of > the installed examples] recently on the CMake list so I >> thought I would share it here, but I know nothing more about this then what >> I read in the cmake documentation. I don't have plans to do this myself... > > Actually, I have been thinking about this some more, and I may try a > proof-of-concept (build the installed C examples) this afternoon to see how > it goes. If anyone else is working on this interesting idea as well, please > keep in touch with me. It actually was incredibly straightforward. See the proof of concept I have put together for revision 9966 (the bulk of the changes) and revision 9968 (one minor bug fix). The result is a CMake mini-project superimposed on the installed examples tree. For now it just builds the C examples. (Note you will clobber the ordinary Makefile approach if you use an in-source build there so assuming you are in the top level of the installed examples tree do something like mkdir build_dir cd build_dir cmake .. make to build the installed C examples. (Note I only allow CMake version 2.6.4 or later for this mini-project because of an essential CMake bug-fix for that version.) Here is what I have done to implement this. For each dependent target of libplplot add an EXPORT export_plplot stanza to the install command for the target. Add a similar stanza to the libplplot install command. Then use a unique INSTALL(EXPORT ...) command to install everything having to do with PLplot and its dependencies. To take advantage of this installed information (in the top-level of the installed examples tree), I configure CMakeLists.txt_installed_examples.in and install it as CMakeLists.txt in the top-level of the installed examples tree. I also install examples/c/CMakeLists.txt_installed_examples_c as examples/c/CMakeLists.txt. Werner and Arjen, will you please give this proof-of-concept a try on Windows for whatever CMake generator you like there? I am running out of time that I can spend on PLplot for the next two weeks or so, so I hope someone takes this proof of concept and moves forward with it. For example, to add C++ examples, you would have to add an EXPORT export_plplot stanza to the install command that installs the plplotcxxd library and also add a unique INSTALL(EXPORT ...) command for that library while using the FILE option to differentiate the resulting export file from the one associated with libplplot. Then tweak CMakeLists.txt_installed_examples.in to include that file, and create c++/CMakeLists.txt_installed_examples_c++ to build the C++ examples using the plplotcxx${LIB_TAG} install tree target that is automatically imported by this whole process. And so on for each of our installed bindings libraries and associated built examples subdirectories. Finally add a "make test" custom target to CMakeLists.txt_installed_examples.in, and you are already getting quite close to the functionality we have now in the installed examples tree with the combination of configured Makefiles and pkg-config. Note, the export approach only keeps track of target linking and does not keep track of special compile options (such as location of headers). So I had to configure and use INCLUDE_DIR to get access to the PLplot headers. Because of that limitation I am sure you would have to configure any special locations for headers (e.g., an attempt to build qt_example for a special Qt install location). Despite such header location limitations, the CMake export feature is actually pretty amazing, and from the already working C examples build I think this is potentially a terrific way to configure the build of the install-tree examples and also configure (Makefile or other generator) rules to do the install tree testing. 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: Werner S. <sm...@ia...> - 2009-05-12 06:01:56
|
Hi, On 11.05.2009, at 19:19, Alan W. Irwin wrote: > On 2009-05-11 13:55+0200 Arjen Markus wrote: > >> Hi Alan, Andrew, Werner, >> >> it may be nothing of consequence, but when I fixed the command-line >> issue with Fortran 77/95 last week, I could not find any pkg-config >> file for the platforms I looked at (notably MinGW). I may have missed >> it, but I was curious whether I should do something about it, as >> there is an extra library now under some circumstances. pkg-config for "bare Windows" can be found at the gtk+ for Windows page: http://www.gtk.org/download-windows.html , scroll down a little bit. >> >> It may be that we only generate it for Cygwin (I have not yet checked >> that platform) - I just thought I'd mention it. > > Here is what plplotd-f77.pc looks like for Linux > > libdir=/home/software/plplot_cvs/installcmake/lib > includedir=/home/software/plplot_cvs/installcmake/include/plplot > drvdir=/home/software/plplot_cvs/installcmake/lib/plplot5.9.3/driversd > > Name: PLplot F77 > Description: Scientific plotting library (F77 bindings, double > precision) > Requires: plplotd > Version: 5.9.3 > Libs: -L${libdir} -lplplotf77d -lplplotf77cd > Cflags: -I${includedir} > > You see that only the normal f77 PLplot libraries are mentioned > (-lplplotf77d -lplplotf77cd). That works on Linux because your extra > library is not used there, but for platforms/situations where your > extra > library is used, you should change bindings/f77/CMakeLists.txt to > include > that extra name in the same format when it configures plplotd-f77.pc. > > I don't think you omission of this is cause for concern for 5.9.4 > since > building the installed examples for the Windows platforms where your > change matters is probably unexplored territory. > > However, I really do hope you and Werner explore that territory > soon. Once > set up, it should be a much easier environment for you guys to work in > because everything is located in consistent locations in the install > tree > rather than scattered all over the build tree. Also, "make test" runs > essentially the same scripts as ctest in the build tree so not too > much > extra effort (you need access to make, pkg-config, and bash) should be > required to get things working for you in the installed examples tree. I actually never use the install tree to test plplot. I do/test everything in the build tree especially on Windows. > > To test your changes out you must install pkg-config on your system > (you > probably have a WARNING about that now in your cmake output which is > why > no *.pc files are configured), and, at minimum, inspect the resulting > plplotd-f77.pc that is configured to make sure it is okay. Do you > need a reminder of the GTK+ location where you can obtain pkg-config > for > non-Cygwin windows? Of course, for Cygwin, you should have their > pkg-config > package (see http://cygwin.com/packages/pkg-config/) installed. see above. > > To test whether you can actually build the installed examples you > will need > "make" for your Windows platforms. Werner, is there a MinGW version > of that > or do Windows users just have a Cygwin version available? The MinGW version is called mingw32-make. MSYS provides its own make. > > Finally, I should note that if you don't like the pkg-config > approach to > deliver the build information you need in the installed examples > tree there > is another good possibility which is to store the needed compile and > link > information for library targets in a CMake export file using the > INSTALL(EXPORT... cmake command. Then a tiny CMake project which > simply > included those files and which configured the required > add_executable for > each example with a foreach loop would be all that was required to > build the > examples. > > My attention was drawn to this possibility recently on the CMake > list so I > thought I would share it here, but I know nothing more about this > then what > I read in the cmake documentation. I don't have plans to do this > myself, > but if somebody else is interested I would certainly encourage the > effort > from the side-lines and also I would be happy to test the > implementation of > such a CMake-based approach to building our installed examples on > Linux. Regards, Werner > > 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 > __________________________ > > ------------------------------------------------------------------------------ > The NEW KODAK i700 Series Scanners deliver under ANY circumstances! > Your > production scanning environment may not be a perfect world - but > thanks to > Kodak, there's a perfect scanner to get the job done! With the NEW > KODAK i700 > Series Scanner you'll get full speed at 300 dpi even with all image > processing features enabled. http://p.sf.net/sfu/kodak-com > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... 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 |
From: Alan W. I. <ir...@be...> - 2009-05-12 06:50:29
|
On 2009-05-12 08:01+0200 Werner Smekal wrote: > Hi, > > On 11.05.2009, at 19:19, Alan W. Irwin wrote: >> However, I really do hope you and Werner explore that territory soon. Once >> set up, it should be a much easier environment for you guys to work in >> because everything is located in consistent locations in the install tree >> rather than scattered all over the build tree. Also, "make test" runs >> essentially the same scripts as ctest in the build tree so not too much >> extra effort (you need access to make, pkg-config, and bash) should be >> required to get things working for you in the installed examples tree. > > I actually never use the install tree to test plplot. I do/test everything in > the build tree especially on Windows. I do both, but my tendency is to use the install tree a lot more, because of the substantial (factor of two gain in speed for my two-CPU box) advantage of a parallel test infrastructure there that cannot be used with the ctest method; ctest is unaware of the dependencies between tests, and just does the tests in sequence leaving all but one of the CPUs of a multiple CPU box completely idle. N.B. We could also take advantage of the parallel testing possiblity in the build tree if we dropped ctest altogether and instead simply set up our build-tree tests as custom targets with proper dependencies between them. So if you have a multiple cpu box, but don't want to bother with the install tree, then this parallel testing possibility for the build tree would be a good area to work on to allow taking proper advantage of those multiple cpu's for build-tree testing. Of course the above "parallel" testing considerations for both install tree and build tree are only relevant on Windows if there is a Windows CMake generator that allows parallel commands to be executed similar to the GNU make -j option. 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...> - 2009-05-12 07:01:25
|
On 2009-05-12 08:50, Alan W. Irwin wrote: > On 2009-05-12 08:01+0200 Werner Smekal wrote: > > > I do both, but my tendency is to use the install tree a lot more, > because of > the substantial (factor of two gain in speed for my two-CPU box) advantage > of a parallel test infrastructure there that cannot be used with the ctest > method; ctest is unaware of the dependencies between tests, and just does > the tests in sequence leaving all but one of the CPUs of a multiple CPU box > completely idle. > > N.B. We could also take advantage of the parallel testing possiblity in the > build tree if we dropped ctest altogether and instead simply set up our > build-tree tests as custom targets with proper dependencies between > them. So > if you have a multiple cpu box, but don't want to bother with the install > tree, then this parallel testing possibility for the build tree would be a > good area to work on to allow taking proper advantage of those multiple > cpu's > for build-tree testing. > > Of course the above "parallel" testing considerations for both install tree > and build tree are only relevant on Windows if there is a Windows CMake > generator that allows parallel commands to be executed similar to the GNU > make -j option. > For the moment at least I prefer to use the current CTest approach - it may be slower than possible, but it is working (for most languages I can look at anyway) for all four Windows platform flavours I have. I will test the new way of dealing with the examples and will let you know how that goes. (A smooth way of dealing with the PLplot libraries on Windows would be very welcome indeed.) Regards, Arjen Delft Hydraulics, GeoDelft, the Subsurface and Groundwater unit of TNO and parts of Rijkswaterstaat have joined forces in a new independent institute for delta technology, Deltares. Deltares combines knowledge and experience in the field of water, soil and the subsurface. We provide innovative solutions to make living in deltas, coastal areas and river basins safe, clean and sustainable. DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Werner S. <sm...@ia...> - 2009-05-12 07:02:09
|
> Of course the above "parallel" testing considerations for both > install tree > and build tree are only relevant on Windows if there is a Windows > CMake > generator that allows parallel commands to be executed similar to > the GNU > make -j option. AFAIK this is the case for mingw32-make, but I've never tested that due the lack of a multicore CPU ;). My laptop is really old :(. But I'll try that for Mac OSX, where I do have a double-core CPU. Thanks, Werner > > 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 > __________________________ -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... 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 |