FindRuby.cmake

Marcus D. Hanwell marcus.hanwell at kitware.com
Thu Mar 10 20:15:33 CET 2011


On Wed, Mar 9, 2011 at 3:40 PM, Alexander Neundorf <neundorf at kde.org> wrote:
> Hi Michael,
>
> On Monday 07 March 2011, Michael Jansen wrote:
>> Ruby has three different installation areas for libraries. Each
>> installation area has two different subdirectories (sort of). One is for
>> architecure independent files. One is for architecture dependent files.
>>
>> 1. Installation Area: Ruby Library Directory
>>
>>         rubylibdir  /usr/lib64/ruby/1.8
>>            archdir  /usr/lib64/ruby/1.8/x86_64-linux
>>
>> This area is reserved for the ruby standard library (http://www.ruby-
>> doc.org/stdlib/). No other software is supposed to be installed into this
>> directory. It makes no sense for the cmake file to determine and provide
>> the path and location of this area. You don't want to install stuff there
>> and you don't need to get stuff from there. (The libruby.so is somewhere
>> else)
>>
>> 2. Installation Area: Vendor
>>
>>            vendordir  /usr/lib64/ruby/vendor_ruby
>>         vendorlibdir  /usr/lib64/ruby/vendor_ruby/1.8
>>        vendorarchdir  /usr/lib64/ruby/vendor_ruby/1.8/x86_64-linux
>>
>> This area is intended to be used by distributions. They install the
>> libraries provided by distribution packages into that area. You are
>> supposed to install into that area if you build distro packages. It
>> therefore makes sense to determine and provide this area from
>> FindRuby.cmake
>>
>> 3. Installation Area: Site
>>
>> This area is intended to be used for self compiled and installed ruby
>> packages. This is the most likely installation area for a ruby extension.
>>
>> 4. Installation Area: Custom
>>
>> In Addition to those 3 areas it is possible to install ruby extensions into
>> custom directories and add their path to ruby $LOAD_PATH global array. Each
>> directory has to be added explicitly. There is no automatic archdir
>> handling.
>>
>>     a) $LOAD_PATH << "<custom_ruby_libdir>" << "<custom_ruby_archdir>"
>>     b) ruby -I<path1> -I<path2>
>>     c) Environment Variable RUBY_LIB and/or DLN_LIBRARY_PATH
>>
>> The current FindRuby.cmake determines the location of the areas 1, 2 ( if
>> it exists) and 3. It does not advise or support chosing any installation
>
> Do you mean the FindRuby.cmake shipped with cmake, the FindRUBY.cmake in
> kdelibs, or another one ?
>
>> prefix to use. The ruby bindings use the simplest way and just install into
>> the site area unless someone specifies a different path. Which is annoying
>> if CMAKE_INSTALL_PREFIX is not the same as the ruby install prefix. But it
>> is annoying too if you have to manually construct the correct path to one
>> of the installation areas just to install your stuff into the ruby prefix.
>> The ruby version and rubyarch are not obvious from the outside for both use
>> cases.
>>
>> The features i would like to implement are:
>>
>> Provide two variables named
>>     RUBY_INSTALL_LIBDIR
>>     RUBY_INSTALL_ARCHDIR
>>
>> First rule wins:
>>
>> 1. If option RUBY_(USE_?)INSTALL_AREA is set to "site"
>
> I guess this is intended to be a cache variable, so it can be set by the
> person who builds the package ?
>
>>     RUBY_INSTALL_LIBDIR  = ${RUBY_SITELIB_DIR}
>>     RUBY_INSTALL_ARCHDIR = ${RUBY_SITEARCH_DIR}
>>
>> 2. If option RUBY_INSTALL_AREA is set to "vendor" and a vendor install area
>> exists (if not error)
>>     RUBY_INSTALL_LIBDIR  = ${RUBY_VENDORLIB_DIR}
>>     RUBY_INSTALL_ARCHDIR = ${RUBY_VENDORARCH_DIR}
>>
>> 3. If option RUBY_INSTALL_AREA is set to something else
>>     error
>
> I'd suggest a 3rd option "auto", which has the same effect as if
> RUBY_INSTALL_AREA is not set. Then we all three valid options can be listed
> using
> set_property(CACHE RUBY_INSTALL_AREA PROPERTY STRINGS vendor;site;auto)
> once we require cmake >= 2.8.0.
> This has the effect that when using cmake-gui, the possible options are
> presented in a combo box.
>
>> 4. if CMAKE_INSTALL_PREFIX is the same as the ruby install prefix
>>     RUBY_INSTALL_LIBDIR  = ${RUBY_SITELIB_DIR}
>>     RUBY_INSTALL_ARCHDIR = ${RUBY_SITEARCH_DIR}
>>
>> 5. If CMAKE_INSTALL_PREFIX is not the same as the ruby install prefix
>> install set
>>     RUBY_INSTALL_LIBDIR  =
>> ${CMAKE_INSTALL_PREFIX}/lib${LIB_SUFFIX}/ruby/${RUBY_VERSION}
>>     RUBY_INSTALL_ARCHDIR =
>> ${CMAKE_INSTALL_PREFIX}/lib${LIB_SUFFIX}/ruby/${RUBY_VERSION}/${RUBY_ARCH}
>>     and print out a hint how to activate this area for ruby (see above)
>>
>> This solution would make it possible to have all ruby extensions support
>> this advanced functionality at once without each and everyone of them
>> trying to support (or neglecting to) it by itself.
>
> Sounds reasonable.
>
>> The question is if such a functionality is appropriate for a cmake file.
>
> If documented properly, I think it makes sense.
>
>> If we finish this i would like to add the same functionality for python
>> (PYTHON_(USE_?)INSTALL_AREA).
>
> Marcus, you are caring about the python support in cmake, right ?
> What's your opinion on this ?
>
Yes, I think this would make sense for Python too, and it seems like a
reasonable approach. This is something that is fairly common across
all scripting languages, but I have hit this with both Ruby and
Python. I could probably help get this into CMake Python.

Marcus


More information about the Kde-buildsystem mailing list