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

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.


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