um Blizz... I got ruby 2 to build dynamically WITHOUT removing all the extensions with this configure line
mkdir build
cd build
..\win32\configure.bat --target=i386-mswin32 --disable-win95 --disable-install-doc --disable-debug-env --disable-rubygems --without-ext="tcl,tk,win32ole,sdbm,dbm,curses,fiddle,gdbm,openssl,pty,readline,syslog" --so-name=ruby200
nmake
as long as you respect the capatals in the ext/Setupfile ie Win32API not win32api
it works fine
it even produces a ruby200.lib that I tested linking liblegacy and libreactor too and it worked.
I ran the reaulting exe and added these lines to the bottom of RMXP.rb in the Data folder
greeting = "\n[ruby] Useing Ruby '#{RUBY_VERSION}' built for '#{RUBY_PLATFORM}' released on '#{RUBY_RELEASE_DATE}'\n"
puts greeting
the result
[april] Initializing APRIL.
[april] Using: DirectX9, Win32
[april] Creating rendersystem: 'DirectX9' (options: '')
[april] Creating window: 'Win32' (640, 480), 'Chronicles of Sir Lag-A-Lot' fulls
creen : no
[april] Window activated.
[atres] Initializing Atres.
[atresttf] Initializing AtresTTF
[aprilui] Initializing AprilUI.
[xal] Initializing XAL.
[xal] Initializing DirectSound.
[xal] Audio system created: DirectSound
[xal] Starting audio update thread.
[reactor] Initializing ARC Reactor Engine.
[legacy] Initializing Legacy RGSS.
[reactor]
[ruby] Useing Ruby '2.0.0' built for 'i386-mswin32_110' released on '2013-02-24'
now I cant build with zlib support simply because I don't have the source for zlib ect. so...
I DID have to stop the inclusion of the ruby/extentions.h you made and comment out the lines that started up those extensions so I'm not sure what we have to do about that
also, we we going to change the board names now that the engine name has been changed?
1. Yes, I'll change the board names right away.
2. If you download the Ruby source, you will notice that there is no Win32API extension. I'm not sure where it's pulling that one from, but it's also the wrong one. win32api is that alternate implementation because Win32API is deprecated and is going to be removed. I'm actually surprised that they didn't remove it in 2.0.0 yet.
3. Since next Ruby versions might have a different set of extensions, I prefer to remove them all so they don't get built rather than using --without-ext.
4. I added zlib.h and zconf.h in the 2.0.0 ext directory so you should technically be able to build zlib now.
5. ruby/extensions.h was only for some extern declarations of the initializers for win32api, socket and zlib since they are statically linked. Technically I would have just added the prototypes in reactor.cpp, but this way it's easier to edit. If you had to do that, it is likely that the compiled extensions could not be loaded or that this build of Ruby was actually able to statically already load these extensions (which it actually should if you compiled with --with-static-linked-ext, but yeah).
BUT WAIT! Does this mean that you successfully built Ruby 2.0.0 dynamically with all extensions already included?
Quote from: Blizzard on February 26, 2013, 02:35:38 am
BUT WAIT! Does this mean that you successfully built Ruby 2.0.0 dynamically with all extensions already included?
yes, I only removed the extensions with the --without-ext option and it built perfectly just be sure to use the generated config.h when linking to it.
I'll try it today then.
ok I ran through every extension and everyone but these
tcl, tk, win32ole, dbm, sdbm, gdbm, curses, syslog, pty, racc, ripper, coverage, probe, readline, fiddle
could conceivably be used by a scripted in a game
so I went and removed their folder from the ext/ folder and compiled ruby like so
(I put you zlib files in c:/lib/zlib/zlib-blizz header and dll + lib and compiled openssl myself to c:/lib/openssl/openssl101e)
C:\lib\ruby\ruby-2.0.0-p0\build>..\win32\configure.bat --target=i386-mswin32 --disable-win95 --disable-install-doc --disable-debug-env --disable-rubygems --without-ext="tcl,tk,win32ole,dbm,sdbm,gdbm,curses,syslog,pty,racc,ripper,coverage,probe,readline,fiddle" --so-name=ruby200 --prefix=c:/lib/ruby/ruby200 --with-openssl-dir=c:/lib/openssl/openssl101e --with-zlib-include=c:/lib/zlib/zlib-blizz --with-zlib-lib=c:/lib/zlib/zlib-blizz
it compiled perfectly and nmake test passed
I've put a zip file in the Dropbox with the compiled ruby it has the header files necessary, the lib files, and all the dll files (zlib, openssl, ruby)
this SHOULD let us link properly
EDIT:
I got curious so I did a benchmark, you might find this interesting. apparently GCC STILL out performs MSVC in the speed of the compiled code even in 2012.
C:\Users\Ryexander\Desktop>pik bench binary-trees.rb
ruby 1.8.7 (2012-10-12 patchlevel 371) [i386-mingw32]
Rehearsal ---------------------------------------------------------------------
** benchmarking 'binary-trees.rb' stretch tree of depth 17 check: -1
131072 trees of depth 4 check: -131072
32768 trees of depth 6 check: -32768
8192 trees of depth 8 check: -8192
2048 trees of depth 10 check: -2048
512 trees of depth 12 check: -512
128 trees of depth 14 check: -128
32 trees of depth 16 check: -32
long lived tree of depth 16 check: -1
30.498000 0.234000 30.732000 ( 30.780760)
----------------------------------------------------------- total: 30.732000sec
user system total real
** benchmarking 'binary-trees.rb' stretch tree of depth 17 check: -1
131072 trees of depth 4 check: -131072
32768 trees of depth 6 check: -32768
8192 trees of depth 8 check: -8192
2048 trees of depth 10 check: -2048
512 trees of depth 12 check: -512
128 trees of depth 14 check: -128
32 trees of depth 16 check: -32
long lived tree of depth 16 check: -1
31.232000 0.141000 31.373000 ( 31.384795)
ruby 1.9.3p194 (2012-04-20) [i386-mingw32]
Rehearsal ---------------------------------------------------------------------
** benchmarking 'binary-trees.rb' stretch tree of depth 17 check: -1
131072 trees of depth 4 check: -131072
32768 trees of depth 6 check: -32768
8192 trees of depth 8 check: -8192
2048 trees of depth 10 check: -2048
512 trees of depth 12 check: -512
128 trees of depth 14 check: -128
32 trees of depth 16 check: -32
long lived tree of depth 16 check: -1
9.610000 0.015000 9.625000 ( 9.608549)
------------------------------------------------------------ total: 9.625000sec
user system total real
** benchmarking 'binary-trees.rb' stretch tree of depth 17 check: -1
131072 trees of depth 4 check: -131072
32768 trees of depth 6 check: -32768
8192 trees of depth 8 check: -8192
2048 trees of depth 10 check: -2048
512 trees of depth 12 check: -512
128 trees of depth 14 check: -128
32 trees of depth 16 check: -32
long lived tree of depth 16 check: -1
9.235000 0.000000 9.235000 ( 9.249529)
ruby 2.0.0p0 (2013-02-24) [i386-mingw32]
Rehearsal ---------------------------------------------------------------------
** benchmarking 'binary-trees.rb' stretch tree of depth 17 check: -1
131072 trees of depth 4 check: -131072
32768 trees of depth 6 check: -32768
8192 trees of depth 8 check: -8192
2048 trees of depth 10 check: -2048
512 trees of depth 12 check: -512
128 trees of depth 14 check: -128
32 trees of depth 16 check: -32
long lived tree of depth 16 check: -1
7.379000 0.249000 7.628000 ( 7.664438)
------------------------------------------------------------ total: 7.628000sec
user system total real
** benchmarking 'binary-trees.rb' stretch tree of depth 17 check: -1
131072 trees of depth 4 check: -131072
32768 trees of depth 6 check: -32768
8192 trees of depth 8 check: -8192
2048 trees of depth 10 check: -2048
512 trees of depth 12 check: -512
128 trees of depth 14 check: -128
32 trees of depth 16 check: -32
long lived tree of depth 16 check: -1
7.520000 0.015000 7.535000 ( 7.541432)
ruby 2.0.0p0 (2013-02-24) [i386-mswin32_110]
Rehearsal ---------------------------------------------------------------------
** benchmarking 'binary-trees.rb' stretch tree of depth 17 check: -1
131072 trees of depth 4 check: -131072
32768 trees of depth 6 check: -32768
8192 trees of depth 8 check: -8192
2048 trees of depth 10 check: -2048
512 trees of depth 12 check: -512
128 trees of depth 14 check: -128
32 trees of depth 16 check: -32
long lived tree of depth 16 check: -1
12.277000 0.016000 12.293000 ( 12.288703)
----------------------------------------------------------- total: 12.293000sec
user system total real
** benchmarking 'binary-trees.rb' stretch tree of depth 17 check: -1
131072 trees of depth 4 check: -131072
32768 trees of depth 6 check: -32768
8192 trees of depth 8 check: -8192
2048 trees of depth 10 check: -2048
512 trees of depth 12 check: -512
128 trees of depth 14 check: -128
32 trees of depth 16 check: -32
long lived tree of depth 16 check: -1
13.323000 0.000000 13.323000 ( 13.331763)
I would like to avoid cluttering the default binary with stuff that 99% of the users won't use. If they really need it, they can compile an .so and use "require". Win32API and zlib are used by some substantial scripts that a lot of people use. socket is only there so people don't have to rewrite default functionality.
but a LOT of the other extensions are very important hence why they are ruby's STANDARD LIBRARY
fiber and possible
date for example is obviously important if your dealing with ANY of the advanced save file systems
dl believe it or not is a ext for calling in to dlls so it's key
etc deals with host OS properties so it could be very usefull
io is a MUST if you want to open files or any io stream
JSON might not be necessary but it can be useful and helpful
nkf is unnecessary if any eastern culture wants to use their native language
mathn is ruby's MATH module your not really thinking of not including THAT are you?
objspace is ruby 2 new interface to the GC
pathname is a filesystem path module for the OS
ruby's string.crypt requires digest
ect.
I'm not including these ext willy nilly Blizz
the only ones you could truly do away with is openssl, fcntl (calling into .so), and fiber
there isn't much cluttering of the binary going on here.
now obviously we really need to build statically so we don't have to lug around all those so's I'm regularly testing the static build with the ruby-trunk, as soon it builds I'll let you know.
I think that a big deal of these are already included. How else would I be able to run CoSLAL on ARC which uses Math functions if mathn wasn't available?
These might be advanced exts. In any case, compiling Ruby is a mess. You have no freaking idea what goes in and what not. :/
Try compiling it without those exts and then try to use them. Let's see if they really aren't there.
weird, your right. I could of sworn that it fails when I tested that before.
mathn DOES contain the math module but apparently it's included automatically even if the folder is removed...
and are you SURE that
http://www.ruby-doc.org/stdlib-2.0/libdoc/dl/rdoc/Win32API.html
isn't the up to date libarry
Definitely. https://rubygems.org/gems/win32-api
This one uses a module called Win32 and a class called API. That one guy suggested it in the other thread months ago. This implementation is much better, but I added some compatibility code so it works with with old Win32API.
I think I've found the root cause of the second error that is preventing the static build form completing. details here http://bugs.ruby-lang.org/issues/7960
No, we don't need static Ruby. We need a dynamic Ruby with statically linked exts. That means that all exts are compiled statically, Ruby is compiled dynamically and all exts are actually included in that Ruby dll.
that's exactly what the problem is. that bug is about the builds with static extension failing.
it caused by the Init_ext function being redefined by the generated ectinit.c file that holds the init functions to set up the statically linked ect's
ruby pre links a dummy of this file so that the function is defined even if there are no statically linked ext's
ok, after my latest post they claim the issue is solved. I'll get the change-set and try to build with static extentions
UPDATE: it worked I added another ruby folder to the dropbox with the source for this version of ruby as well as a zipfile with the successful built statically link ext ruby and a text file with the commands I used
you will note that I didn't link to zlib because for some reason linking to zlib with static extensions gave me an error. you will probably nee to build zlib special to do that.
zlib requires the original zlib.lib and zlib.dll in order to successfully link. If you have a statically compiled zlib.lib for Ruby, it's fine, I can work with that.
EDIT: BTW, there is something that needs to be taken into account. We need to build this with VS2012 with Update 1 so it can run on XP machines. you have to make sure that not the "v110" toolset is used but the "v110_xp".