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

Hello there,

On Sat, 16 Mar 2002, Daniel Veillard wrote:

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

And I was wondering why I haven't received anything. I turned my mailbox
upside-down, peeked at my mail server's logs, measured the voltage on my
internet wire... :-)

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

Hehe, I got a headache this morning, a legacy of my favourite alcoholic
beverage I consumed last evening. I'll agree upon anything now :-) My
grandpa always said: 'Boy, your every day shall begin with what you prepared
for it yesterday.', but I wouldn't listen :-)

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

This would be perfectly okay. The way things fare on my platform, IN_LIBXML
must be defined when compiling the library, but must not be defined when
compiling client code. What you suggest above would give exactly that.

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

Okay, I must admit that your makefile is far, far more complicated than
mine. Actually, when I look at it, this IN_LIBXML macro and its libxslt
equivalents are being used by several platforms now, few of which do not
share the same makefiles. A source-based solution suddenly sounds better.

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

It would. Every solution which ensures that IN_LIBXML is defined in libxml,
but not defined in xmllint works here.

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

Don't stick a finger in an aching wound :-) I have installed MS Visual
Studio 7.0 (.NET) IDE last week, a successor to what I have been using so
far. It proved to be a nice idea for those commited to .NET development, but
a grave error for the folk who worship C/C++.

The new C/C++ build environment has several issues I cannot live with. There
is a lot to it, and I shall post a separate message explaining all of it,
but the fact is that I have no use for it. I am now investigating another
build process, using solely the MS command-line development tools, which
seem to have a lot more functionality without the IDE. You will have the
c14n patches, if any are needed, as soon I set that up.

While we are at it, does anyone know how to generate dependences
automatically on Windows, without the IDE? I mean the thing 'gcc -M' would


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