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. Marcus ------------------------------------------------------------------------------ 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
