aboutsummaryrefslogtreecommitdiffstats
path: root/meta-xfce/recipes-apps
diff options
context:
space:
mode:
authorMark Asselstine <mark.asselstine@windriver.com>2014-09-05 11:07:13 -0400
committerMartin Jansa <Martin.Jansa@gmail.com>2014-09-26 05:42:52 +0200
commit8c2e27e68642224df084eed14c2ad1de4f1bb0a5 (patch)
tree4a8d1aaceac36d1cfb6f93242eae6826ab0a809d /meta-xfce/recipes-apps
parented698c4dba606b9d0c36c68023004046417db251 (diff)
downloadmeta-openembedded-contrib-8c2e27e68642224df084eed14c2ad1de4f1bb0a5.tar.gz
ruby.bbclass: introduce a class to assist in building gems
In order to allow the building of gems we have created a ruby.bbclass. The building of gems is much like the building of python packages in that we rely on building up -native gems in order to facilitate the cross compiling of the gems that will be built for the target. When dependencies exist between gems they must be satisfied by the -native gems installed in the host sysroot. This approach is feasible since the build process is able to query installed gems without being affected by the ARCH they were built for. At this point I have yet to come across a situation where the assumption associated with this approach have failed but so far focus has only been on x86 and x86-64 builds. The recipes which inherit the ruby.bbclass can optionally define a BPV in the case where the gemspec version doesn't always map 1:1 to the PV. This situation has only been encountered on a few occasions so the class has been made to default BPV to PV. To demonstrate the ruby.bbclass in use we have included a recipe to build the bundler gem. Bundler can be used on a running target to install gems from rubygems.org, which can be useful in itself when you don't have recipes available for gems but want to try installing and running pre-built gems. Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Diffstat (limited to 'meta-xfce/recipes-apps')
0 files changed, 0 insertions, 0 deletions