Re: [xml] RE: [xslt] small fix needed for win32

[ I really don't understand why I didn't sent that message last Tuesday
  I was wondering why I didn't got an answer ... Seems it was never sent ...
  Oops, Daniel ]

On Tue, Mar 12, 2002 at 09:43:32AM +0100, Igor Zlatkovic wrote:
Good Morning Ladies and Gentlemen, Boys and Girls.

  xmllint.c actually includes "libxml.h", but I din't changed that
in the last 2 months.
  If Igor could look at this and see if this or what need patching
that would be the best.

  Yes! Last time we discussed this topic, you sounded... well, a bit
oversensitive :-) I think it was due to stup... ehem... pressure in another,
unrelated post thread. With time, you got your new coffee machine and calmed
down, but I forgot to rise the topic again :-)

  Haha, I got a single cup of coffee this morning, maybe we can reach an
agreement (or try to ;-)

  It is not just xmllint, but also xsltproc and several other programs as
well. The fact is, IN_LIBXML must not be defined when compiling xmllint.
Xmlint is just like any other client program and if client code defines
IN_LIBXML, the build will fail. Either libxml.h must loose the line that
reads #define IN_LIBXML, or xmllint may never include this file. The same
goes for xsltproc and libxslt.

  I'm tempted by an intermediate approach:
    - all source shipped as part of the distribution do #include "libxml.h"
      or "libxslt.h"
    - the files which are actually part of that library explicitely
      have #define IN_LIBXML before including it
    - the #define IN_LIBXML is removed from the header itself.

  What I didn't understand back then, and still don't understand, why must
IN_LIBXML be manually defined in the internal header file? Why is defining
it on the compiler command line not sufficient? If its definition is removed
from libxml.h, xmllint can perfectly reuse libxml internal headers to
improve its own portability.

  Because this put the reliability of that solution outside the code
itself back to the "Makefile" level, and Makefiles are already enough
of a PITA to maintain that I far far prefer a source oriented solution.

  Would the suggestion given work for you ? If yes I will apply it.


P.S. I assume the last release didn't worked "out of the box" anyway since
     the new c14n module was added and I didn't integrated any patch from
     you about this ;-)

Daniel Veillard      | Red Hat Network
veillard redhat com  | libxml Gnome XML XSLT toolkit | Rpmfind RPM search engine

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