PLplot

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
__________________________

>>
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: smekal@...
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

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

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
__________________________

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
__________________________

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
> Plplot-devel@...
> 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: smekal@...
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