Hi Alan
The reason I would prefer to use the LIB_TAG variable is really only neatness. This would mean I could have all my libraries (Plplot and others) in a single directory, as happens on Linux. I would have thought this would have been better for Linux users who would want there libraries in \usr\local\lib or perhaps \usr\local\lib64. So their install prefix will always be \usr\local, regardless of the build type.
If, however, you have reasons to not want to allow this then that is fine.

If you are interested on a user's thoughts on the d suffix, then I agree with you. Even though I know why it is there I have still found myself chasing my tail with link errors because at first glance I thought I had the debug version. However, I think it is still worth differentiating the builds to help users with possible link error diagnoses if they link to the wrong library. Given that most users use the double version then maybe using f for float versions would be better. However for me having no double/float distinguisher would be better than having a confusing d suffix.

From: Alan W. Irwin
Sent: ‎24/‎01/‎2014 04:01
To: Phil Rosenberg; Andrew Ross; Orion Poplawski
Cc: plplot-devel@lists.sourceforge.net
Subject: Re: [Plplot-devel] Qsatime suffix

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

> 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 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