How to build from source?

Hello! I’d like to build as comprehensive a package of JRuby as
possible. It looks like builds are handled as Maven goals (with
different profiles).

The bundled BUILDING.md seems aimed more at the developers, rather than
packagers like myself – ultimately, I need to create an RPM for CentOS.

What combination(s) of goals and profiles should I use to build
(%build), test (%check), and install (%install) JRuby?

Thank you!

Do you really need to build from source? You can package the binaries in
your RPM and they will run on any supported OS that has a JVM, without
recompilation. The install will be orders of magnitude faster and much
less
error prone.

T#

mvn -Pdist

will build the same distribution files you can find on jruby.org for
downloading. the result are stored in maven/jruby-dist/target

if you want to “pick” just jruby from the current source tree, just use

mvn

which basically sets up lib/* in way that you can use jruby from that
very
file location like

bin/jruby

after that you might want to in jruby-launcher gem

bin/jruby -S gem install jruby-launcher

which gives you a faster startup for jruby command line execution.

At our company we use RPM and used to build from source. I found it much
easier to use ruby-install then package results from /opt/rubies as well
as /etc/environment changes as opposed to requiring all of the build
time dependencies.

Thanks,
Ariel

Sent from my mobile device. Please excuse any errors.

Howdy, Theo –

A quick note about RPM. The preferred workflow is to compile from source
at package build time; this does not impact installation-time
performance.

Using this workflow allows RPMs to have patches applied; to track
metadata
on those patches, and to allow the end-user to see exactly what source,
and
exactly which patches, went into what they’re installing.

hi Mikhail,

I am happy to improve the jruby build process to be more suitable for
packager !

christian wrote in post #1151838:

mvn -Pdist

will build the same distribution files you can find on jruby.org for
downloading. the result are stored in maven/jruby-dist/target

The above created .tar.gz and .zip files, indeed, but without many of
the gems inside them (though .bat-files found their way into .tar.gz)…

By running “mvn -Pcomplete package” and then simply packaging the bin/
and lib/ subdirectories, I get thins like htmldiff and rspec, as well as
some gems (like krypt).

after that you might want to in jruby-launcher gem

bin/jruby -S gem install jruby-launcher

which gives you a faster startup for jruby command line execution.

Yes, after running this I gained the
lib/ruby/gems/shared/gems/jruby-launcher-1.1.0-java/ subdirectories.
And jruby-launcher-1.0.19…

I’ll be packaging all other gems separately – we already do that for
the native Ruby. Thank you!

christian wrote in post #1151869:

hi Mikhail,

I am happy to improve the jruby build process to be more suitable for
packager !

Thank you, Christian! The typical build-steps used during packaging
(whether in a FreeBSD’s port-build or when creating a Linux RPM, etc.)
are:

  • config – which lets the packager turn various optional parts of the
    software on and off
  • download – which (which rpmbuild does not handle, actually, but
    others do)
  • extract sources
  • patch sources (with rpmbuild extraction and patching are the same
    step: %prep)
  • configure
  • build (rpmbuild combines configure and build into a single %build
    step)
  • test (what FreeBSD ports call “regression-test” and rpmbuild refers
    to as %check)
  • package or install

Having a command (an mvn goal, make or ant target) for each of these
steps would be ideal. The commands should not overlap – for example,
the build should not perform tests and the test should not rerun the
entire build (although it is Ok for it to ensure, the build succeeded).
It should be possible to communicate the options, if any, specified by
the user in the first step of the process, via either command-line flags
(such as -Pfoo) or environment variables.

Another wish is for the package-building to be self-contained:
currently, I’m fighting maven’s attempts to download files into the
packager’s home directory by giving it a a custom settings.xml. But
that’s of secondary importance, because work-arounds exist.

after that you might want to in jruby-launcher gem
bin/jruby -S gem install jruby-launcher
which gives you a faster startup for jruby command line execution.

Can this be run after mvn -Pdist – but before packaging up the results?
Thanks!

yes, the tar,gz and zip have identical content :wink:

if you just run
mvn clean package
that is enough to setup the lib directory.

the rspec gem and htmldiff gem comes from
mvn -Pbootstrap
and they will NOT be cleaned with mvn clean !

but a fresh clone and not using that bootstrap will keep the
lib/ruby/gems/shared/gems
empty !

jruby currently has 8 default gems, i.e. their specifications will be
in lib/ruby/gems/shared/specifications/default
and the content of those gems is basically copied into
lib/ruby/gems/shared

those gems will be downloaded by maven from
http://rubygems-proxy.torquebox.org/releases

these default gems are part of jruby-complete, jruby-stdlib and
jruby-dist
and they are needed for jruby itself.

christian wrote in post #1151838:

after that you might want to in jruby-launcher gem

 bin/jruby -S gem install jruby-launcher

which gives you a faster startup for jruby command line execution.

I did that, but the script consisting of nothing but “puts ‘Hellow
world’” still takes 6 seconds (and plenty of io) to execute:

% time jruby /tmp/hello.rb
Hello world
7.753u 0.777s 0:05.91 144.1% 0+0k 96+80io 0pf+0w

This is on RHEL6 with Oracle’s JDK 1.7.0_55.

For comparison, with regular ruby the time is 1 hundredth of a second:
% time ruby /tmp/hello.rb
Hello world
0.007u 0.005s 0:00.01 0.0% 0+0k 0+0io 0pf+0w

I understand, that Java programs do carry the start-up penalty… But I
didn’t realize, it is SO big. Am I benefiting from having jruby-launcher
at all – or do I need to do something else for faster start-ups?
Thanks!

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs