On 2014-01-23 20:15-0000 Phil Rosenberg wrote: > Hi Alan and others
> We discussed this some time ago, but i don't know if any conclusions were reached. Would it be possible to add the same suffix to qsatime and the other libraries generated by Plplot as well as to the core libraries? This has just been brought to my attention again because I'm trying to tidy up my libraries because it's a bit more difficult to add library directories to projects in vc++ 2012, compared to 2008 and so I would like all my Plplot libraries in one directory with different suffixes for debug vs release and 32 vs 64 bit. I was also thinking about static and dll. This gives 8 versions. Unfortunately the libraries without suffixes overwrite each other, so i have to change the filenames manually. I'm sure i can't be the only one that builds multiple versions of the libraries for which this would be useful. > If it's at all possible it would be very useful to me. Just to give some background, the LIB_TAG suffix of "" or "d" is currently appended by our build system to LIB_TAG specified by the user. The value of what is appended depends on whether the PLFLT variable used in the library is actually a float or a double. (It is usually a double so the trailing "d" is almost always part of most of our library names now.) Of course, some of our libraries (such as qsastime) have no variables typed PLFLT at all so they don't have a LIB_TAG assigned for them. (If they did, they would receive a "d" suffix for the common case when PLFLT was double which would make no sense at all.) In my opinion, we should not allow users to set LIB_TAG (before the build system appends to it) since it allows users to rename a subset of our libraries in arbitrary ways that can be quite confusing to everybody else. If we made that change, where would that leave users with Phil's needs who do a number of different builds with varying conditions that typically affect all libraries (not just the subset that currently have LIB_TAG appended)? I suggest such users should take advantage of the cmake option -DCMAKE_INSTALL_PREFIX:PATH=<prefix> to install the various kinds of builds in different locations. To illustrate the differences between the two approaches, let's take a typical Windows case where the Windows dll's are installed in <prefix>/bin where <prefix> is specified by the user as above. For the current case, only one prefix is used, and a user like Phil with various kinds of builds installs <prefix>/bin/libplplot<kind1>d.dll, <prefix>/bin/libplplot<kind2>d.dll, ..., and <prefix>/bin/libqsastime.dll where kind =kind1, kind2, etc., takes on various string values he as assigned via LIB_TAG corresponding to various kinds of builds and "d" is appended to LIB_TAG by our build system because PLFLT is normally a double. But he cannot fiddle with the qsastime suffix because LIB_TAG does not apply in that case for the reason mentioned above. So allowing the user to fiddle with LIB_TAG creates a mess with libqsastime.dll (and other installed files that might differ from one kind of build to another) being overwritten by whatever kind of build he does last. My simple and clean alternative suggestion is our build system would no longer allow the user to set LIB_TAG (although for this minimal change it would still be set to "" or "d" as before by our build system depending on the type of PLFLT.) Instead, users would install <prefix_kind1>/bin/libplplotd.dll, <prefix_kind1>/bin/libqsastime.dll <prefix_kind2>/bin/libplplotd.dll, <prefix_kind2>/bin/libqsastime.dll, ... instead. The user achieves that specifying prefix_kind1, prefix_kind2, etc., via CMAKE_INSTALL_PREFIX for each different kind of build that he wants to do. @Phil: Please give the CMAKE_INSTALL_PREFIX method a try to make sure it works as I have outlined. Is there any reason (other than the pain of the changeover) why you could not change to that method of cleanly distinguishing your various kinds of builds/installs? If there are no strong objections from Phil or anyone else to this minimal LIB_TAG change, then I propose it be done at the start of the next release cycle. @Everybody. One possibility beyond the minimal change discussed above is to drop LIB_TAG completely so the above dll name would be libplplot.dll regardless of the type of PLFLT). This is a separate issue from the above issue, but I thought I should bring it up because I think it is a good idea. Of course, if we do decide to completely remove LIB_TAG that does effectively rename our core library from libplplotd to libplplot. Such a change is not without practical pain (especially for distro packagers like Orion and Andrew) and also (slightly) interferes with user identification of our libraries, but I think it is worth it just to reduce potential user confusion about whether we have a debug release or not. (The "d" suffix on our library name is usually misinterpreted by our users that way according to most comments I have read.) If we do decide to completly remove LIB_TAG, it would be right after the 5.10.0 release on October 1st to assure a complete release cycle to test the change, and a prominent warning notice of the library name changes in the announcement of the next release after 5.10.0 would be appropriate as well. I would also want to directly contact software developer groups that depend on PLplot such as rhe QSAS software team to make sure they are not blind-sided by these backwards-incompatible changes to our library names. @Orion and Andrew: I am especially interested in your comments on the implications of effectively dropping the "d" suffix for most of our distributed library names. 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); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); 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 __________________________ ------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
