On 2015-04-24 11:52-0700 Alan W. Irwin wrote: > I assume what you are trying to do is make a fully-loaded build of > PLplot and then split up the results into a bunch of different binary > packages, but if you look at export_plplot.cmake (which generated the > above error message) you can see the problem; it loops over all PLplot > targets that were exported in the fully-loaded build of PLplot and > errors out on the targets which you have attempted to split into > separate binary components. > > Since split binary targets have been around from the early days of > rpm, I am pretty sure that CMake supports that idea when exporting > targets, but I currently don't know how to take advantage of such > CMake functionality if it exists. So I will ask a question on the > CMake list about this.
To Orion, Andrew, and all other binary packagers of PLplot: I have explored the above issue on the cmake mailing list (with subject line "What is the proper way to export targets that will be split into separate binary packages?") and got what appear to be definitive responses. It turns out to deal with this issue some substantial but reasonably straightforward changes have to be made in the way we export our targets. Clearly, those changes should be done to bring the PLplot cmake package up to modern standards. Furthermore, those changes imply there will be a separate CMake package target file for each of our ~30 targets that are exported with one overall hand-written configuration file (see src/plplotConfig.cmake which is largely just a placeholder now) to organize those individual target files into the CMake package for PLplot (most likely without any further organization into individual CMake package components). Furthermore, the CMake logic in the updated src/plplotConfig.cmake file should be able to loop through the individual target files that hapen to be installed. So once I get the CMake package for PLplot modernized in this way, I am pretty sure a binary packager's job would boil down to deciding which of the target files should be collected into the individual binary packages, and if a user decides not to install some of those binary packages, the logic in the revised src/plplotConfig.cmake should just continue to work. In sum, it appears that it will be possible to combine split binary packages and a modernized version of the CMake package for PLplot, but there will be lots of implementation work for me to do in this release cycle before we get there. 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 __________________________ ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
