There are two scenarios: 1. You need to recompile it when the compiler used by ruby changes. 2. You need to reapply the patch and then recompile whenever changes have been made to the original win32ole.c code.
I would need to do some research to find out which versions of Ruby have had one of these two events. Bret On Sun, Jan 16, 2011 at 11:20 PM, Tim Koopmans <tim.ko...@gmail.com> wrote: > That's what I'm thinking, since majority of modal test cases work for me in > 1.8.7 ... > > Cheers, > Tim > > > > On Mon, Jan 17, 2011 at 3:52 PM, Jarmo <jarm...@gmail.com> wrote: > >> I was wondering, do you even have to recompile it for different Ruby >> versions, which have same minor version number? At least i have understood >> that you only need to recompile binaries if the major or minor version >> number differ. E.g. you can use same binary for 1.8.6 and 1.8.7, but need to >> recompile it for 1.9.1 and 1.9.2. Am i wrong? >> >> Jarmo >> >> >> On Mon, Jan 17, 2011 at 12:55 AM, Bret Pettichord <b...@pettichord.com>wrote: >> >>> On Thu, Jan 13, 2011 at 9:07 PM, Tim Koopmans <tim.ko...@gmail.com>wrote: >>> >>>> When you say Win32OLE is patched/hacked, is that the shared object in >>>> C:\ruby187\lib\ruby\1.8\i386-mingw32 >>>> or >>>> C:\ruby187\lib\ruby\gems\1.8\gems\watir-1.7.0\lib\watir\win32ole.rb OR >>>> win32ole\win32ole.so ? >>>> >>> >>> win32ole.so is compiled from win32ole.c, which has been hacked. >>> https://github.com/bret/watir/tree/master/watir/lib/watir/win32ole >>> >>> >>>> If win32ole is the only thing holding us back, why don't we crack on >>>> with the ming compiled version and ditch 1.8.6 altogether? >>>> >>> >>> We also need to make sure that there are no baseline changes to win32ole. >>> If so, then we would need to migrate the patch to the new version of >>> win32ole before recompiling. >>> >>> If we do this we could release the result as 1.8.0. We would need to >>> update the minor version number as it would change the Ruby requirement, no >>> longer supporting what we had required previously. While we are at it, maybe >>> would should pull in some other big changes, like the zero-index code. >>> >>> As long as we depend on the current approach (hack and recompile >>> win32ole), we will have a tight binding between Watir (or at least this part >>> of Watir) and the version of Ruby we've compiled for. The question is >>> whether we want remove this technical debt. >>> >>> If we swap out the wrong version of win32ole, it might cause Watir tests >>> to fail. It could also cause other code using win32ole to fail. We don't >>> have tests for the latter case. >>> >>> Bret >>> >>> >>> On Tue, Jan 11, 2011 at 1:39 PM, Bret Pettichord <b...@pettichord.com>wrote: >>> >>>> Charley's comment and a discussion with Hugh McGowan at work have >>>> reminded me of the state of this. >>>> >>>> 1. We actually swap in our own copy of the Ruby Win32OLE library. This >>>> is C code and therefore needs to be compiled using the same compiler as >>>> Ruby. The version currently distributed with watir works with early >>>> versions >>>> of 1.8.6. I think they changed to the new compiler (ming) in the most >>>> recent >>>> versions of 1.8.6. >>>> >>>> 2. This whole approach is incredibly hacky (it was my idea). I have >>>> previously suggested that we pull this code (the showModalDialog support >>>> only) into a separate gem simply because it does these horrible things and >>>> adds these dependencies that really don't matter to many Watir users. >>>> >>>> 3. I was a bit confused, because I know we have some people using 1.8.7 >>>> at Convio, but apparently this is because Hugh hacked the version of >>>> Win32Ole to make it work. >>>> >>>> 4. Yes, Jarmo that is "the" modal dialog test. >>>> >>>> Bret >>>> >>>> On Mon, Jan 10, 2011 at 11:54 AM, Jarmo <jarm...@gmail.com> wrote: >>>> >>>>> On Mon, Jan 10, 2011 at 5:39 PM, Tim Koopmans <tim.ko...@gmail.com>wrote: >>>>> >>>>>> I've recommended 1.8.6 or 1.8.7 of Ruby but thinking of cutting this >>>>>> back to 1.8.7, pending IE modal dialog support (is there a specific unit >>>>>> test for that?) >>>>>> >>>>> >>>>> I found something at unittests\windows\modal_dialog_test.rb. I'm not >>>>> sure if that is THE modal dialog, but it seems to be. For me that test >>>>> blocks forever under Win7/XP with 1.8.6 and 1.8.7. Haven't had any time to >>>>> investigate as to why is that happening. Maybe someone else can try that >>>>> test on their machine too to see if there's any difference and maybe even >>>>> figure out the problem itself. >>>>> >>>>> Jarmo >>>>> >>>>> _______________________________________________ >>>>> Wtr-development mailing list >>>>> Wtr-development@rubyforge.org >>>>> http://rubyforge.org/mailman/listinfo/wtr-development >>>>> >>>> >>>> >>>> >>>> -- >>>> Bret Pettichord >>>> Director, Watir Project, www.watir.com >>>> >>>> Blog, www.testingwithvision.com >>>> Twitter, www.twitter.com/bpettichord >>>> >>>> >>>> _______________________________________________ >>>> Wtr-development mailing list >>>> Wtr-development@rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/wtr-development >>>> >>> >>> >>>> _______________________________________________ >>>> Wtr-development mailing list >>>> Wtr-development@rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/wtr-development >>>> >>> >>> >>> >>> -- >>> Bret Pettichord >>> Director, Watir Project, www.watir.com >>> >>> Blog, www.testingwithvision.com >>> Twitter, www.twitter.com/bpettichord >>> >>> >>> _______________________________________________ >>> Wtr-development mailing list >>> Wtr-development@rubyforge.org >>> http://rubyforge.org/mailman/listinfo/wtr-development >>> >> >> >> _______________________________________________ >> Wtr-development mailing list >> Wtr-development@rubyforge.org >> http://rubyforge.org/mailman/listinfo/wtr-development >> > > > _______________________________________________ > Wtr-development mailing list > Wtr-development@rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -- Bret Pettichord Director, Watir Project, www.watir.com Blog, www.testingwithvision.com Twitter, www.twitter.com/bpettichord
_______________________________________________ Wtr-development mailing list Wtr-development@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-development
