Orion Poplawski writes:
 > Orion Poplawski wrote:
 > > 
 > > Missing, presumably will come later once docs are pre-built:
 > > /usr/share/info
 > > /usr/share/man
 > > 
 > > Missing, presumably go for good with CBS?
 > > /usr/bin/plplot-config
 > > /usr/bin/plplot_libtool

Sorry to be tardy on this, had meant to respond on this when I saw it
mentioned on list a couple weeks back.  Just burried here.

Anyway, the elimination of configure and plplot-config will definitely be a
major barrier to adoption of the remade PLplot strains.  Let me explain
briefly how PLplot is integrated into our software stack at Lightspeed.  I
would not expect this to be uncommon, though obviously I can't be certain of
how other software products/projects around the world, are individually
built.

At Lightspeed, we use PLplot in our primary software product (a VLSI circuit
layout tool).  PLplot is one of nearly a dozen packages we use.  Most are
autoconf based, some are not.  We separate the world into software we write
ourselves, and software written outside our walls, which we link against.
All of this externally sourced software is bundled together into what we call
our "prefix", drawn directly from the now ubiquitous --prefix= of autoconf
fame.

Since we pay our developers to write VLSI circuit layout software, and not to
spend their time constantly fussing with their "computational environment",
we have reduced the construction of the prefix to a well-travelled process,
which is rolled out only occasional, rev'd rarely.  Many developers do not
even know (because they don't need to) exactly how this is done, they just
use the provided prefix.  Preparation of this is a function of what would be
called the "Software Integration Department" in a larger software development
organization.

The way this works is that we have a script which fetches the source bundle
for each of these externally produced software packages, unpacks it, cd's
into it, configures it against a common --prefix, builds it, installs it, and
moves on to the next.  Many packages require specific jiggering in the
conduct of the above mission, and the particularies of each are all embodied
in this prefix-construction script.

In the specific case of PLplot, we use configure, and include the use of the
"site prefix" control support that Maurice implemented so many years ago.
This allows us to capture the various configuration settings in a nonvolatile
representation which can be reused with multiple PLplot releases.  We have
used the same site prefix plugin script for roughly 4 years of Lightspeed
software dependence upon PLplot.

Then, when our end application is built, the makefiles call upon
plplot-config to produce the linkage specification for PLplot and it's
dependencies, and this string is stuffed into the final application link
line.  

Taking away configure and plplot-config means exactly one thing to
Lightspeed.  That we cannot trivially upgrade to the next PLplot release,
something we have been able to do essentially effortlessly for the last
several years.  This represents a barrier to adoption, and it means that we
will either:

a) Not adopt plplot 5.7.0 for some lengthy time, until we can free someone up
   to revisit our prefix construction procedure and our end-product
application makefiles.

b) Assign someone to do the job now, at the expense of not working on other
   recognized company work tasks.

In the specific case of Lightspeed, since we have two PLplot developers on
staff, and are critically dependent upon PLplot, I'm sure we will ultimately
update our stack with PLplot 5.7.0, but not necessarily anytime soon, due to
the opportunity cost of b).

However, given the disproportionate amount of fuss that is will cause, I am
personally 100% confident that this move will specifically irk many PLplot
end users around the world, and would expect that some users would simply not
upgrade "indefinitely", by which I mean, won't do it until they are compelled
to update or switch away, by some other compelling event down the road.

So, in summary, my position is that elimination of configure and
plplot-config, fundamentally, does not serve the customer.

What I would most prefer to see is a rewrite of configure, which continues to
take the same options it always has, including the site config file, and then
as the last step, runs cmake.  And similarly, I would like plplot-config to
continue to exist, be supported, and do what it does now.

Maurice and I have discussed this.  We both think this is a good idea.  I had
kind of hoped to be able to make the construction of such a revamped
"configure" script one of my own contributions to this cmake cutover.  But,
bottom line, due to the workload we are each bearing at Lightspeed at the
moment, I kind of doubt that either he or I will be able to do this on a
timescale relevant to the PLplot 5.7.0 release.

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel

Reply via email to