On January 06, 2011 3:25 AM, Marcus D. Hanwell [mailto:marcus.hanw...@kitware.com] wrote: >On Jan 6, 2011, at 4:21 AM, Noel O'Boyle wrote: > >> On 6 January 2011 09:12, Marcus D. Hanwell <marcus.hanw...@kitware.com> >> wrote: >>> On Jan 5, 2011, at 11:14 AM, Bollinger, John C wrote: >>> >>>> Hello, >>>> >>>> Per baoilleach's suggestion, I am responding to the OpenBabel dev list to >>>> request further discussion of Bug #3151502. >>>> >>>> I am attempting to build an RPM package for OpenBabel, thus I want to >>>> configure it to run from one location, but at the "make install" step I >>>> want the files actually copied to a staging area instead of to their >>>> ultimate destination. The GNU model and the CMake system both provide a >>>> DESTDIR make variable for exactly that purpose: it specifies an >>>> alternative root directory for the installation step (only), thus avoiding >>>> any build-time confusion about where files are expected to be at run time >>>> (i.e. for RPATHs, configuration files, etc.) The software is not expected >>>> to be run out of the DESTDIR-rooted area, unless possibly via chroot. >>>> >>>> Because OpenBabel's build system is based on CMake, it automatically >>>> provides for use of DESTDIR. Although DESTDIR support seems generally to >>>> work, it does not work for the Python extension, contrary to reasonable >>>> expectations of a CMake-based build system. >>>> >>>> Whether that's construed as a bug or as a missing feature, OpenBabel's >>>> build system cannot do what I need it to do. If I include the path to a >>>> staging area in CMAKE_INSTALL_PREFIX, then "make install" does place the >>>> Python files in the corresponding place, but it also includes the path to >>>> the staging area in the RPATHs encoded into OpenBabel's shared libraries. >>>> If instead I use DESTDIR in the conventional way then the RPATHs are >>>> right, but the Python components do not get installed correctly. >>>> >>>> Given that CMAKE_INSTALL_PREFIX can be manipulated to get the Python files >>>> installed in the right place, I infer that it should be straightforward to >>>> extend DESTDIR support to the Python extension. I'm not much of a CMake >>>> guy, however, so I'm a bit at a loss as to how to patch the problem. >>>> >>>> Help? >>> >>> It seems to be largely due to bypassing CMake's install command when >>> installing the bindings files. If we adjust them to use the install command >>> then they would automatically benefit from the use of install prefix, >>> DESTDIR and other install related details. >>> >>> I can look into this, and it is the way CMake is intended to be used. >>> Things like Python bindings installation locations always tend to be a >>> little more complicated though. >> >> This is indeed the reason, but please don't adjust them to use the >> install command (see previous discussions on this topic). If we need >> to add DESTDIR support (and it seems like there is a consensus that we >> do), we can do it with some more "if" statements. > >If that is how you would prefer to do it, I will leave things alone. I am not >sure I understand why you are sidestepping the mechanisms provided by CMake >that handle many of these things correctly out of the box. It seems that you >are then forced to implement existing support in several if cases in the CMake >language, possibly leading to subtle bugs.
For what it's worth, Python distutils (by which OpenBabel currently installs the extension) also supports the DESTDIR concept, but distutils spells it "--root". It may be possible to leverage that to implement DESTDIR for the Python extension with minimal changes. --root=/ should be the same as not specifying --root at all. --root=$(DESTDIR) (however that should be written for CMake) is what I need for a DESTDIR build. Alternatively, --root=$(DESTDIR)/ might also work. Thanks, John -- John C. Bollinger, Ph.D. Department of Structural Biology St. Jude Children's Research Hospital Email Disclaimer: www.stjude.org/emaildisclaimer ------------------------------------------------------------------------------ Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ OpenBabel-Devel mailing list OpenBabel-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openbabel-devel
