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
