From rogerpack2005 at gmail.com  Wed Nov  7 00:09:30 2007
From: rogerpack2005 at gmail.com (Roger Pack)
Date: Tue, 6 Nov 2007 22:09:30 -0700
Subject: [Rubyinstaller-devel] side by side
Message-ID: <966599840711062109k6b74569csacf35514b4dcd9a@mail.gmail.com>

After you get the mingw compilation going, it seems to me like setting up a
script to compile it nightly wouldn't be too hard.  Oh--except for the one
click aspect.
So far the only error I've really found is that running ruby-e "\"" anything
quotes in quotes causes problems.

Maybe we can put a link on the main page to the mingw one until we get
feedback for it. Something side by side.  What is the problem with having
two?

With the normal OCI it gives tons of libraries, most of which are unused,
and if there are some that are used, users can just install the gem with no
problem.
Maintaining a slimmed down version seems like it would be cake, once you get
one going.
Thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rubyinstaller-devel/attachments/20071106/60636081/attachment.html 

From luislavena at gmail.com  Wed Nov  7 00:40:50 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Wed, 7 Nov 2007 02:40:50 -0300
Subject: [Rubyinstaller-devel] side by side
In-Reply-To: <966599840711062109k6b74569csacf35514b4dcd9a@mail.gmail.com>
References: <966599840711062109k6b74569csacf35514b4dcd9a@mail.gmail.com>
Message-ID: <71166b3b0711062140m3679aba4q8847286e2a937b61@mail.gmail.com>

On 11/7/07, Roger Pack <rogerpack2005 at gmail.com> wrote:
> After you get the mingw compilation going, it seems to me like setting up a
> script to compile it nightly wouldn't be too hard.  Oh--except for the one
> click aspect.

Part of the Installer is the One-Click ;-)

> So far the only error I've really found is that running ruby-e "\"" anything
> quotes in quotes causes problems.
>

Did you tried -e 'puts "hello"' instead of the quad quotes?
(double-double quotes)

> Maybe we can put a link on the main page to the mingw one until we get
> feedback for it. Something side by side.  What is the problem with having
> two?

I still have my reservations about mingw/vc8 builds.

Another kind of package right now will get us a lot of troubles since
we are in RC stage.
After OCI hits stable we will start the brain storm process for the
upcoming release.

The whole build process should be automated, and the package building
(Windows Installer + Merge Modules) for the extensions and libraries.

> With the normal OCI it gives tons of libraries, most of which are unused,
> and if there are some that are used, users can just install the gem with no
> problem.

Yeah, user get a lot of things out of the box, but sometimes some gems
requires the compiler, which is another issue we must face.

> Maintaining a slimmed down version seems like it would be cake, once you get
> one going.

The whole idea is start from scratch, be modular and easily testable,
taking as experience what we learned from OCI.

> Thoughts?

I guess you can collect all the comments I made previously to this
topic in ruby-talk and here :-)

-- 
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi

From curt.hibbs at gmail.com  Wed Nov  7 11:06:40 2007
From: curt.hibbs at gmail.com (Curt Hibbs)
Date: Wed, 7 Nov 2007 10:06:40 -0600
Subject: [Rubyinstaller-devel] side by side
In-Reply-To: <71166b3b0711062140m3679aba4q8847286e2a937b61@mail.gmail.com>
References: <966599840711062109k6b74569csacf35514b4dcd9a@mail.gmail.com>
	<71166b3b0711062140m3679aba4q8847286e2a937b61@mail.gmail.com>
Message-ID: <31d15f490711070806t152f0d4hc48f41257306ccb@mail.gmail.com>

On 11/6/07, Luis Lavena <luislavena at gmail.com> wrote:
>
> On 11/7/07, Roger Pack <rogerpack2005 at gmail.com> wrote:
> > With the normal OCI it gives tons of libraries, most of which are
> unused,
> > and if there are some that are used, users can just install the gem with
> no
> > problem.
>
> Yeah, user get a lot of things out of the box, but sometimes some gems
> requires the compiler, which is another issue we must face.
>

Over the years I have definitely cut back on the included extensions,
encouraging the use of RubyGems instead. The guiding factors that I have
used are that OCI should out-of-the-box 1) support the Windows platform
(this means including the core Win32 gems), and 2) should include modest
newbie tools to help them explore Ruby.

#2 is why OCI includes fxri (which is good for seasoned rubyists as well as
newbies). Including fxri requires the inclusion of FXRuby. I've tried to get
someone to write a GUI interface to RubyGems, without any luck. If someone
had done that, I would have included it.

Also, since database programming and web programming are very popular uses,
including DBI and OpenSSL make a lot of sense.

Curt

Gui RubyyGems
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rubyinstaller-devel/attachments/20071107/cc4c516e/attachment.html 

From luislavena at gmail.com  Mon Nov 12 19:21:00 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Mon, 12 Nov 2007 21:21:00 -0300
Subject: [Rubyinstaller-devel] Mingw Builds
In-Reply-To: <4738E3E4.7020509@gmail.com>
References: <4738E3E4.7020509@gmail.com>
Message-ID: <71166b3b0711121621t637187cdq5158ed0ef29d5ccb@mail.gmail.com>

On Nov 12, 2007 8:38 PM, James Tucker <private email> wrote:
> Luis,
>
> I too have been working on a mingw compile for some time now.
>
> I have been learning mingw and msys slowly, and trying to setup some method of having a ruby install which is capable of compilation, but in most senses runs entirely standalone similar to the One-Click Installer setup.

Excellent news, and also good that you contact me, since we can learn
from each other about this.

> My latest compile is working just great, and I'm using mostly libraries from GnuWin32, and have a full-stack of ext built and working perfectly.

Is good to know that you can use the GnuWin32 utils 'as-is' without
requiring modification.

I'll really appreciate the exact version numbers of most of the
packages, included the gcc (mingw) version, since I was using
candidate and not current (stable).

> I get the same three test failures you do on patchlevel 5000.

Also good to know that I'm not alone ;-)

> The problem I am currently seeing is that I am not getting some of the interrupt signals compiling. (i.e. SIGUSR1)
>
> Have you experienced this problem?
>

AFAIK, USR1, USR2 and SIGUSR{1,2} don't work on Windows.

I need to check that, but my memory isn't good these days (getting
older, today is my 28th birthday).

irb(main):003:0> trap("USR1") { puts "SIGUSR1" }
ArgumentError: unsupported signal SIGUSR1
        from (irb):3:in `trap'
        from (irb):3
irb(main):004:0> trap("USR2") { puts "SIGUSR2" }
ArgumentError: unsupported signal SIGUSR2
        from (irb):4:in `trap'
        from (irb):4
irb(main):005:0> RUBY_PLATFORM
=> "i386-mswin32"
irb(main):006:0> RUBY_VERSION
=> "1.8.6"

> On another note, I am scripting this build up to work mostly independantly, and am very interested in making a build farm project which will also attempt to autobuild gems and provide easy compilation reports to gem authors. In this regard, I would be very willing to join our two projects into a Ruby MinGW OCI.

Let me tell you what I'm doing right now:

I'm creating a series of rake tasks that allow us have the whole
download, unpack, compile, package process for interpreters, libraries
and everything in Rake.

The idea is Exerb [1] Rake (rake.exe) and the new installer be just a
bunch of "recipes/tasks" that can be chained to produce the Installer.

so: compiler:mingw:download will download all the packages needed to
get a mingw compiler and msys

interpreter:ruby19:download, :compile and :package are other tasks in
the same way.

All independent .rake files that will be loaded by the main rakefile.rb

The idea is let the same build procedure allow us build for MinGW or
VC8 (even VC requires some patches) and even different interpreters
(ruby18, ruby19, jruby)

Example:

rake rubyinstaller.rb INTERPRETER=ruby18 COMPILER=mingw

Regarding the build farm, I've setup locally at office
CruiseControl.rb [2] to perform the checkout and build processes for
Mongrel, my applications and the new breed of One-Click installer.

I'll suggest we support and endorse firebrigade [3] regarding
compatibility of gems with the compilers and platforms.

If you're interested, I'll thank you if you join rubyinstaller-devel
list (I'm CC'ing it with the reply) and share with us the process of
bring a better Ruby to Windows :-)

Regards and have a nice week!

[1] http://exerb.sourceforge.jp/index.en.html
[2] http://cruisecontrolrb.thoughtworks.com/
[3] http://firebrigade.seattlerb.org/

-- 
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi

From luislavena at gmail.com  Fri Nov 30 18:55:02 2007
From: luislavena at gmail.com (Luis Lavena)
Date: Fri, 30 Nov 2007 20:55:02 -0300
Subject: [Rubyinstaller-devel] ruby-zlib 0.6.0 has been merged back into
	ruby_1_8
Message-ID: <71166b3b0711301555n2e52642s4e76085d2ea0748@mail.gmail.com>

Hello guys,

While I was re-doing the steps to compile ruby18 (for info to come
soon) I found that ruby-zlib 0.6.0 *is already* part of ext/zlib in
the ruby_1_8 branch (and think it is also on trunk).

Also, it seems they have corrected the lookup of library, which we
needed to replace to get it compiled with standard zlib.

So, I think will reduced one dependency and tweaking situation.

More info soon :-D

-- 
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi