so i need to compile a bunch of stuff on windows. some third party stuff and
ruby extensions to those third party libs. everything i do __must__ be
compatible with the one-click installer, here's what i'm thinking might be a
good approach:
assumption : i've read that the latest one-click installer is compatible with
mingw output
assumption : all extensions and libs in question compile under mingw
step one : configure a ruby from the __same__ sources used for one-click
installer using something like
This is close to how I build the ruby-postgres win32 gem. I have
MingW and MSYS installed, which I used to build, *and install* ruby
1.8.4. simple as:
./configure --prefix=c:/mingw/ruby
make
make install
this keeps the two ruby installs seperate.
and to build the extension:
export PATH="c:/mingw/ruby/bin:$PATH"
cd to/ruby/extension
ruby extconf.rb
make
gem build *.gemspec
to install the extension (to the one-click installer ruby in c:/ruby),
I open up a new term, which has c:/ruby/bin in the $PATH, and run `gem
install ...`. In your case, you would run `make install`, which
should install to your one-click installation. I run all of this from
an MSYS term, except for the last step of installing to one-click
ruby, where I use a windows command term.
Dave
···
On 4/8/06, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> wrote:
so i need to compile a bunch of stuff on windows. some third party stuff and
ruby extensions to those third party libs. everything i do __must__ be
compatible with the one-click installer, here's what i'm thinking might be a
good approach:
[snip]
has anyone done anything like this? does it sound resonable?
so i need to compile a bunch of stuff on windows. some third party stuff
and ruby extensions to those third party libs. everything i do __must__ be
compatible with the one-click installer, here's what i'm thinking might be a
good approach:
[...]
step four : clobber the one-click installer's rbconfig.rb with the one
just created! the idea here is that this rbconfig can be used to
ruby ./extconf.rb
and create a Makefile that will be setup for the mingw toolchain but
producing output that will be compatible with the vc++ compiled one-click
ruby
step five : compile any third party libs using mingw
step six : compile any ruby extensions against these as normal
has anyone done anything like this? does it sound resonable?
A couple years ago I proceeded similarly to build ruby-serialport: actually, I
built and installed (separately) ruby under msys, and then copied the
extensions so the one-click build would see them, but that's largely
equivalent to what you described. That was with an older one-click distro
before Curt began building it against an incompatible runtime (so the
situation was the same as now, after the shift to the mswin32 build).
In the past, I also cross-compiled PDCurses, the curses extension,
GraphicsMagick, etc... It sometimes required some ad-hoc modifications in the
build systems, but none took more than ~10-15 minutes and they would have
been easy to script had I wanted to automate builds.
···
On Sun, Apr 09, 2006 at 01:36:06AM +0900, ara.t.howard@noaa.gov wrote:
so i need to compile a bunch of stuff on windows. some third party
stuff and
ruby extensions to those third party libs. everything i do __must__ be
compatible with the one-click installer, here's what i'm thinking might
be a
good approach:
You are using MSYS right?
I can get this to compile ruby, but it will not run webrick, it just
returns to the command prompt.
seems like i'm on the right track. the only drawback i can see to this
approach is that any third party lib must also compile against the
'cygwin-less' mingw setup (or a pure mingw setup) and that's quite a hope
thanks for the info.
fyi. i just got narray to compile for the one-click using this approach.
-a
···
On Sun, 9 Apr 2006, Dave Lee wrote:
On 4/8/06, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> wrote:
so i need to compile a bunch of stuff on windows. some third party stuff and
ruby extensions to those third party libs. everything i do __must__ be
compatible with the one-click installer, here's what i'm thinking might be a
good approach:
[snip]
has anyone done anything like this? does it sound resonable?
This is close to how I build the ruby-postgres win32 gem. I have
MingW and MSYS installed, which I used to build, *and install* ruby
1.8.4. simple as:
./configure --prefix=c:/mingw/ruby
make
make install
this keeps the two ruby installs seperate.
and to build the extension:
export PATH="c:/mingw/ruby/bin:$PATH"
cd to/ruby/extension
ruby extconf.rb
make
gem build *.gemspec
to install the extension (to the one-click installer ruby in c:/ruby), I
open up a new term, which has c:/ruby/bin in the $PATH, and run `gem install
...`. In your case, you would run `make install`, which should install to
your one-click installation. I run all of this from an MSYS term, except
for the last step of installing to one-click ruby, where I use a windows
command term.
--
be kind whenever possible... it is always possible.
- h.h. the 14th dali lama
have you done this against the __latest__ one-click installer? my libs are
blowing up with bad entry points!?
-a
···
On Sun, 9 Apr 2006, Dave Lee wrote:
On 4/8/06, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> wrote:
so i need to compile a bunch of stuff on windows. some third party stuff and
ruby extensions to those third party libs. everything i do __must__ be
compatible with the one-click installer, here's what i'm thinking might be a
good approach:
[snip]
has anyone done anything like this? does it sound resonable?
This is close to how I build the ruby-postgres win32 gem. I have
MingW and MSYS installed, which I used to build, *and install* ruby
1.8.4. simple as:
./configure --prefix=c:/mingw/ruby
make
make install
this keeps the two ruby installs seperate.
and to build the extension:
export PATH="c:/mingw/ruby/bin:$PATH"
cd to/ruby/extension
ruby extconf.rb
make
gem build *.gemspec
to install the extension (to the one-click installer ruby in c:/ruby),
I open up a new term, which has c:/ruby/bin in the $PATH, and run `gem
install ...`. In your case, you would run `make install`, which
should install to your one-click installation. I run all of this from
an MSYS term, except for the last step of installing to one-click
ruby, where I use a windows command term.
--
be kind whenever possible... it is always possible.
- h.h. the 14th dali lama
this is due to threading issues on windows i think. i've successfully
compiled ruby, gsl, narray, and rb-gsl using this approach now. the gsl
binaries are here now
i plan to write this up soon. i'll test webrick on my platform soon.
regards.
-a
···
On Fri, 23 Jun 2006, Kris Leech wrote:
unknown wrote:
so i need to compile a bunch of stuff on windows. some third party
stuff and
ruby extensions to those third party libs. everything i do __must__ be
compatible with the one-click installer, here's what i'm thinking might
be a
good approach:
You are using MSYS right?
I can get this to compile ruby, but it will not run webrick, it just returns
to the command prompt.
--
suffering increases your inner strength. also, the wishing for suffering
makes the suffering disappear.
- h.h. the 14th dali lama
Ara, I've had conflisting reports about the compatibility of mingw and
vc++6. So, I don't really know the answer.
The compiler situation under Windows has become a miniature nightmare. The
current release (one its goes final) will be the last one built with vc++.
Starting with whatever Matz releases this Xmas, I'm going to move to mingw.
Curt
···
On 6/23/06, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> wrote:
On Fri, 23 Jun 2006, Kris Leech wrote:
> unknown wrote:
>> so i need to compile a bunch of stuff on windows. some third party
>> stuff and
>> ruby extensions to those third party libs. everything i do __must__ be
>> compatible with the one-click installer, here's what i'm thinking might
>> be a
>> good approach:
>>
>
> You are using MSYS right?
>
> I can get this to compile ruby, but it will not run webrick, it just
returns
> to the command prompt.
this is due to threading issues on windows i think. i've successfully
compiled ruby, gsl, narray, and rb-gsl using this approach now. the gsl
binaries are here now
I understand from http://eigenclass.org/hiki.rb?ruby+1.8.5+release+schedule that our
next release will show up in August. It may sound crazy, but I'd
rather see no 1.8.4 stable OCI on VC6 with a ming or current VC++
version (now that the compiler is freely available) release in August.
If an OCI is released, extensions will have to support it given the
size of the OCI user base. VC6 is no longer available and there are
significant compatibility issues not among the VC++ versions and
mingw. If we switch to yet another compiler as early as August or even
as early as Christmas 2006 for that matter, we experience the
compatibility issue all over again. It is not out of the question that
a user would have to select one of three binary versions of an
extension just to get it running on their installed OCI which, to my
mind, is unacceptable.
This is the problem. vc++6 is no longer available, yet nearly all of the
binary extensions are only available in vc++6. Last year's disaster with
vc++7 is why we returned to vc++6. However its lack of availability and the
realization that this will be an ongoing problem is why we'll be going with
mingw.
However, I was not aware (until now) of the 1.8.5 schedule. That is too soon
for a mingw release (too much work to be be done and not enough time). If
that happens, then 1.8.5 would also be a vc++6 release.
Curt
···
On 6/23/06, John-Mason P. Shackelford <jpshack@gmail.com> wrote:
I understand from http://eigenclass.org/hiki.rb?ruby+1.8.5+release+schedule that our
next release will show up in August. It may sound crazy, but I'd
rather see no 1.8.4 stable OCI on VC6 with a ming or current VC++
version (now that the compiler is freely available) release in August.
If an OCI is released, extensions will have to support it given the
size of the OCI user base. VC6 is no longer available and there are
significant compatibility issues not among the VC++ versions and
mingw. If we switch to yet another compiler as early as August or even
as early as Christmas 2006 for that matter, we experience the
compatibility issue all over again. It is not out of the question that
a user would have to select one of three binary versions of an
extension just to get it running on their installed OCI which, to my
mind, is unacceptable.
