On 01/11/2013 12:03 AM, Alan W. Irwin wrote:
> 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.
I would advocate a separated solution. Looking at my Fedora 18 package
(5.9.9-12.svn12202.fc18) there are 34 files that are checked for in
export_plplot-noconfig.cmake. They are each in the various packages as
listed below. I suspect that debian is organized similarly (if not, it
might be a good time to align them better). It is unlikely that a
project will use more than a couple different language interfaces and
the drivers are almost all together in plplot-libs, so there really
wouldn't need to be many different cmake export names.
Also if any of these files are going to be used for things other than
the plplot examples, they should go in /usr/share/cmake/plplot.
Otherwise as noted in the bug I might just hack the error into a warning
and let the people who need the specific packages for building require them.
/usr/lib/libcsirocsa.so.0.0.1
/usr/lib/libcsironn.so.0.0.1
/usr/lib/libqsastime.so.0.0.1
/usr/lib/libplplotd.so.11.0.0
/usr/lib/libplplotcxxd.so.10.0.0
/usr/lib/libplplotf95cd.so.9.1.1
/usr/lib/libplplotf95d.so.9.1.1
/usr/lib/plplot5.9.9/driversd/cairo.so
/usr/lib/plplot5.9.9/driversd/mem.so
/usr/lib/plplot5.9.9/driversd/ntk.so
/usr/lib/plplot5.9.9/driversd/null.so
/usr/lib/plplot5.9.9/driversd/ps.so
/usr/lib/plplot5.9.9/driversd/pstex.so
/usr/lib/plplot5.9.9/driversd/psttf.so
/usr/lib/plplot5.9.9/driversd/svg.so
/usr/lib/plplot5.9.9/driversd/xfig.so
/usr/lib/plplot5.9.9/driversd/xwin.so
plplot-libs-0:5.9.9-12.svn12202.fc18.i686
/usr/lib/python2.7/site-packages/_plplotcmodule.so
plplot-0:5.9.9-12.svn12202.fc18.i686 (plplot depends on plplot-libs so
this would be lumped in above)
/usr/lib/libtclmatrixd.so.9.2.0
/usr/lib/libplplottcltkd.so.9.2.0
/usr/bin/plserver
/usr/lib/python2.7/site-packages/plplot_widgetmodule.so
/usr/lib/plplot5.9.9/driversd/tk.so
/usr/lib/plplot5.9.9/driversd/tkwin.so
/usr/bin/pltcl
plplot-tk-0:5.9.9-12.svn12202.fc18.i686
/usr/lib/octave/site/oct/i686-redhat-linux-gnu/plplot_octave.oct
plplot-octave-0:5.9.9-12.svn12202.fc18.i686
/usr/lib/libplplotwxwidgetsd.so.0.0.0
/usr/lib/plplot5.9.9/driversd/wxwidgets.so
plplot-wxGTK-0:5.9.9-12.svn12202.fc18.i686
/usr/lib/libplplotadad.so.0.0.0
plplot-ada-0:5.9.9-12.svn12202.fc18.i686
/usr/lib/lua/5.1/plplot/plplotluac.so
plplot-lua-0:5.9.9-12.svn12202.fc18.i686
/usr/lib/libplplotqtd.so.0.0.1
/usr/lib/plplot5.9.9/driversd/qt.so
plplot-qt-0:5.9.9-12.svn12202.fc18.i686
/usr/lib/python2.7/site-packages/plplot_pyqt4.so
plplot-pyqt-0:5.9.9-12.svn12202.fc18.i686
/usr/lib/libplf95demolibd.a
plplot-fortran-devel-0:5.9.9-12.svn12202.fc18.i686
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane [email protected]
Boulder, CO 80301 http://www.cora.nwra.com
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 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_122912
_______________________________________________
Plplot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/plplot-devel
