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

[Daniel Veillard <veillard redhat com>]

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

Daniel

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 https://rhn.redhat.com/
veillard@redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/