OK, this is what I mean. I save the following file (attached also) as Merlin/Main/Languages/Ruby/mspec-debug.rb:
RUBY_EXE = 'd:/dev/ruby/ironruby/current/Merlin/Main/Bin/debug/ir.exe'
$:.unshift 'd:/dev/ruby/mspec/lib'
require 'mspec/commands/mspec-run'
require 'mspec'
class MSpecScript
set :target, RUBY_EXE
set :flags, [ ' -D']
set :ci_files, ["rubyspec/1.8/core",]
set :tags_patterns, [
[%r(rubyspec/), 'ironruby-tags/'],
[/_spec.rb$/, '_tags.txt']
]
end
MSpecRun.main
Once you have modified the paths for your setup, you can then run this file
just like mspec-run:
/path/to/ir.exe mspec-debug.rb /path/to/rubyspec/some_spec.rb
In the VS Ruby.Console project properties I set the following:
Start Action: Start Project
Start Options:
Command Line Options: -D mspec-debug.rb -V
d:/dev/ruby/rubyspec/core/fixnum/abs_spec.rb
Working Directory:
D:\dev\ruby\ironruby\current\Merlin\Main\Languages\Ruby\
Then I can set breakpoints in the C# code to debug and so on.
This solution is self contained, doesn't require any environment variables,
doesn't spawn any sub processes and doesn't rely on mspec guessing the ruby
engine. I personally don't feel that it uses too much of the internals of
mspec: the configuration bits are public interfaces to mspec and all we are
doing is including a couple of files (that are unlikely to change name) and
running a single class method.
Let me know what you think.
Pete
mspec-debug.rb
Description: Binary data
_______________________________________________ Ironruby-core mailing list [email protected] http://rubyforge.org/mailman/listinfo/ironruby-core
