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

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/
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?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]