Re: [xml] Release of libxml2-2.4.11



On Tue, 27 Nov 2001, Thomas Krebs wrote:

It is a problem to set the proper include paths from xslt-u.v.w to
libxml2-x.y.z.
When you include both into one package this is solved. Libxml2 and
libxslt
aren't too big packages as such.

Windows port compiles from the same source as other ports do and everyone is
concerned when a change such as this is at stakes.

Just like in the European monetary system, some would welcome the union,
others would not. I personally need both libraries and wether I get the
source in one or two CVS checkouts, all the same to me :-)

I definitely think this is overrated - even MS does so - they call it
the
dll hell. Do you really guarantee the dll interface to stay the same?
(This is a real question) If no you would need to keep versions of your
dlls and keep all of them on your system if you are not absolutely sure
to replace all of your apps using the old dlls...
And with statically linking I do mean statically linking of libxml2
but not the c-library (msvcrt) of course. But I admit that you have the
choice - I simply meant making static linking of libxml2 the default.
I don't (and I think others as well) want to install the dll into
a system directory or setting the path variable to an ever changing
directory...

To DLL or not to DLL is generally a topic which causes flame wars, at least
in Windows. Let's leave it to those in comp.os.windows.* to wave their
battle axes heavenward :-)

Still, I don't quite understand what you mean by default. When you write a
program which uses libxml, you don't have a default linking. Dynamic and
static libraries are both available and you choose which one you want to
use.  Whichever it is, you have to specify it in your project. There is
nothing in libxml that defaults you to the one option or the other.

Okay, xmllint and friends link dynamically, but it is just as when you
invite a cute girl for a dinner. The waiter asks "red or white wine?", and
defaults you to none. You inquire her preference, but she leaves the choice
to you. You choose what you like and have a pleasant meal. Of course, if
what you chose was the one she dislikes, she'll have a headache later on and
say good night :-) :-)

You cannot have one project file (you can of course have any number of
project
files in one workspace file to do that) that creates a static library (a
.lib)
AND a dynamic library (an import .lib and the dll) just by changing the
configuration. You need different project files to accomplish that.

You say? One cannot mix Caipirinha and Pina Collada in the same shaker at
the same time, yes?

Of course one CAN make project files which build both the static AND the
shared library in a single run. How such project files are made is a topic
for a course on using MSVC IDE, rather than for this list.

You are right, but on the other hand you keep the various build files
for the
*NIX make process in the source code directories as well. There all of
your
arguments hold as well (configure build files also change from time to
time).
It is simply a matter of keeping things more in parallel between
*NIX/Win.
As you do things I (and other people may as well) could believe you
estimate
one platform build process over the other.

Don't see things so negative. It is not a doom, it is a privilege to have an
own subdirectory! It is to us what an own room is to a 13-year-old who would
otherwise have to share it with an older, teasing brother :-)

This constellation involving the win32 subdirectory was a part of libxml
long before I came. At the moment, this constellation simplifies updates to
MSVC project files, as they have few oddities regarding the line delimiters
and Daniel hasn't seen Windows for at least ten years, if ever :-)

This is not meant to be real critic on your work, just some feedback I
wanted
to give. Keep up the good work.

Oh, don't worry, I am used to critics. Once upon a time, I managed to choose
the wrong wine three times in turn and the critical expression of her face
still comes to haunt me at night :-) :-)


Ciao
Igor




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