Re: [xml] RE: [xslt] small fix needed for win32
- From: Igor Zlatkovic <igor stud fh-frankfurt de>
- To: Daniel Veillard <veillard redhat com>
- Cc: <xslt gnome org>, <xml gnome org>
- Subject: Re: [xml] RE: [xslt] small fix needed for win32
- Date: Sun, 17 Mar 2002 02:30:10 +0100 (CET)
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]