Re: [xml] Release of libxml2-2.4.11

[Thomas Krebs <Thomas_Krebs gmx de>]

Igor Zlatkovic schrieb:

...

> You are right, one set is too much. The set in win32/dsp is the one to use.
> Everything else is old and exists just to cover people who may still depend
> on it. By now, I am not aware of anyone who uses these old files anymore.
> We'll have these go away in the near future.

Ok.

> > - Wouldn't it be better to distribute libxml2 and libxslt as one package
> >   as it would help configuring/compiling/using it much?
>
> I see those as two different things. It might be subjective, of course, but
> I fail to see the consumer's benefit from putting these in one package.

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.

> > - Why is the code for libxml2 and its applications (testDocbook,
> >   testHTML, testSAX, testURI, testXPath and xmllint) not structured in
> >   directories for the code for the library and applications as it is
> >   done (much better in my opinion) in libxslt?
>
> The world is not perfect :-)

So let's make it better.

> > - The project files for libxml2/libxslt are set up for using dlls
> >   mainly. I (and not only I) think that dlls are highly overrated.
>
> Well, I don't. I prefer shared libraries to static ones, I am very close to
> unconditionally requiring them whenever the same library is used by more
> than one program on a productive system. Whatever my opinion, you are free
> to use whichever you like in your programs, nothing forces a dynamic link.

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

> >   Furthermore the project files are not easy to switch between
> >   dynamic/static linking.
>
> You mean xmllint and friends? Yes, one must modify project files to have
> these link statically. What do you suggest?

I would suggest two workspace files containing the relevant project
files
one for static and one for dynamic linking. (Dynamic linking of the C
lib
is quite ok)

> >   In general it is not possible (in MSVC 6.0)
> >   to have one set of project files for dynamic and static linking.
>
> Of course it is possible. It is just that these cannot be made by using the
> predefined click-next-click-finish wizardry.

Ok, I was not precise enough here:
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.
An application though can link statically or dynamically in one project
file by changing the configuration.

> >   Also I would put the project files into the directories where the
> >   relevant code is like yu do it with other makefiles as well.
>
> Well, having them in a subdirectory is not a showstopper for me :-)

Nor is it for me.

> Seriously, MSVC project files don't remain compatible between IDE versions.
> Those made for with one IDE version cannot be used with the next without
> conversion. Conversion done automatically by the IDE is not always without
> loss, specifically when you have highly customised project files (like those
> which do it dynamically and statically in a single build run, for example),
> so you keep more versions around. With the upcoming MSVC 7 we'll have
> another set to maintain until the light of MSVC 6 extinguishes. Perhaps all
> this mess is better organised in a subdirectory.

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.

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

Thomas