From: Werner S. <sm...@ia...> - 2008-02-07 17:03:10
|
Hi list, it is now possible to insert a tag in (all) the library names by setting LIB_TAG at the cmake configuration stage, e.g. cmake -DLIB_TAG=debug .. Reason is, that it is sometimes convenient to have the libraries being distinguishable due their name. E.g. in windows I have a debug and a release build of my program, linked to a debug and release build of wxwidgets. Therefore I need also a debug and release build of plplot linked to the debug and release build of wxwidgets. Since up to now the dlls were called the same, they couldn't stay in the same directory, I would need to set the path or copy dlls all the time I switch from debug to release and vice versa. With that minor change to double.cmake I'm now able to name the plplot libraries differently and both could stay in the same directory. Apart from that some would like to have different versions of plplot installed in Linux, which should be possible as well with this change. Or she has made some custom changes to plplot and would like to have this version called differently. I think that this change was the least extensive change, there are maybe other possibilities. There should be no changes however for those who don't set LIB_TAG at all. I tested the changes on Mac OS X and had no problems, so I hope, that it won't break anything, if so, it's easy to revert. Regards, Werner -- 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...> - 2008-02-07 21:04:41
|
On 2008-02-07 18:03+0100 Werner Smekal wrote: > Hi list, > > it is now possible to insert a tag in (all) the library names by > setting LIB_TAG at the cmake configuration stage, e.g. > > cmake -DLIB_TAG=debug .. Could you please revert the change for now and do it after the release? I think your implementation will not introduce any nasty build-system bugs, but my instinct says we should have a longer testing period to make sure. Also, I think we need some additional discussion here of whether it is worthwhile to have a variety of LIB_TAG's. That does give us different name spaces for library names and device drivers so they can all coexist happily under the same installation prefix, but other components of the PLplot install will just get overwritten by each install with a separate LIB_TAG. I think Maurice is the only one that has practical experience with installs to the same prefix of single and double-precision versions of PLplot, but I am not sure whether he is still doing that or how extensive his testing has been of that situation. Of course, another completely safe alternative to changing LIB_TAG is simply to use differently named install prefixes for each different version of PLplot that you configure. 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...> - 2008-02-08 07:03:03
|
>> Hi Alan, > > Could you please revert the change for now and do it after the > release? I > think your implementation will not introduce any nasty build-system > bugs, > but my instinct says we should have a longer testing period to make > sure. Sure, done. > > > Also, I think we need some additional discussion here of whether it is > worthwhile to have a variety of LIB_TAG's. That does give us > different name > spaces for library names and device drivers so they can all coexist > happily > under the same installation prefix, but other components of the PLplot > install will just get overwritten by each install with a separate > LIB_TAG. I > think Maurice is the only one that has practical experience with > installs to > the same prefix of single and double-precision versions of PLplot, > but I am > not sure whether he is still doing that or how extensive his testing > has > been of that situation. I actually didn't mean that different versions of plplot (with different names) should be installed into the same directories. They should stay in different directories but have different library names. > > > Of course, another completely safe alternative to changing LIB_TAG > is simply > to use differently named install prefixes for each different version > of > PLplot that you configure. That's a possibility though but doesn't work on Windows. I could have a debug and release version of plplot in different installation directories, true. But all .lib files and .dll files are the same. So even if I set the path to both bin directories (where the dlls are), it will choose the first dll it finds - which is in one of the cases the wrong one. I would need to change the PATH variable everytime I change from build to debug release or vice versa. That's not very convenient in Windows (Start->System Preferences->System->Another menu- >Environment Variables, change variable, click two times ok and close the system preferences). Restart Visual C++. Might not work, since Visual C++ somehow caches the enviroment variables sometimes, so I have to REBOOT! (Windows is funny, isn't it :). I know, that in Linux it's not a problem, and I use different versions of plplot in different install directories already, but even here - I could set the LD_LIBRARY_PATH to both or all install directories and I wouldn't need to reset them or start a new terminal (this is now what I do e.g. for the several wxwidgets installations). So, I don't propose that changing the library name should be common use, but there are cases, where I believe that this is the only convenient way to work with several versions of the library and the configuration should provide a way to enable this. What do you think? 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 > __________________________ -- 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: Arjen M. <arj...@wl...> - 2008-02-08 07:25:43
|
Werner Smekal wrote: >That's a possibility though but doesn't work on Windows. I could have >a debug and release version of plplot in different installation >directories, true. But all .lib files and .dll files are the same. So >even if I set the path to both bin directories (where the dlls are), >it will choose the first dll it finds - which is in one of the cases >the wrong one. I would need to change the PATH variable everytime I >change from build to debug release or vice versa. That's not very >convenient in Windows (Start->System Preferences->System->Another menu- > >Environment Variables, change variable, click two times ok and close >the system preferences). Restart Visual C++. Might not work, since >Visual C++ somehow caches the enviroment variables sometimes, so I >have to REBOOT! (Windows is funny, isn't it :). > > It could be the OS itself: the DLLs might stay in memory, but I agree: only via different names can you make sure that the correct version (that is: the version you intended) is loaded. Windows does not have the convenience of soft links that will pick out the right actual library. >I know, that in Linux it's not a problem, and I use different versions >of plplot in different install directories already, but even here - I >could set the LD_LIBRARY_PATH to both or all install directories and I >wouldn't need to reset them or start a new terminal (this is now what >I do e.g. for the several wxwidgets installations). > >So, I don't propose that changing the library name should be common >use, but there are cases, where I believe that this is the only >convenient way to work with several versions of the library and the >configuration should provide a way to enable this. > >What do you think? > > Let us hope it is not going to be a habit indeed :), but I can sympathise with the use cases you have brought up. Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2008-02-08 17:35:37
|
On 2008-02-08 08:03+0100 Werner Smekal wrote: >>> > Hi Alan, > >> >> Could you please revert the change for now and do it after the >> release? I >> think your implementation will not introduce any nasty build-system >> bugs, >> but my instinct says we should have a longer testing period to make >> sure. > > Sure, done. Thanks, Werner. Please bring up this issue again after the release if I forget to do it myself. 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...> - 2008-02-14 00:55:34
|
On 2008-02-08 09:34-0800 Alan W. Irwin wrote: > Thanks, Werner. Please bring up this issue again after the release if I > forget to do it myself. Hi Werner: Since nobody argued against this and you argued well for it, I have just reinstated your change. I wanted to delay this until after the release because I was concerned about the implementation; CMake handles -DLIB_TAG:STRING=whatever differently than -DLIB_TAG=whatever. (It puts the typed version in the cache and just sets an ordinary variable when it is not typed.) However, some simple tests I have done seem to indicate that your implementation with the simple set(LIB_TAG "${LIB_TAG}d") does the right thing whether the -D option is typed or not (probably because this set command only sets the ordinary CMake variable and not the cached version). The handling of untyped -D options will be changed for CMake 2.6.x (I think they will be put into the cache just like typed variables) so we may have to revisit this, but the implementation should be fine for now and should give the same results for untyped and typed setting of LIB_TAG with a -D 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: Werner S. <sm...@ia...> - 2008-02-16 20:42:47
|
Hi Alan, thanks for the change. I consider it quite helpful (at least for my daily work :). And I don't expect any problems for anybody else. Regards, Werner Alan W. Irwin wrote: > On 2008-02-08 09:34-0800 Alan W. Irwin wrote: > >> Thanks, Werner. Please bring up this issue again after the release if I >> forget to do it myself. > > Hi Werner: > > Since nobody argued against this and you argued well for it, I have just > reinstated your change. > > I wanted to delay this until after the release because I was concerned about > the implementation; CMake handles -DLIB_TAG:STRING=whatever differently > than -DLIB_TAG=whatever. (It puts the typed version in the cache and just > sets an ordinary variable when it is not typed.) However, some simple tests > I have done seem to indicate that your implementation with the simple > > set(LIB_TAG "${LIB_TAG}d") > > does the right thing whether the -D option is typed or not (probably because > this set command only sets the ordinary CMake variable and not the cached > version). > > The handling of untyped -D options will be changed for CMake 2.6.x (I think > they will be put into the cache just like typed variables) so we may have to > revisit this, but the implementation should be fine for now and should give > the same results for untyped and typed setting of LIB_TAG with a -D > 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 > __________________________ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > 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 |