Re: [xslt] Port to windows

[Daniel Veillard <veillard redhat com>]

On Thu, Jun 21, 2001 at 01:51:58AM -0700, Yon Derek wrote:
> >   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.

   By the proper detection of the GCC compiler in xmlversion.h (itself
generated from xmlversion.h.in). i assume on Windows you just have to do

#ifndef ATTRIBUTE_UNUSED
#define ATTRIBUTE_UNUSED
#endif

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

  Well I don't want to export stuff which is not APIs but compiler
directives for the module. You should not include it. I was just 
wondering if the set of directives in win32config.h were sufficient,
not suggesting to include them as an API header.

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

  Well except this doesn't work, one really need to share the same
variable, thanks for you patch BTW.

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

  I did some cleanup yesterday in this area. I suggest you keep the
debug calls defined until I sort out some related problems.

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

  Well, yes, put them in a ZIP to avoid problems but wait first
until Igor  Zlatkovic have a look at the problems. I will also see if I
can make the decoupling, using "libxslt.h".

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

  Well libxml2 is not shaped in a way to build from CVS. The tar.gz
generated have a different include tree structure, and my goal is to
make this easy to compile, not CVS. Compiling from CVS requires 
symbolic links at the filesystem level.

Daniel

-- 
Daniel Veillard      | Red Hat Network http://redhat.com/products/network/
veillard@redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Sep 17-18 2001 Brussels Red Hat TechWorld http://www.redhat-techworld.com