From luislavena at gmail.com  Tue Jul  1 07:25:32 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Tue, 1 Jul 2008 13:25:32 +0200
Subject: [Rubyinstaller-devel] Updated VC6 One-Click Installer
In-Reply-To: <6dae68ac0806271715s3ecc38bdta7485eafd6b5e2c8@mail.gmail.com>
References: <6dae68ac0806271715s3ecc38bdta7485eafd6b5e2c8@mail.gmail.com>
Message-ID: <71166b3b0807010425k28a65f73ub88fad4b31d0b07f@mail.gmail.com>

On Sat, Jun 28, 2008 at 2:15 AM, Mike Hodgson <mhodgson at gmail.com> wrote:
> Hi all,
>
> I've been conversing with Luis through e-mail for the last few days,
> and he convinced me to post here :)
>
> I was originally just working on this for my own needs, but I have
> seen requests for it elsewhere. I've compiled the latest ruby 1.8.6
> p114 and applied the patches that the Phusion guys came up with (the
> same patch from the mingw version). I've also updated Rubygems to
> 1.2.0 and Rake to 0.8.1. Everything else is exactly the same as the
> 186-26 installer.
>
> http://www.mikehodgson.com/ruby186-27-mkh.exe
>
> I'd like some folks here to give it a try and let me know if you find
> any serious bugs. If not, I'll release it to the wild over the
> weekend. I haven't changed the readme's or anything, but this isn't an
> official release, it's just something to hold people over until the
> mingw version is released.
>
> Mike

Hello Mike!

Sorry for being late on this, but been hectic lately which distracted
me a bit :-P

In any case, I just wanted to let you know that I posted my position
to this in ruby-talk:

http://groups.google.com/group/comp.lang.ruby/browse_thread/thread/f5ab6423ceb76200#

Also added some comments to your post, which I think deserve some
thank you for the community and from me!

Again, thank you for your time doing this and also for sharing your
thought with me before the release.

Take care and have a nice week!

Regards,
-- 
Luis Lavena
AREA 17
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From larsch at belunktum.dk  Sun Jul  6 10:20:02 2008
From: larsch at belunktum.dk (Lars Christensen)
Date: Sun, 06 Jul 2008 16:20:02 +0200
Subject: [Rubyinstaller-devel] OpenSSL update & curses support
Message-ID: <4870D492.4070304@belunktum.dk>

Hello,

I had been tinkering with a similar project 
(http://github.com/larsch/rakeruby4win/) until I found rubyinstaller. I 
will probably abandon it now, since rubyinstaller is more complete and 
clean, but there are couple of thing's I'd like to see in RubyInstaller.

The OpenSSL library that is used for the rubyinstaller is very old. I 
have added a rake recipe to build openssl from source 
(http://github.com/larsch/rubyinstaller/commits/opensslbuild). The 
biggest problem is that it depends on a Perl installation, and the MSYS 
perl doesn't work. I have not been able to find a Perl package for 
windows that is easily downloadable & installable into the sandbox. 
Another small issue is that you need to clean up the PATH environment 
let it find mingw and nothing but mingw (the recipe does this). Other 
than that it appears to work.

I have added a recipe for pdcurses as well (on branch pdcurses).

A couple of minor issues I encountered:
  - rubygems installation doesnt work if RUBYOPT is set. I added a few 
lines to clear it on my master branch.
  - README.txt suggests that rubyinstaller will work with ruby 1.8.5 or 
later. I could not get it working using Ruby1.8.6-p0. There see to be 
some issues with Kernel#system when quoting the executable and directing 
to NUL at the same time. -p111 works fine however. Might be worthwhile 
checking the patch level and warning the user.
  - git and CR/LF is somewhat a mess. Any tips? If I checkout with 
core.autocrlf=true, it breaks the WiX XML files. If I edit files with 
core.autocrlf=false, it breaks the delta on everything else.

Regards,
Lars




From luislavena at gmail.com  Sun Jul  6 18:25:03 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Mon, 7 Jul 2008 00:25:03 +0200
Subject: [Rubyinstaller-devel] OpenSSL update & curses support
In-Reply-To: <4870D492.4070304@belunktum.dk>
References: <4870D492.4070304@belunktum.dk>
Message-ID: <71166b3b0807061525q68a4203epe1821da78a871b71@mail.gmail.com>

On Sun, Jul 6, 2008 at 4:20 PM, Lars Christensen <larsch at belunktum.dk> wrote:
> Hello,
>
> I had been tinkering with a similar project
> (http://github.com/larsch/rakeruby4win/) until I found rubyinstaller. I will
> probably abandon it now, since rubyinstaller is more complete and clean, but
> there are couple of thing's I'd like to see in RubyInstaller.
>

Hey Lars, welcome aboard!

> The OpenSSL library that is used for the rubyinstaller is very old. I have
> added a rake recipe to build openssl from source
> (http://github.com/larsch/rubyinstaller/commits/opensslbuild). The biggest
> problem is that it depends on a Perl installation, and the MSYS perl doesn't
> work. I have not been able to find a Perl package for windows that is easily
> downloadable & installable into the sandbox. Another small issue is that you
> need to clean up the PATH environment let it find mingw and nothing but
> mingw (the recipe does this). Other than that it appears to work.
>

Yeah, right now we depend on a old pre-build package since building
from sources, as you pointed, was problematic and required several
packages not included.

We consider that a task re factoring and reorganization will ease the
process, but right now we were focused in getting it done :-D

I checked you commit and saw you included mingw-make, is that just for
OpenSSL? We had several issues getting it working to build ruby
itself, so we reverted to msys-make instead.

An alternative, instead of following the batch file as suggested in
OpenSSL site is follow the configure, make and make install process.
Did you explored that way?

> I have added a recipe for pdcurses as well (on branch pdcurses).
>

Oh, great, the more extension being build, the better!

> A couple of minor issues I encountered:
>  - rubygems installation doesnt work if RUBYOPT is set. I added a few lines
> to clear it on my master branch.

Gordon did fix this in his fork which I didn't pulled into mine:

http://github.com/vertiginous/rubyinstaller/tree/master

>  - README.txt suggests that rubyinstaller will work with ruby 1.8.5 or
> later. I could not get it working using Ruby1.8.6-p0. There see to be some
> issues with Kernel#system when quoting the executable and directing to NUL
> at the same time. -p111 works fine however. Might be worthwhile checking the
> patch level and warning the user.

Yes, indeed:
ruby 1.8.5 (2007-09-24 patchlevel 114) [i386-mswin32]

and
ruby 1.8.6 (2008-03-03 patchlevel 114) [i386-mswin32]

Both worked for me, but didn't used a older patchlevel since latest
1.8.5 of One-Click is 1.8.6 and previous was 1.8.5

>  - git and CR/LF is somewhat a mess. Any tips? If I checkout with
> core.autocrlf=true, it breaks the WiX XML files. If I edit files with
> core.autocrlf=false, it breaks the delta on everything else.
>

Yeah, two things I suggest: do not use git configure core.autocrlf
false directly, please alter the etc/gitconfig file instead, since I
have seen, even with --global being used, the change do not affect the
clones or the commits.

Also change your editor to Unix (LF) instead of Windows (LF+CR) since
most of the recipes are been coded that way (to be able to use the
sandbox as cross-platform compilation recipe). Most editor today
should be able to let you configure or change that. As rule of thumb,
I alwasy set on Unix to avoid merge conflicts contributing to
projects.

> Regards,
> Lars
>

Again, welcome aboard and thanks for your time man!

Good week and great work man. I'll take a look to your commits and see
how can we workout those. You can use github gem to simplify pulling
from different users (use my fork of github-gem since will work with
MinGW).

Regards!
-- 
Luis Lavena
AREA 17
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From gthiesfeld at gmail.com  Sun Jul  6 21:08:33 2008
From: gthiesfeld at gmail.com (Gordon Thiesfeld)
Date: Sun, 6 Jul 2008 20:08:33 -0500
Subject: [Rubyinstaller-devel] OpenSSL update & curses support
In-Reply-To: <4870D492.4070304@belunktum.dk>
References: <4870D492.4070304@belunktum.dk>
Message-ID: <e9ece6840807061808p3bf1ca23nafabab0356239926@mail.gmail.com>

On Sun, Jul 6, 2008 at 9:20 AM, Lars Christensen <larsch at belunktum.dk> wrote:
> The OpenSSL library that is used for the rubyinstaller is very old. I have
> added a rake recipe to build openssl from source
> (http://github.com/larsch/rubyinstaller/commits/opensslbuild). The biggest
> problem is that it depends on a Perl installation, and the MSYS perl doesn't
> work. I have not been able to find a Perl package for windows that is easily
> downloadable & installable into the sandbox. Another small issue is that you
> need to clean up the PATH environment let it find mingw and nothing but
> mingw (the recipe does this). Other than that it appears to work.

This is good news.  I've tried building OpenSSL a few times, but never
had much luck with it.  As far as Perl goes, have you tried Strawberry
Perl[1]?  I don't know much about the different Perl packages, but
Strawberry has a zip file available.  Just a thought.

[1] http://strawberryperl.com/releases.html

Thanks,

Gordon

From larsch at belunktum.dk  Mon Jul  7 11:00:05 2008
From: larsch at belunktum.dk (Lars Christensen)
Date: Mon, 07 Jul 2008 17:00:05 +0200
Subject: [Rubyinstaller-devel] OpenSSL update & curses support
In-Reply-To: <71166b3b0807061525q68a4203epe1821da78a871b71@mail.gmail.com>
References: <4870D492.4070304@belunktum.dk>
	<71166b3b0807061525q68a4203epe1821da78a871b71@mail.gmail.com>
Message-ID: <48722F75.6090506@belunktum.dk>

Luis Lavena wrote:
> On Sun, Jul 6, 2008 at 4:20 PM, Lars Christensen <larsch at belunktum.dk> wrote:
>   
> I checked you commit and saw you included mingw-make, is that just for
> OpenSSL? We had several issues getting it working to build ruby
> itself, so we reverted to msys-make instead.
>   
Yes, the OpenSSL build scripts call mingw32-make directly. Their 
makefile generator assume that everything is plain old DOS commands 
using mingw32-make (e.g. "copy" rather than "cp"). Tuning the SHELL 
might help, but since they assume DOS conventions for everything, it may 
not be compatible with msys-make.

> An alternative, instead of following the batch file as suggested in
> OpenSSL site is follow the configure, make and make install process.
> Did you explored that way?
>   
I tried that, but their scripts/Makefile refuse to work that way and ask 
you to use "ms\mingw32.bat" instead. They don't use autoconf, so 
portability is something they handle manually.
> Yeah, two things I suggest: do not use git configure core.autocrlf
> false directly, please alter the etc/gitconfig file instead, since I
> have seen, even with --global being used, the change do not affect the
> clones or the commits.
>   
Setting it to false did help, I think. Not sure why I had the problem 
with edited files and "git diff"; I doesn't happen anymore.
> Also change your editor to Unix (LF) instead of Windows (LF+CR).
>   
No problem, I'm on Emacs.





From larsch at belunktum.dk  Mon Jul  7 12:07:09 2008
From: larsch at belunktum.dk (Lars Christensen)
Date: Mon, 7 Jul 2008 18:07:09 +0200 (Romance Standard Time)
Subject: [Rubyinstaller-devel] OpenSSL update & curses support
In-Reply-To: <e9ece6840807061808p3bf1ca23nafabab0356239926@mail.gmail.com>
References: <4870D492.4070304@belunktum.dk>
	<e9ece6840807061808p3bf1ca23nafabab0356239926@mail.gmail.com>
Message-ID: <Pine.WNT.4.64.0807071800050.676@cookie>


On Sun, 6 Jul 2008, Gordon Thiesfeld wrote:

> I've tried building OpenSSL a few times, but never had much luck with 
> it. As far as Perl goes, have you tried Strawberry Perl[1]?  I don't 
> know much about the different Perl packages, but Strawberry has a zip 
> file available.  Just a thought.

Good idea. However, they (ironically) include a MinGW environment of their 
own (zip is 35M). I've added rules to use it for building OpenSSL.

http://github.com/larsch/rubyinstaller/commit/77be67b3d8ebc370004bf314b5a99b6473846677

Regards,
Lars


From larsch at belunktum.dk  Sat Jul 12 08:45:53 2008
From: larsch at belunktum.dk (Lars Christensen)
Date: Sat, 12 Jul 2008 14:45:53 +0200 (Romance Standard Time)
Subject: [Rubyinstaller-devel] rubygems & --destdir
Message-ID: <Pine.WNT.4.64.0807121444270.3544@cookie>

Hi,

The change to installing rubygems --destdir doesn't work for me. Am I 
missing something? I get this:

fileutils.rb:243:in `mkdir': Invalid argument - 
D:/src/rubyinstaller/sandbox/rubygems_mingw/D:

Lars


From luislavena at gmail.com  Sat Jul 12 10:14:51 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Sat, 12 Jul 2008 16:14:51 +0200
Subject: [Rubyinstaller-devel] rubygems & --destdir
In-Reply-To: <Pine.WNT.4.64.0807121444270.3544@cookie>
References: <Pine.WNT.4.64.0807121444270.3544@cookie>
Message-ID: <71166b3b0807120714j39d8dbf2t9d1baed17dd58086@mail.gmail.com>

On Sat, Jul 12, 2008 at 2:45 PM, Lars Christensen <larsch at belunktum.dk> wrote:
> Hi,
>
> The change to installing rubygems --destdir doesn't work for me. Am I
> missing something? I get this:
>
> fileutils.rb:243:in `mkdir': Invalid argument -
> D:/src/rubyinstaller/sandbox/rubygems_mingw/D:
>

Hello Lars,

We found that using --prefix only copied the binaries and the
libraries of ruby outside sandbox/ruby_mingw, but the folder structure
where the gems will be stored still remains inside of it.

--destdir is supposed to allow packagers (in Linux) to replicate the
folder structure outside the installation directory, something we have
been doing manually.

The thing is that parameter is broken in 1.2 and I committed a fix for
it, as you can see in the changelog:

http://rubygems.rubyforge.org/svn/trunk/ChangeLog

Also this is the mailing list post that describe the situation:

http://rubyforge.org/pipermail/rubygems-developers/2008-July/003969.html

I got approval from Eric Hodel to commit the fix.

The problem is yet there is no official release for 1.2.1, so I've
been using rake CHECKOUT=1 to build from svn these components.

Thankfully Ruby SVN now works, but I'll keep my fingers crossed just in case ;-)

BTW, I took a look at your fork, looks good. The only downside is the
strawberry perl is huge :-P

I've been thinking in peek the GNUwin32 guys to update their packages,
but that will be silly (and will not get good reactions).

The other workaround is remove the dependencies build nightware from
rubyinstaller and provide (to us) pre-packaged binary versions of
OpenSSL, Readline, Iconv, Gettext, etc.

Anyway, open to suggestions.

> Lars
>

Thank you Lars for pointing this down.
-- 
Luis Lavena
AREA 17
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From larsch at belunktum.dk  Sat Jul 12 13:54:18 2008
From: larsch at belunktum.dk (Lars Christensen)
Date: Sat, 12 Jul 2008 19:54:18 +0200 (Romance Standard Time)
Subject: [Rubyinstaller-devel] rubygems & --destdir
In-Reply-To: <71166b3b0807120714j39d8dbf2t9d1baed17dd58086@mail.gmail.com>
References: <Pine.WNT.4.64.0807121444270.3544@cookie>
	<71166b3b0807120714j39d8dbf2t9d1baed17dd58086@mail.gmail.com>
Message-ID: <Pine.WNT.4.64.0807121930400.3544@cookie>


On Sat, 12 Jul 2008, Luis Lavena wrote:

> On Sat, Jul 12, 2008 at 2:45 PM, Lars Christensen <larsch at belunktum.dk> wrote:
>> The change to installing rubygems --destdir doesn't work for me. Am I
>> missing something?
>
> --destdir is supposed to allow packagers (in Linux) to replicate the
> folder structure outside the installation directory, something we have
> been doing manually.

Ruby's configure is called with --prefix. Could change be changed to 
--destdir?

> The problem is yet there is no official release for 1.2.1, so I've been 
> using rake CHECKOUT=1 to build from svn these components.

Thanks, I'll use that until rubygems gets released.

> BTW, I took a look at your fork, looks good. The only downside is the
> strawberry perl is huge :-P

Yes, its far from optimal. Suggestions welcome :)

> I've been thinking in peek the GNUwin32 guys to update their packages,
> but that will be silly (and will not get good reactions).
>
> The other workaround is remove the dependencies build nightware from
> rubyinstaller and provide (to us) pre-packaged binary versions of
> OpenSSL, Readline, Iconv, Gettext, etc.
>
> Anyway, open to suggestions.

I personal prefer to keep the option to build everything from sources & 
official binaries (gnuwin32 permitted). This way, if someone wants to 
fix/modify/upgrade a dependency, its completely transparent how 
rubyinstaller generates it from its official source.

It would be possible to give the user an option of using prebuilt 
packages, for example by specifying "rake USEPREBUILT=1".

Lars


From luislavena at gmail.com  Sat Jul 12 14:47:51 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Sat, 12 Jul 2008 20:47:51 +0200
Subject: [Rubyinstaller-devel] rubygems & --destdir
In-Reply-To: <Pine.WNT.4.64.0807121930400.3544@cookie>
References: <Pine.WNT.4.64.0807121444270.3544@cookie>
	<71166b3b0807120714j39d8dbf2t9d1baed17dd58086@mail.gmail.com>
	<Pine.WNT.4.64.0807121930400.3544@cookie>
Message-ID: <71166b3b0807121147v15f9db22mdc3daf6c635f42e6@mail.gmail.com>

On Sat, Jul 12, 2008 at 7:54 PM, Lars Christensen <larsch at belunktum.dk> wrote:
>
> On Sat, 12 Jul 2008, Luis Lavena wrote:
>
>> On Sat, Jul 12, 2008 at 2:45 PM, Lars Christensen <larsch at belunktum.dk>
>> wrote:
>>>
>>> The change to installing rubygems --destdir doesn't work for me. Am I
>>> missing something?
>>
>> --destdir is supposed to allow packagers (in Linux) to replicate the
>> folder structure outside the installation directory, something we have
>> been doing manually.
>
> Ruby's configure is called with --prefix. Could change be changed to
> --destdir?
>

There is no --destdir for Ruby, only for RubyGems.

>> The problem is yet there is no official release for 1.2.1, so I've been
>> using rake CHECKOUT=1 to build from svn these components.
>
> Thanks, I'll use that until rubygems gets released.
>

Keep in mind that you will require to remove the folders from
ruby_mingw (lib/ruby/1.8/gems/*) since they belong to rubygems_mingw
instead

>> BTW, I took a look at your fork, looks good. The only downside is the
>> strawberry perl is huge :-P
>
> Yes, its far from optimal. Suggestions welcome :)
>

I think I found a workaround using msys-perl and some tweaks to
openssl generated makefile. Will test it a bit more and share that
with you.

>> I've been thinking in peek the GNUwin32 guys to update their packages,
>> but that will be silly (and will not get good reactions).
>>
>> The other workaround is remove the dependencies build nightware from
>> rubyinstaller and provide (to us) pre-packaged binary versions of
>> OpenSSL, Readline, Iconv, Gettext, etc.
>>
>> Anyway, open to suggestions.
>
> I personal prefer to keep the option to build everything from sources &
> official binaries (gnuwin32 permitted). This way, if someone wants to
> fix/modify/upgrade a dependency, its completely transparent how
> rubyinstaller generates it from its official source.
>
> It would be possible to give the user an option of using prebuilt packages,
> for example by specifying "rake USEPREBUILT=1".
>

In any case, the rubyinstaller is ideally target to One-Click
Installer developers and not end users, so the usage of pre-build vs.
source is non-critical.

> Lars
>

-- 
Luis Lavena
AREA 17
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From luislavena at gmail.com  Mon Jul 14 16:42:20 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Mon, 14 Jul 2008 22:42:20 +0200
Subject: [Rubyinstaller-devel] Succeed building OpenSSL (kind of)
Message-ID: <71166b3b0807141342m54a7c11dte0aeb2673af0f084@mail.gmail.com>

Hello Guys,

I the issue with OpenSSL (the lack of updated version) is very annoying.

One path to solve that is what Lars implemented in his fork, which
rely on strawberry Perl and looks it works. The down side: 30MB of
perl download since strawberry "flavor" bundles it's own MinGW
environment.

Other alternative was using ActivePerl, which require manual
installation, and thus, cannot be automated.

There are several downsides with OpenSSL: the lack of configure / make
/ make install familiar with *nix packages that usually works with
MinGW+MSYS and the forced usage of perl to build OpenSSL :-P

I've been exploring the Thor recipes for building OpenSSL:

https://svn.torproject.org/svn/torbrowser/trunk/build-scripts/INSTALL

Which, so far, produced good results, excep for being static linked
libraries instead of shared ones.

When I turn on the shared ones, it fails (need to review what is wrong).

I'll invest my time getting this working instead of depending on
another huge package like strawberry or activestate perl.

Why? is not the succeed, but sounds stupid from the OpenSSL developers
they: 1) ship with symlinks and 2) do not provide a *nix like building
solution for Windows (configure / make / make install).

In any case, Is just my opinion, but I'll love heard other thoughts about it.

-- 
Luis Lavena
AREA 17
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From larsch at belunktum.dk  Mon Jul 14 18:08:57 2008
From: larsch at belunktum.dk (Lars Christensen)
Date: Tue, 15 Jul 2008 00:08:57 +0200 (Romance Standard Time)
Subject: [Rubyinstaller-devel] Succeed building OpenSSL (kind of)
In-Reply-To: <71166b3b0807141342m54a7c11dte0aeb2673af0f084@mail.gmail.com>
References: <71166b3b0807141342m54a7c11dte0aeb2673af0f084@mail.gmail.com>
Message-ID: <Pine.WNT.4.64.0807142345330.3988@cookie>



On Mon, 14 Jul 2008, Luis Lavena wrote:

> Other alternative was using ActivePerl, which require manual 
> installation, and thus, cannot be automated.

It seems to be possible to automate ActivateState extraction using a 
so-called "administrative install". Check it out at

http://github.com/larsch/rubyinstaller/commits/openssl-activestate

It not a whole lot better than Strawperry perl; the AS Perl distribution 
is still 17MB, and extracting using msiexec takes quite a while. It could 
be made optional however, if an installation is detected on the build 
host.

> Why? is not the succeed, but sounds stupid from the OpenSSL developers
> they: 1) ship with symlinks and 2) do not provide a *nix like building
> solution for Windows (configure / make / make install).

Particularly ironic is this sarcastic statement from their FAQ: "autoconf 
will probably be used in future OpenSSL versions. If it was less 
Unix-centric, it might have been used much earlier.".

> In any case, Is just my opinion, but I'll love heard other thoughts about it.

Using an unofficial (or hacked) build procedure for OpenSSL does not 
appear as an ideal solution to me either, 
(http://metasploit.com/users/hdm/tools/debian-openssl/ comes to mind).

An alternative is to hack their Makefile-generator script to work around 
the issues with msys-perl? It seemed to be a path issue when I tried. Perl 
is not fresh in my memory however.

Lars


From luislavena at gmail.com  Mon Jul 14 19:11:19 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Tue, 15 Jul 2008 01:11:19 +0200
Subject: [Rubyinstaller-devel] Succeed building OpenSSL (kind of)
In-Reply-To: <Pine.WNT.4.64.0807142345330.3988@cookie>
References: <71166b3b0807141342m54a7c11dte0aeb2673af0f084@mail.gmail.com>
	<Pine.WNT.4.64.0807142345330.3988@cookie>
Message-ID: <71166b3b0807141611i7d6e27f4x141070005a9e1ec4@mail.gmail.com>

On Tue, Jul 15, 2008 at 12:08 AM, Lars Christensen <larsch at belunktum.dk> wrote:
>
>
> On Mon, 14 Jul 2008, Luis Lavena wrote:
>
>> Other alternative was using ActivePerl, which require manual installation,
>> and thus, cannot be automated.
>
> It seems to be possible to automate ActivateState extraction using a
> so-called "administrative install". Check it out at
>
> http://github.com/larsch/rubyinstaller/commits/openssl-activestate
>
> It not a whole lot better than Strawperry perl; the AS Perl distribution is
> still 17MB, and extracting using msiexec takes quite a while. It could be
> made optional however, if an installation is detected on the build host.
>

Yeah, and a administrative install still pollutes the Windows
Installer information database (ala: it keep track of your
administrative install). Couldn't confirm with proper examples but
found issues in the past doing the same with other tools

>> Why? is not the succeed, but sounds stupid from the OpenSSL developers
>> they: 1) ship with symlinks and 2) do not provide a *nix like building
>> solution for Windows (configure / make / make install).
>
> Particularly ironic is this sarcastic statement from their FAQ: "autoconf
> will probably be used in future OpenSSL versions. If it was less
> Unix-centric, it might have been used much earlier.".
>

Yeah, plain and simple irony... :-P

>> In any case, Is just my opinion, but I'll love heard other thoughts about
>> it.
>
> Using an unofficial (or hacked) build procedure for OpenSSL does not appear
> as an ideal solution to me either,
> (http://metasploit.com/users/hdm/tools/debian-openssl/ comes to mind).
>
> An alternative is to hack their Makefile-generator script to work around the
> issues with msys-perl? It seemed to be a path issue when I tried. Perl is
> not fresh in my memory however.
>

What I did and succeed:

Replace the files that reported with symlink extraction issues with
the proper files.
(most header files and some c ones)

Removed the test folder and after executed config script, modified the
generated makefile to remove the test.

In any case, I took a look at the makefiles from GNUwin32 and they are
quite interesting (Makefile.mingw and Makefile.ssl), maybe we can base
on that for our parameters?

-- 
Luis Lavena
AREA 17
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From hramrach at centrum.cz  Tue Jul 15 09:49:13 2008
From: hramrach at centrum.cz (Michal Suchanek)
Date: Tue, 15 Jul 2008 15:49:13 +0200
Subject: [Rubyinstaller-devel] Succeed building OpenSSL (kind of)
In-Reply-To: <71166b3b0807141342m54a7c11dte0aeb2673af0f084@mail.gmail.com>
References: <71166b3b0807141342m54a7c11dte0aeb2673af0f084@mail.gmail.com>
Message-ID: <a5d587fb0807150649l5e0e9c10x13ff0d39bda79eb1@mail.gmail.com>

On 14/07/2008, Luis Lavena <luislavena at gmail.com> wrote:
> Hello Guys,
>
>  I the issue with OpenSSL (the lack of updated version) is very annoying.
>
>  One path to solve that is what Lars implemented in his fork, which
>  rely on strawberry Perl and looks it works. The down side: 30MB of
>  perl download since strawberry "flavor" bundles it's own MinGW
>  environment.
>
>  Other alternative was using ActivePerl, which require manual
>  installation, and thus, cannot be automated.
>
>  There are several downsides with OpenSSL: the lack of configure / make
>  / make install familiar with *nix packages that usually works with
>  MinGW+MSYS and the forced usage of perl to build OpenSSL :-P
>
>  I've been exploring the Thor recipes for building OpenSSL:
>
>  https://svn.torproject.org/svn/torbrowser/trunk/build-scripts/INSTALL
>
>  Which, so far, produced good results, excep for being static linked
>  libraries instead of shared ones.
>
>  When I turn on the shared ones, it fails (need to review what is wrong).
>

I think there is no problem with static libraries (as long as they can
be used to build the extension). The library is going to be used only
for a single extension so there is no sharing anyway. Actually you
might save some space by linking statically.

Thanks

Michal

From luislavena at gmail.com  Tue Jul 15 09:59:44 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Tue, 15 Jul 2008 15:59:44 +0200
Subject: [Rubyinstaller-devel] Succeed building OpenSSL (kind of)
In-Reply-To: <a5d587fb0807150649l5e0e9c10x13ff0d39bda79eb1@mail.gmail.com>
References: <71166b3b0807141342m54a7c11dte0aeb2673af0f084@mail.gmail.com>
	<a5d587fb0807150649l5e0e9c10x13ff0d39bda79eb1@mail.gmail.com>
Message-ID: <71166b3b0807150659n680876al25031437fb72c11e@mail.gmail.com>

On Tue, Jul 15, 2008 at 3:49 PM, Michal Suchanek <hramrach at centrum.cz> wrote:
> On 14/07/2008, Luis Lavena <luislavena at gmail.com> wrote:
>> Hello Guys,
>>
>>  I the issue with OpenSSL (the lack of updated version) is very annoying.
>>
>>  One path to solve that is what Lars implemented in his fork, which
>>  rely on strawberry Perl and looks it works. The down side: 30MB of
>>  perl download since strawberry "flavor" bundles it's own MinGW
>>  environment.
>>
>>  Other alternative was using ActivePerl, which require manual
>>  installation, and thus, cannot be automated.
>>
>>  There are several downsides with OpenSSL: the lack of configure / make
>>  / make install familiar with *nix packages that usually works with
>>  MinGW+MSYS and the forced usage of perl to build OpenSSL :-P
>>
>>  I've been exploring the Thor recipes for building OpenSSL:
>>
>>  https://svn.torproject.org/svn/torbrowser/trunk/build-scripts/INSTALL
>>
>>  Which, so far, produced good results, excep for being static linked
>>  libraries instead of shared ones.
>>
>>  When I turn on the shared ones, it fails (need to review what is wrong).
>>
>
> I think there is no problem with static libraries (as long as they can
> be used to build the extension). The library is going to be used only
> for a single extension so there is no sharing anyway. Actually you
> might save some space by linking statically.
>

Thank you for your input Michal.

Yeah, I've seen no problem with the static builds, but I'm worried
about the interface between Ruby and Postgres, which bundles as shared
library latest OpenSSL.

Dunno if sometimes there will be some conflict at execution time that
can be bad in the long run.

Also, if developers require to build other Ruby C extensions that
depends on OpenSSL (dunno which one yet, but just in case), we will
require to have a bundle of those modifications as a downloadable zip
package.

But please, people, drop me the negatives comments so that forces me
to work on better alternatives ;-)

> Thanks
>

Thanks to you for your comments and following the list!

-- 
Luis Lavena
AREA 17
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From luislavena at gmail.com  Fri Jul 25 21:33:12 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Sat, 26 Jul 2008 03:33:12 +0200
Subject: [Rubyinstaller-devel] News for OpenSSL build
Message-ID: <71166b3b0807251833g2ddce3fcg3e26ce9367d2a093@mail.gmail.com>

Hello Guys,

Following the inspiration and the push Lars provided for building
OpenSSL. I must congratulate him for the perceverance on getting it
working, but I disagree on the external dependency to ActiveState Perl
or the huge Strawberry Perl (35MB).

I first thought the OpenSSL were crazy using perl scripts instead of
autoconf / automake scripts, and they have proven that they are :-D

After circumvent the issues with symlinks in the packages and find the
proper steps to build it, I managed to create a new recipe for it.

Also, it is now a good series of rake tasks that avoid rebuilding or
extraction if there are no change to the files or source package.

This is part of the 'proper-openssl' branch in GitHub.

The main reason I didn't merge it yet with master is that the
generated library is a static one, and that adds 1MB more of memory
usage just by require 'openssl' Ruby C Extension.

The dll commands are failing:

 dllwrap --dllname libeay32.dll --output-lib out/libeay32.a --def
ms/libeay32.def out/libcrypto.a -lwsock32 -lgdi32 -lmsvcrt
libeay32.exp:fake:(.edata+0x35c4): undefined reference to `pqueue_print'
collect2: ld returned 1 exit status

Any suggestions are real welcome.

Good night everybody.
-- 
Luis Lavena
AREA 17
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From fabioakita at gmail.com  Sat Jul 26 15:37:03 2008
From: fabioakita at gmail.com (Fabio Akita)
Date: Sat, 26 Jul 2008 16:37:03 -0300
Subject: [Rubyinstaller-devel] Trying to compile sqlite3
Message-ID: <43bfd1100807261237q284e5fd4k90e0180e8a5afa21@mail.gmail.com>

Hi, Luis I am re-copying the question I sent you here in the list.

I've built the most current One-Click installer and it worked great. I
installed the devkit version and I am now trying to install the
sqlite3-ruby gem.

C:\>gem install sqlite3-ruby -- --with-sqlite3-dir=c:/src/sqlite-source-3_6_0
Building native extensions.  This could take a while...
ERROR:  Error installing sqlite3-ruby:
        ERROR: Failed to build gem native extension.

c:/ruby18/bin/ruby.exe extconf.rb install sqlite3-ruby --
--with-sqlite3-dir=c:/src/sqlite-source-3_6_0
checking for fdatasync() in -lrt... no
checking for sqlite3.h... no
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of
necessary libraries and/or headers.  Check the mkmf.log file for more
details.  You may need configuration options.

Provided configuration options:
        --with-opt-dir
        --without-opt-dir
        --with-opt-include
        --without-opt-include=${opt-dir}/include
        --with-opt-lib
        --without-opt-lib=${opt-dir}/lib
        --with-make-prog
        --without-make-prog
        --srcdir=.
        --curdir
        --ruby=c:/ruby18/bin/ruby
        --with-sqlite3-dir
        --with-sqlite3-include
        --without-sqlite3-include=${sqlite3-dir}/include
        --with-sqlite3-lib
        --without-sqlite3-lib=${sqlite3-dir}/lib
        --with-rtlib
        --without-rtlib


Gem files will remain installed in
c:/ruby18/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.2.2 for inspection.
Results logged to
c:/ruby18/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.2.2/ext/sqlite3_api/gem_make.out


I've downloaded the sqlite3 sources from:
http://www.sqlite.org/sqlite-source-3_6_0.zip

Am I missing something?

-- 
[]'s

Fabio Akita (www.akitaonrails.com)
Ruby on Rails Product Manager
Locaweb - Keep IT Simple.

From luislavena at gmail.com  Sat Jul 26 16:11:32 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Sat, 26 Jul 2008 22:11:32 +0200
Subject: [Rubyinstaller-devel] Trying to compile sqlite3
In-Reply-To: <43bfd1100807261237q284e5fd4k90e0180e8a5afa21@mail.gmail.com>
References: <43bfd1100807261237q284e5fd4k90e0180e8a5afa21@mail.gmail.com>
Message-ID: <71166b3b0807261311g55efa74cpdd5c0bfc733babf9@mail.gmail.com>

On Sat, Jul 26, 2008 at 9:37 PM, Fabio Akita <fabioakita at gmail.com> wrote:
> Hi, Luis I am re-copying the question I sent you here in the list.
>
> I've built the most current One-Click installer and it worked great. I
> installed the devkit version and I am now trying to install the
> sqlite3-ruby gem.
>
> C:\>gem install sqlite3-ruby -- --with-sqlite3-dir=c:/src/sqlite-source-3_6_0
> Building native extensions.  This could take a while...
> ERROR:  Error installing sqlite3-ruby:
>        ERROR: Failed to build gem native extension.
>
> c:/ruby18/bin/ruby.exe extconf.rb install sqlite3-ruby --
> --with-sqlite3-dir=c:/src/sqlite-source-3_6_0
> checking for fdatasync() in -lrt... no
> checking for sqlite3.h... no
> *** extconf.rb failed ***
> Could not create Makefile due to some reason, probably lack of
> necessary libraries and/or headers.  Check the mkmf.log file for more
> details.  You may need configuration options.
>
> ...
>
> I've downloaded the sqlite3 sources from:
> http://www.sqlite.org/sqlite-source-3_6_0.zip
>
> Am I missing something?
>

Actually, is not 100% your fault ;-)

You need the pre-built binaries besides the source code:
http://sqlite.org/sqlitedll-3_6_0.zip

Then you can grab either source or the amalgamation version, we only
care about sqlite3.h which is inside.

>From the dll package you will have the dll and a .def file. We now
need to create the linking library that will be used by gcc to link
against sqlite3 dll.

So, until they provide a ready to use sqlite3 package:

1) create a sqlite3 folder
2) unzip sqlitedll-3_6_0.zip into sqlite3/lib folder
3) unzil from the sources the sqlite3.h file and put into sqlite3/include folder
3) you will need to call dlltool to create the .a library to be able
to compile with gcc:

D:\src\sqlite3\lib>c:\Ruby18\devkit\mingw\bin\dlltool.exe --dllname sqlite3.dll
--def sqlite3.def --output-lib sqlite3.a

4) Now you can supply the --with-sqlite3-dir to gem install:

gem install sqlite3-ruby -- --with-sqlite3-dir=d:/src/sqlite3
Building native extensions.  This could take a while...
Successfully installed sqlite3-ruby-1.2.2
1 gem installed
Installing ri documentation for sqlite3-ruby-1.2.2...
Installing RDoc documentation for sqlite3-ruby-1.2.2...

Maybe we should point this in the Wiki? :-D

HTH,
-- 
Luis Lavena
AREA 17
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From fabioakita at gmail.com  Sun Jul 27 11:41:58 2008
From: fabioakita at gmail.com (Fabio Akita)
Date: Sun, 27 Jul 2008 12:41:58 -0300
Subject: [Rubyinstaller-devel] IIS FastCGI
Message-ID: <A1EF916D-8CE9-4D6F-9FC8-E34362F10D65@gmail.com>

IIS 6 already supports Rails under FastCGI but requires a few  
adjustments (http://mvolo.com/blogs/serverside/archive/2007/02/18/10-steps-to-get-Ruby-on-Rails-running-on-Windows-with-IIS-FastCGI.aspx 
):

- a tweak on line 559 of cgi.rb
- RoR IIS extensions

Do you think it would be beneficial to include the cgi.rb fix and the  
RoR IIS extension already in the installer?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rubyinstaller-devel/attachments/20080727/bf7ed2d6/attachment.html>

From luislavena at gmail.com  Sun Jul 27 13:02:47 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Sun, 27 Jul 2008 19:02:47 +0200
Subject: [Rubyinstaller-devel] IIS FastCGI
In-Reply-To: <A1EF916D-8CE9-4D6F-9FC8-E34362F10D65@gmail.com>
References: <A1EF916D-8CE9-4D6F-9FC8-E34362F10D65@gmail.com>
Message-ID: <71166b3b0807271002jd743ed3pd4a639c7755d540e@mail.gmail.com>

On Sun, Jul 27, 2008 at 5:41 PM, Fabio Akita <fabioakita at gmail.com> wrote:
> IIS 6 already supports Rails under FastCGI but requires a few adjustments
> (http://mvolo.com/blogs/serverside/archive/2007/02/18/10-steps-to-get-Ruby-on-Rails-running-on-Windows-with-IIS-FastCGI.aspx):
>
> - a tweak on line 559 of cgi.rb
> - RoR IIS extensions
>
> Do you think it would be beneficial to include the cgi.rb fix and the RoR
> IIS extension already in the installer?

The CGI tweak should be sent to Ruby-Core, patching is a thing I will
not like to do more than needed.

The IIS extensions mentioned over there are built with VC7 which link
to a different version of MSVCRT.

To solve that, I worked with Drew Sears and bundled fcgi with latest
One-Click Installer.

I'll suggest the creator of fcgi extension work on a Gem so we can
bundle it or ease installation as installing plain extensions on top
of new RubyInstaller package is not a good alternative.

-- 
Luis Lavena
AREA 17
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From fabioakita at gmail.com  Mon Jul 28 17:34:55 2008
From: fabioakita at gmail.com (Fabio Akita)
Date: Mon, 28 Jul 2008 18:34:55 -0300
Subject: [Rubyinstaller-devel] Problem with Mongrel
Message-ID: <43bfd1100807281434h270cf6e2kb9a1c8cb18660992@mail.gmail.com>

I am running the new ruby installer and I installed  the several
win32utils after mongrel complained about win32-service. But even
after that I am unable to start  mongrel. That's the error:

** Starting Mongrel listening at 0.0.0.0:3000
** Starting Rails with development environment...
** Rails loaded.
** Loading any Rails specific GemPlugins
Exiting
c:/ruby18/lib/ruby/gems/1.8/gems/mongrel-1.1.5-x86-mswin32-60/lib/mongrel/configurator.rb:
372:in `trap': unsupported signal SIGUSR1 (ArgumentError)
        from c:/ruby18/lib/ruby/gems/1.8/gems/mongrel-1.1.5-x86-mswin32-60/lib/mongrel/con
figurator.rb:372:in `setup_signals'
        from c:/ruby18/lib/ruby/gems/1.8/gems/mongrel-1.1.5-x86-mswin32-60/bin/../lib/mong
rel/rails.rb:174:in `setup_rails_signals'
        from c:/ruby18/lib/ruby/gems/1.8/gems/mongrel-1.1.5-x86-mswin32-60/bin/mongrel_rai
ls:124:in `cloaker_'
        from c:/ruby18/lib/ruby/gems/1.8/gems/mongrel-1.1.5-x86-mswin32-60/lib/mongrel/con
figurator.rb:149:in `call'
        from c:/ruby18/lib/ruby/gems/1.8/gems/mongrel-1.1.5-x86-mswin32-60/lib/mongrel/con
figurator.rb:149:in `listener'
        from c:/ruby18/lib/ruby/gems/1.8/gems/mongrel-1.1.5-x86-mswin32-60/bin/mongrel_rai
ls:99:in `cloaker_'
        from c:/ruby18/lib/ruby/gems/1.8/gems/mongrel-1.1.5-x86-mswin32-60/lib/mongrel/con
figurator.rb:50:in `call'
        from c:/ruby18/lib/ruby/gems/1.8/gems/mongrel-1.1.5-x86-mswin32-60/lib/mongrel/con
figurator.rb:50:in `initialize'
         ... 14 levels...
        from c:/ruby18/lib/ruby/gems/1.8/gems/rails-2.1.0/lib/commands/server.rb:39
        from c:/ruby18/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in
`gem_origin
al_require'
        from c:/ruby18/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in
`require'
        from script/server:3

-- 
[]'s

Fabio Akita (www.akitaonrails.com)
Ruby on Rails Product Manager
Locaweb - Keep IT Simple.

From luislavena at gmail.com  Mon Jul 28 17:48:42 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Mon, 28 Jul 2008 23:48:42 +0200
Subject: [Rubyinstaller-devel] Problem with Mongrel
In-Reply-To: <43bfd1100807281434h270cf6e2kb9a1c8cb18660992@mail.gmail.com>
References: <43bfd1100807281434h270cf6e2kb9a1c8cb18660992@mail.gmail.com>
Message-ID: <71166b3b0807281448o6f0db5bcibcfba4c2b8265390@mail.gmail.com>

On Mon, Jul 28, 2008 at 11:34 PM, Fabio Akita <fabioakita at gmail.com> wrote:
> I am running the new ruby installer and I installed  the several
> win32utils after mongrel complained about win32-service. But even
> after that I am unable to start  mongrel. That's the error:
>

The problem is that you forced the installation of mongrel with
platform mswin32 and at that time 1.1 was full of problems related to
MinGW.

I backported the fixes from 1.2 branch into 1.1 and released a binary
1.1.5 mingw32 version of the gem.

You can now safely remove that gem and install mongrel with "gem
install mongrel" and will install the mingw build instead.

> c:/ruby18/lib/ruby/gems/1.8/gems/mongrel-1.1.5-x86-mswin32-60/lib/mongrel/configurator.rb:
> 372:in `trap': unsupported signal SIGUSR1 (ArgumentError)

Moreover, you must be careful about forcing the installation of gems
not built for the specific platform. Even mswin32 states is 100%
compatible with mingw32, they sometimes segfaults.

win32-service is mongrel_service depedency and not mongrel itself, you
can force mongrel_service to install without issues since it doesn't
contain any regexp related to RUBY_PLATFORM (which was the problem
you're getting before).

HTH,
-- 
Luis Lavena
AREA 17
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams