RE: [xslt] Port to windows

["Yon Derek" <yond pobox com>]

>   Do you know if reusing the libxml win32config.h directly 
> would be sufficient to make this work, I don't see what 
> libxslt would require which is system specific and not 
> already handled by libxml.

I was able to reuse (i.e., compile with win32config.h from libxml2), if
I did something like this:
/* libxslt.h */
#ifndef __XML_LIBXSLT_H__
#define __XML_LIBXSLT_H__

#ifdef WIN32
#define ATTRIBUTE_UNUSED
#define WITHOUT_TRIO 1
#define LIBXSLT_VERSION_STRING "1200"
#include <win32config.h>   /* this is from libxml2 */
#else
#include "xlstconfig.h"
#endif

i.e., trio had to be disabled and ATTRIBUTE_UNSED nulled as MSVC doesn't
recognize it. I couldn't figure out how those are handled in libxml2.
This adds, however, one more include path since in libxml2 all includes
but win32config.h are in include\libxml subtree, while win32config.h in
include only. I think it should be moved inside include\libxml (for one
it would be less messy to distribute libxml2 "SDK" for windows, i.e.,
header, *.dll and *.lib file).

>   Hum, I will see what I can do. Instead of sending a patch, 
> since you're using CVS could you rather tell me what you had 
> to change ?

I had to copy xmlStringTextNoenc (from tree.c in libxml2) since it
wouldn't link otherwise (maybe it's possible to export it in libxml2,
but I haven't pursued this path).

I've also noticed that xmlXPathStringEvalNumber is used in xslt.c while
it's only defined in libxml if LIBXML_DEBUG_ENABLED is defined which
might be a potential problem (it wasn't problem for me). Also I got the
impression that LIBXML_DEBUG_ENABLED usage is not consistent within
libxml2.

Other than that it's just creating libxslt.def for DLL definition
(simple but boring; just copying names from *.h files) and creating
project and workspace files for MSVC. There is a problem in a sense that
you have to specify include paths and paths for linking, I just assumed
that libxslt and gnome-xml are siblings in the filesystem tree. I can
send those files (.def and *.dsp and *dsw).

One solution to LIBXSLT_VERSION_STRING problem would to put the
definition of things from which those are generated in a separate file
(.h ?) in such a way that it's possible to generate
LIBXSLT_VERSION_STRING etc. with C macros instead of during ./configure
step (as I believe is done right now).

I assume that the goal is to have the current version number in just one
place and generate other defs from it. I would gladly work toward and
test changes that would make both libxml2 and libxslt compile out-of-the
box from CVS on Windows.

Thanks,