Re: [xml] Release of libxml2-2.4.11



Hi there.

On Tue, 27 Nov 2001, Thomas Krebs wrote:

Hello,
I'm interested in libxm2 and I'm on this email exploder since quite a
long time. I have compiled successfully libxml2 (and libxslt) since
2.4.1 under MSVC.

Me too :-)

- Why do you distribute two sets of dsp/dsw files for MSVC? I think this
  confuses more than it helps.

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.

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

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

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

  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?

  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.

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


Ciao
Igor




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