Thanks John for explaining this. If you specify "-DPYTHON_PREFIX", it seems like this will solve the problem. Is this correct? (There is a corresponding RUBY and OBPERL prefix)
- Noel On 5 January 2011 16:14, Bollinger, John C <john.bollin...@stjude.org> 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? > > > Thanks, > > John > > > -----Original Message----- > From: SourceForge.net [mailto:nore...@sourceforge.net] > Sent: Wednesday, January 05, 2011 8:08 AM > To: nore...@sourceforge.net > Subject: [ openbabel-Bugs-3151502 ] make install ignores DESTDIR for Python > extension > > Bugs item #3151502, was opened at 2011-01-04 22:37 > Message generated for change (Comment added) made by baoilleach > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=428740&aid=3151502&group_id=40728 > > Please note that this message will contain a full copy of the comment thread, > including the initial issue submission, for this request, > not just the latest update. > Category: Installation/Building > Group: 2.3.x > Status: Open > Resolution: None > Priority: 5 > Private: No > Submitted By: John Bollinger (johnbollinger) > Assigned to: Nobody/Anonymous (nobody) > Summary: make install ignores DESTDIR for Python extension > > Initial Comment: > On CentOS 5.5 Linux I can successfully build OpenBabel 2.3.0, including the > Python bindings. I subsequently want to install to a staging area, so I then > perform, for example, > > make install DESTDIR=/tmp/openbabel > > That correctly installs the OpenBabel binaries, libraries, etc. under > /tmp/openbabel, BUT it attempts to install the Python extension directly onto > the system (in my case, into /usr/lib64/python2.4/site-packages). It should > instead install the Python extension to (in this example) > /tmp/openbabel/usr/lib64/python2.4/site-packages. > > > ---------------------------------------------------------------------- > >>Comment By: Noel O'Boyle (baoilleach) > Date: 2011-01-05 14:07 > > Message: > This is not a bug. The Open Babel install should be configured using CMake > parameters, not at the "make" stage. See the installation instructions. > > If you want to discuss this in more detail, for example if you feel that > our approach does not allow you to do something in particular, please send > an email to the dev list and people can weigh in on this. > > ---------------------------------------------------------------------- > > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=428740&aid=3151502&group_id=40728 > > > 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 > ------------------------------------------------------------------------------ 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
