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

[Igor Zlatkovic <igor zlatkovic com>]

Joel Reed wrote:
> I would like to address this issue specifically. it seemed to me
> that most projects with plugins or modules, have one or two application
> specific directories from which they will load such plugins or modules.
> this path is determined at compile time.

Only on Unix. No program that I know of on Windows has ever done this.

> for example: 
>   /usr/lib/gimp/2.0/modules/
>   /usr/lib/apache/1.3/
>  
> i was planning on win32 to hack configure.js such that if you enable
> modules, you would be warned/reminded that the "prefix" setting takes on
> much greater importance in that it is used to construct the path from
> which plugins or modules are loaded. i was envisioning perhaps even
> requiring prefix to be set if you enable modules on win32.

That would not be good. Most people have their own visions about where 
on the disc their tools should be. How am I to produce a working binary 
distribution if I must hardcode my paths into it? I doubt a lot of 
people have, or wish to have their libxml2 sitting in C:\Opt\FSW\

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?

Ciao,
Igor