On Feb 6, 2007, at 5:20 PM, Tim Ellison wrote:
Geir Magnusson Jr. wrote:
On Feb 6, 2007, at 12:17 PM, Tim Ellison wrote:
Ronald Servant wrote:
On 2/5/07, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
And why did you decide this was better than #1?
I didn't. This could be considered step 1 towards doing #1.
Producing this patch was much quicker than trying to cease all
use of
the port lib in the launcher.
Having said that, I'm not convinced that #1 is the real answer
either.
<snip>
This is a good step forward. It will relieve our immediate pain of
colliding classlib/drlvm/VME threadlibs. We can then take a
breather
and think again about how to bootstrap the portlib for use by the
launcher, but the overhead of this solution is ok for now.
This isn't about it not being a good step forward, but rather why not
examine the other solution. I always think modifying paths is a hack,
compared to deliberately loading the library, for example
The first option was to avoid the port library dependency in the
launcher code, that seems to be what Ron is proposing by
duplicating the
required functions -- i.e. I think he is doing more of #1 than #2 <g>
Both #1 and #2 avoided the dep as far as figuring out where the lib
was located, but I thought #1 then used it after it found it. That
seems cleaner, I guess. I'm going to look at the patch and see how
hard the alternative is.
Whatever the number, it is IMO a reasonable solution to the main
problem
of refactoring the access to the threadlib. We can then refine the
way
the launcher picks up the library if necessary.
Tim
