[Insight-developers] Re: [Fwd: Re: [slicer-devel] Slicer3 on darwin-ppc]

[Luis Ibanez]

Before we make any further changes I would strongly suggest that
we add specific tests for this functionality.

It is *not acceptable* to make changes in the Toolkit that are
not validated in the Dashboard. We cannot be at the mercy of
whether someone tries a particular functionality of the toolkit
or not.

 From the ITK advanced course we have code that can be converted
into a test for loading dynamic libraries. We could start with
that code. It is in the NAMICSandbox under the directory:

NAMICSandBox/trunk/ITKAdvancedCourse/src/Exercises/exercise29

If any of you have code that can be converted in to a nightly
test, please let me know, it will be great to have multiple
tests for this functionality.



   Thanks


      Luis




========================
Mathieu Malaterre wrote:
> Ok this thing is nasty. In VTK, DynamicLoader was changed so that it
> would load .so file:
> http://public.kitware.com/cgi-bin/viewcvs.cgi/Common/vtkDynamicLoader.cxx?r1=1.16&r2=1.17 
> 
> 
> Bill did the exact contrary in ITK
> http://public.kitware.com/cgi-bin/viewcvs.cgi/Code/Common/itkDynamicLoader.cxx?root=Insight&r1=1.15&r2=1.16 
> 
> 
> So the question is: what do we want to load: MODULE or LIBRARY ? I
> guess we could change the implementation of DynamicLoader, to have a
> new function:
> DynamicLoader::SetModeToModule/Library()
> 
> and the ITK would set to Module while the VTK one would set to Library
> (to preserve backward compat.).
> 
> I can volunteer for implementing this.
> 
> Comments welcome
> Mathieu
> 
> On 30 Nov 2006 19:02:25 -0500, Neil Weisenfeld <neil at bwh.harvard.edu> 
> wrote:
> 
>> Sorry to say this, but your changes to DynamicLoader.cxx do not include
>> the changes necessary for LibPrefix and LibExtension to work properly on
>> the platform.
>>
>> LibPrefix needs to return "" and LibSuffix needs to return ".dylib"
>>
>> I did this in version 1.21 of Code/Common/itkDynamicLoader.cxx
>>
>> Sadly, I don't think that dashboard tests will pick this up, but it will
>> result in plugins not being found from ITK_AUTOLOAD_PATH.
>>
>>
>> Neil
>>
>>
>>
>> Mathieu Malaterre wrote:
>> >> Note that fixing the kwsys version in ITK doesn't fix itkDynamicLoader
>> >> -- I'm not sure where the kwsys version gets used, but not by the I/O
>> >> factories (unless I'm missing something).
>> >
>> > Ok this is also fixed. For some reason the code was copy/paste instead
>> > of reused. The API was not touched, only the implementation is now
>> > forwarding call to the kwsys implementation.
>> >
>> >
>> > -M
>>
> 
>