On 11 January 2011 15:59, Bollinger, John C <john.bollin...@stjude.org> wrote: > > On Saturday, January 08, 2011 1:59 PM, Noel O'Boyle wrote: >>On 6 January 2011 22:30, Bollinger, John C <john.bollin...@stjude.org> wrote: >>> Hello All, >>> >>> Today I have been looking into DESTDIR usage for the other language >>> bindings supported by OpenBabel. I am reporting my findings for discussion >>> here before filing any more bug reports on the topic: >>> >>> 2) Ruby -- The mkmf-generated Makefile for the Ruby binding supports >>> DESTDIR, but OpenBabel's installation rules have coopted it for their own >>> purposes. The rules as written don't achieve the result described in the >>> installation docs, however. To get that, the generation of the Makefile >>> needs to be managed. That is, the install location needs to be configured >>> into the generated Makefile. If that were done then DESTDIR would be >>> available for its conventional purpose, and the rules for the Ruby bindings >>> would then also be more consistent with those for the Perl and Python >>> bindings. >> >>I've added support for DESTDIR for the Ruby bindings. >> >>Unfortunately, mkmf doesn't seem to support any mechanism for >>specifying --prefix (and believe me, I tried a few - I also note that >>someone has started a mkmf2 project because of these and other >>shortcomings) so we still need to continue co-opting DESTDIR for this >>purpose. In any case, the previous behaviour is maintained and now it >>also supports DESTDIR. > > Thank you, I appreciate that. > > I agree that mkmf has no concept of installing a ruby extension anywhere > other than under the Ruby sitearch directory (for example, under > /usr/lib/ruby/site_ruby/1.8/ on one of my systems). While we wait on mkmf2, > then, perhaps it would be appropriate to note this distinction in the > installation docs, which currently state: "For Ruby [...] the library files > are installed to a subdirectory of wherever the Open Babel libraries are > installed: something like [...] site_ruby/1.8/linux-i486 [...]." > Unfortunately, that often will not be true by default; in fact, with Ruby > installed under /usr instead of under /usr/local, I don't think there is any > combination of variables that currently can make it true. > > That's in part because those docs are also misleading about the effect of the > RUBY_PREFIX and CMAKE_INSTALL_PREFIX variables on the Ruby bindings. Based > on the docs, I would expect that specifying RUBY_PREFIX=/usr/lib would result > in the bindings going somewhere under /usr/lib/site_ruby/1.8, but it appears > that instead that would put them under something like > /usr/lib/usr/lib/site_ruby/1.8 (note the repetition of /usr/lib). Also, if I > omitted RUBY_PREFIX but specified CMAKE_INSTALL_PREFIX=/usr/local then the > extension would end up somewhere under /usr/lib/site_ruby/1.8 (no local/) on > many of my machines, and if I specified CMAKE_INSTALL_PREFIX=/usr then it > would end up under something like /usr/usr/lib/site_ruby/1.8 (note the extra > usr/). What a mess! > > If you want installation of the Ruby extension to conform to the current > docs, then either the mkmf-generated Makefile needs to be manipulated > post-creation, or its "install" target needs to be ignored in favor of > (presumably) a direct CMake install rule. I am investigating the feasibility > of the latter. I hope to be able to provide the documented installation > behavior, as well as getting DESTDIR support from cmake for free. If I > succeed then I will offer a patch for your consideration.
That'd be great. If you go down the former route, I have some code written to allow the PREFIX to be passed in (without upsetting the makefile generator) if it's useful: http://gist.github.com/771081 > > Cheers, > > John > > -- > John C. Bollinger, Ph.D. > Department of Structural Biology > St. Jude Children's Research Hospital > > > > > Email Disclaimer: www.stjude.org/emaildisclaimer > > ------------------------------------------------------------------------------ Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ OpenBabel-Devel mailing list OpenBabel-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openbabel-devel
