[jruby-user] How to build from source?

[Mikhail T.]

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!

[Theo Hultberg]

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#

Post by Mikhail T.
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!
--
Posted via http://www.ruby-forum.com/.
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

[christian]

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.

[Mikhail T.]

Post by christian
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).

Post by christian
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]

yes, the tar,gz and zip have identical content ;)

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.

[Mikhail T.]

Post by christian
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!

[Ariel Valentin]

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.

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#

Post by Mikhail T.
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!
--
Posted via http://www.ruby-forum.com/.
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

[Charles Duffy]

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.

Post by Theo Hultberg
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#

Post by Mikhail T.
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!
--
Posted via http://www.ruby-forum.com/.
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

[christian]

hi Mikhail,

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

[Mikhail T.]

Post by christian
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.