Ironruby and Gentoo Linux

Hi guys.

Im a developer/packager for Gentoo Linux [1] and I have been looking at
packaging IronRuby. Within gentoo the long-term goal would be to have
all

300 ruby packages ( could be anything from gems to applications ) supported
by IronRuby (this also includes their unit tests [2]) and to have the
ability
to set IronRuby as the system ruby implementation ( ie no cruby just
IronRuby
).

We have ways of supporting specific ruby implementations so minor
compatibility
issues wont be a problem. So don’t start worrying :slight_smile:

Hopefully you guys are interested in this as I would like to get
IronRuby into
a state where it is easy to package. This leads me onto the
following…

I noticed that within your git repository you have the Microsoft.Dynamic
and
Scripting projects. I also believe that they are replicated in the
IronPython tree but have different assembly version numbers. this is
fine by
itself but more concerned about pulling 2 version of a package from 2
different
locations.

Is there a master repository for these projects. Is it safe to package
directly them from your repository ( ie have you made any changes to
them?
would ironpython have?)

I also checked out your git repository and have noticed the some of the
Rakefiles are missing. (eg Languages/Ruby/Rakefile ). It seems that
you guys
had continuous integration for mono but that website seems to be down.

Thanks

Alistair

[1] Gentoo is a source-based linux distro, we compile everything from
source.
even things that don’t get compiled like ruby/perl are “compiled”. see
www.gentoo.org for more.

[2] From a ruby perspective the major benefit of [1] is that we can run
the
packages testsuite before we install the package. In rubys case we
could run
the testsuite against multiple implementations of ruby ( ruby18 ruby18
ree
jruby and eventually ironruby with any luck)

We are definitely interested! Please feel free to file bugs on CodePlex
(http://ironruby.codeplex.com/WorkItem/AdvancedList.aspx) whenever you
find some compatibility issue (even minor - chances are it would be easy
to fix).
IronRuby is indeed accepting contributions so you can even send us a
patch if you feel like fixing the issue.

Unfortunately we don’t have resources to run automated tests on other
OSes than Windows, although we would like to. If you could help us with
that we would very much appreciate it.

Regarding different versions of IronRuby and IronPython shared
libraries… once in a while we synchronize our releases so that our
languages can work together. The last time we did so was for IronRuby
v1.0 (http://ironruby.codeplex.com/releases/view/25901) and IronPython
v2.6.1 (http://ironpython.codeplex.com/releases/view/36280).

We used to include IronPython in Ruby’s GIThub repo. I’m not sure why we
don’t do so any more. We should. Let me check it out.

Tomas

We used to include IronPython in IronRuby’s repo in order to make sure
it would work with us since IronPython had a different source layout. I
removed it when IronPython removed most of their transforms, but I could
add it if needed. DLR’s codeplex site should have all 3 projects in it,
so that might be an option. While we don’t have resources to setup
automated tests on other OSes, if you were able to help prepare a VHD
for Hyper-V, I could try to get it into our systems (assuming I don’t
get pushback from legal and so on :(). If you are interested, feel free
to contact me directly and we’ll go from there.

JD

I think we should include IronPython in GIT repo since some of our
interop tests depend on it.

Tomas

We used to include IronPython in IronRuby’s repo in order to make sure it
would work with us since IronPython had a different source layout. I
removed it when IronPython removed most of their transforms, but I could
add it if needed. DLR’s codeplex site should have all 3 projects in it, so
that might be an option.

I suppose that is completely up to you. What im more worried about is
there
being 2 parallel streams of development for DLR but from the sounds of
it that
doesn’t really occur. obviously my main effort will be packaging your
releases
which you sync anyway.

While we don’t have resources to setup automated
tests on other OSes, if you were able to help prepare a VHD for Hyper-V, I
could try to get it into our systems (assuming I don’t get pushback from
legal and so on :(). If you are interested, feel free to contact me
directly and we’ll go from there.

I will be able to create ebuilds (the build scripts we use) that target
your
git repositories. Currently I have those “live” packages reinstalling
(and
doing an update) weekly on my system. In the future it might be nice to
have
more but it will do for now. I won’t be able to get ironruby into the
tree at
least until the next release of mono as it will not build with 2.6.4 (a
mono
bug I think you guys now about). but it does with mono trunk.

Alistair.

Ivan Porto C. (@casualjim) had a ci build for linux running at one
time. You could check with him. I believe he was running off of mono
trunk
(2.7) at the time.

~ Ryan R.

The rakefiles are gone, but we could figure out some way to specify a
keyfile

Our project build looks into dlr/Internal/MSSharedLibKey.snk for the
key. If you can’t do that for some reason let us know. We can change the
projects to accept an msbuild variable.

Tomas

Ivan Porto C. (@casualjim) had a ci build for linux running at one
time. You could check with him. I believe he was running off of mono trunk
(2.7) at the time.

Yes, I have seen his git repo and it looks a little out of date. I
don’t
think ive got much of a problem building ironruby. As I can already do
it.

The only things ive got to do is make the assemblies strong named so
that they
can be installed into the gac and to split the Microsoft.Dynamic and
Scripting
dlls into 1 or 2 separate packages. I’ll also want to submit any
changes to
do this back to ironruby. From what ive seen the Rakefiles doesn’t
support
specifying keyfiles so I’ll have to add that to their functionality.

Alistair.

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