Re: [xslt] [PATCH] xslt extensions as modules/dso's

[Mark Vakoc <thevakoc-xml yahoo com>]

--- Igor Zlatkovic <igor zlatkovic com> wrote:
> Better would be to look for the modules relative to the location of the 
> libxml2 library. GCC on Windows does this to find its bits. Call 
> GetModuleFileName API to discover where on the disc libxml resides, then 
> look for modules at ../lib/libxml from there, for example. Is that 
> acceptable?
> 

So a program installed to "c:\Program Files\My Application\MyApp.exe" would
need "c:\Program Files\lib\libxml" to contain the dynamic libraries?  Very
ugly.  I don't really like any of this, but to me a better solution for Win32
would be to use "./plugins" or something similar with the relative path being
to libxml2.  

Now if libxml2 is built staticly the GetModuleFileName would have pass NULL for
the first parameter to get the path of the calling EXE.  If libxml2 is built as
a dll it would have to add a call to GetModuleHandle("libxml2.dll") then pass
that to GetModuleFilename.  If someone builds libxml2 but uses a different
name, such as "libxml2.2.0.52.dll" for the library they are SOL because that
name isn't known at compile time.

And now what about modules for libxslt?  I can see modules being used by
libxml2 to add support for custom i/o handlers, and modules being loaded by
libxslt to add xslt extensions.  These should be relative to the libxslt binary
(or staticly compiled in executable).  

This seems to be making a mess.