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
give?


Ciao
Igor





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