On 2013-01-10 21:02-0700 Orion Poplawski wrote:
> In Fedora we package up plplot into lots of sub-packages for the
> different interfaces. However this appears to be causing problems for
> users of the export_plplot cmake module because it wants to be able to
> find all of the plplot modules, even if they are not needed for the project.
>
> I know very little about the expected ways to use cmake to find and use
> plplot. Perhaps this isn't even the way one is supposed to do it.
>
> What is needed from a packaging perspective is a way for users of plplot
> to specify which interface(s) they want and only load/check for those.
> Is this currently available?
>
> Thoughts/comments? Thanks!
To Orion and Andrew:
It's a small world! I was unaware of this issue until now, but David
Howells, the author of this bug report is collaborating with me on
ephcom and te_gen development, and te_gen needs PLplot for the subset of its
tests
that make residual plots. He probably decided to bother you with this
rather than me because I am in the last day or so of releases for
ephcom and te_gen. However, I wouldn't mind a break, and I am the
sole author of this part of the CMake build system for PLplot (which David is
probably unware of) so I will take the time to answer this in detail.
(I have included David in the cc list, but, David, if your reply
includes the plplot-devel mailing list address, your reply will
just bounce since I don't think you are subscribed.)
Every PLplot library and shared object exports its CMake data via one
set of export files for all of Plplot. The generic name of that set
is "export_plplot". So to look closer at what is going on, look for
"export_plplot" in the PLplot source tree with a bit of context included in
the grep. Here are those results:
----------------
software@raven> find . -type f |grep -v svn |xargs grep -B1 export_plplot
./lib/qsastime/CMakeLists.txt-install(TARGETS qsastime
./lib/qsastime/CMakeLists.txt: EXPORT export_plplot
--
./lib/nistcd/CMakeLists.txt- install(TARGETS nistcd
./lib/nistcd/CMakeLists.txt: EXPORT export_plplot
--
./lib/nn/CMakeLists.txt- install(TARGETS csironn
./lib/nn/CMakeLists.txt: EXPORT export_plplot
--
./lib/csa/CMakeLists.txt- install(TARGETS csirocsa
./lib/csa/CMakeLists.txt: EXPORT export_plplot
--
./bindings/tk/CMakeLists.txt- install(TARGETS plserver
./bindings/tk/CMakeLists.txt: EXPORT export_plplot
--
./bindings/c++/CMakeLists.txt- install(TARGETS plplotcxx${LIB_TAG}
./bindings/c++/CMakeLists.txt: EXPORT export_plplot
--
./bindings/octave/CMakeLists.txt- install(TARGETS plplot_octave
./bindings/octave/CMakeLists.txt: EXPORT export_plplot
--
./bindings/qt_gui/pyqt4/CMakeLists.txt- TARGETS plplot_pyqt4
./bindings/qt_gui/pyqt4/CMakeLists.txt: EXPORT export_plplot
--
./bindings/qt_gui/CMakeLists.txt- install(TARGETS plplotqt${LIB_TAG}
./bindings/qt_gui/CMakeLists.txt: EXPORT export_plplot
--
./bindings/f77/CMakeLists.txt- install(TARGETS plplotf77c${LIB_TAG}
./bindings/f77/CMakeLists.txt: EXPORT export_plplot
--
./bindings/f77/CMakeLists.txt- install(TARGETS plplotf77${LIB_TAG}
./bindings/f77/CMakeLists.txt: EXPORT export_plplot
--
./bindings/tcl/CMakeLists.txt-install(TARGETS tclmatrix${LIB_TAG}
./bindings/tcl/CMakeLists.txt:EXPORT export_plplot
--
./bindings/tcl/CMakeLists.txt-install(TARGETS plplottcltk${LIB_TAG}
./bindings/tcl/CMakeLists.txt:EXPORT export_plplot
--
./bindings/python/CMakeLists.txt- TARGETS plplot_widgetmodule _plplotcmodule
./bindings/python/CMakeLists.txt: EXPORT export_plplot
--
./bindings/wxwidgets/CMakeLists.txt- install(TARGETS plplotwxwidgets${LIB_TAG}
./bindings/wxwidgets/CMakeLists.txt: EXPORT export_plplot
--
./bindings/ada/CMakeLists.txt- install(TARGETS plplotada${LIB_TAG}
./bindings/ada/CMakeLists.txt: EXPORT export_plplot
--
./bindings/lua/CMakeLists.txt- install(TARGETS plplotluac
./bindings/lua/CMakeLists.txt: EXPORT export_plplot
--
./bindings/d/CMakeLists.txt- install(TARGETS plplotdmd${LIB_TAG}
./bindings/d/CMakeLists.txt: EXPORT export_plplot
--
./bindings/gnome2/lib/CMakeLists.txt- install(TARGETS plplotgnome2${LIB_TAG}
./bindings/gnome2/lib/CMakeLists.txt: EXPORT export_plplot
--
./bindings/gnome2/python/CMakeLists.txt- TARGETS gcwmodule
./bindings/gnome2/python/CMakeLists.txt: EXPORT export_plplot
--
./bindings/gnome2/python/CMakeLists.txt- TARGETS cplplotcanvasmodule
./bindings/gnome2/python/CMakeLists.txt: EXPORT export_plplot
--
./bindings/f95/CMakeLists.txt- install(TARGETS plplotf95c${LIB_TAG}
./bindings/f95/CMakeLists.txt: EXPORT export_plplot
--
./bindings/f95/CMakeLists.txt- install(TARGETS plplotf95${LIB_TAG}
./bindings/f95/CMakeLists.txt: EXPORT export_plplot
--
./drivers/CMakeLists.txt- install(TARGETS ${SOURCE_ROOT_NAME}
./drivers/CMakeLists.txt: EXPORT export_plplot
--
./src/CMakeLists.txt-install(TARGETS plplot${LIB_TAG}
./src/CMakeLists.txt: EXPORT export_plplot
--
./src/CMakeLists.txt-# This exports information for every target in the whole
build that
./src/CMakeLists.txt:# has the EXPORT export_plplot signature (as above) for
the
./src/CMakeLists.txt-# install(TARGETS ... # command.
./src/CMakeLists.txt:install(EXPORT export_plplot DESTINATION
${DATA_DIR}/examples/cmake/modules)
--
./debian/patches/04_use-mkoctfile.diff-- install(TARGETS plplot_octave
./debian/patches/04_use-mkoctfile.diff:- EXPORT export_plplot
--
./debian/patches/08_nn_link_libm.diff- install(TARGETS csironn
./debian/patches/08_nn_link_libm.diff: EXPORT export_plplot
--
./utils/CMakeLists.txt- install(TARGETS pltcl
./utils/CMakeLists.txt: EXPORT export_plplot
--
./examples/CMakeLists.txt-
./examples/CMakeLists.txt: include(export_plplot)
--
./examples/f95/CMakeLists.txt- install(TARGETS plf95demolib${LIB_TAG}
./examples/f95/CMakeLists.txt: EXPORT export_plplot
----------------
Note the three different signatures above. The
install(EXPORT export_plplot ... )
signature that only occurs once establishes one export
context for PLplot with the name export_plplot. The many
install(TARGETS ... EXPORT export_plplot ...)
adds one component per each of the ~25 libraries/shared objects to that
context, and
finally the
include(export_plplot)
signature may be used by any external build system (in this
case it is the separate build system for the installed PLplot
libraries, drivers, and examples) to import that target information
for all the above targets back into the external build system. (Note
the build system for te_gen also uses the "include(export_plplot)"
command to gain access to all this PLplot target information for
te_gen.)
So far so good, but what the above logic means is all these PLplot target
results are collected into one export_plplot context and integrated
together into the two corresponding PLplot module files for that
context called export_plplot-noconfig.cmake and export_plplot.cmake
that are installed in
$prefix/share/plplot5.9.9/examples/cmake/modules.
That means the proper downstream Fedora packaging solution for the
above upstream PLplot
situation that pertains now is to package those two files in their own
"export_plplot" rpm which in turn depends on every other PLplot rpm.
That should supply a complete packaging fix for David's bug report but
also means there are going to be a lot of dependencies for the
"export_plplot" rpm and also for the te_gen rpm.
If you dislike that solution for the bug, then an alternative to consider is to
change the PLplot build system such that each of the ~25
install(TARGETS ... EXPORT <export_name> ...)
commands listed above has a unique export_name. But in that case, there would
have to be
~25 separate corresponding
install(EXPORT <export_name> ...)
commands implemented which would generate ~25 two-file sets which
contained the relevant export information for each separate target
and which would be put in the appropriate rpm where that export
information is needed by external projects.
To import that information back into some external project
would require up to ~25
include(<export_name>)
commands. For example, probably all ~25 such commands would be
required for the installed examples build system for PLplot since that
uses essentially all library/shared object targets mentioned above,
but considerably less than that would be needed for the te_gen build
system since that only uses the PLplot core library, the Python
bindings for that library and the ps device driver.
Note I have over-simplified the split approach above by having a
separate <export_name> per target. Obviously you would still want to
group the export sets a bit such as all the libplplot dependent
libraries in one set of exports, etc. And that probably would reduce
the number of include statements required for te_gen down to two or
three which isn't too onerous.
I urge Andrew to weigh in here as well since unless he has fixed it
already there must be a similar dependency issue for the Debian
packages that he maintains.
Personally, I lean toward the current integrated "export_plplot"
solution where the only changes would be to Fedora packaging to create
one "export_plplot" rpm that contains the two files and which depends
on every other PLplot rpm. (And similarly for Debian if Andrew hasn't
already dealt with this dependency issue for the two files containing
the current integrated export_plplot information.) However, if you and
Andrew lean more toward a "separated" solution, I would be willing to
go along although I would request one/both of you to do the required
upstream work on the PLplot build system along the lines I suggested
above.
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
__________________________
------------------------------------------------------------------------------
Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
much more. Get web development skills now with LearnDevNow -
350+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122812
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
