diff options
| author |   Mark Asselstine <mark.asselstine@windriver.com> | 2014-09-05 11:07:13 -0400 |
|---|---|---|
| committer |   Martin Jansa <Martin.Jansa@gmail.com> | 2014-09-26 05:42:52 +0200 |
| commit | 8c2e27e68642224df084eed14c2ad1de4f1bb0a5 (patch) | |
| tree | 4a8d1aaceac36d1cfb6f93242eae6826ab0a809d /meta-oe/licenses | |
| parent | ed698c4dba606b9d0c36c68023004046417db251 (diff) | |
| download | meta-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-oe/licenses')
0 files changed, 0 insertions, 0 deletions