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

[Igor Zlatkovic <igor zlatkovic com>]

Mark Vakoc wrote:

> 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.  

The actual path doesn't matter to me at all, as long as it isn't 
absolute and hardcoded. I just want to be able to make a binary 
distribution which will work at machines other than just mine, without 
violating someone's preference about the physical location of the 
library on the disc. In fact, I would like to move libxml on the disc 
around as I please and have it work at every location.

Imagine a team of twenty people and no two of them keep their software 
at the same physical location. If you challenge their preferences, 
they'll bite. I wish to prepare a single binary distribution that they 
all can use and not have them each compile their own.

We can use an environment variable for all I care, just please don't 
hardcode absolute paths.

> 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.

It is, since you must know the name of the DLL at compile time in order 
to build an apropriate import library. We can modify the configure.js 
script to take this name and put it at the apropriate place in the source.

> 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).  

Exactly. What was the problem there?

> This seems to be making a mess.

Which is the way we have always handled best. I don't like silicon tits 
and I don't like perfect software for the same reason. Both are the 
handwork of an expensive magician who turns the beauty of natural 
creation into a token of commercial lust.

But that we shall discuss next year. Few hours ago I have set the sun 
with the dark ale and now I'll go pass the year with some more :)

Happy new year, Mark.

Ciao,
Igor