RE: [xslt] xsltconfig.h - outdated



Hello,

> I understand, but is there a reason for having '1.0.10' in it 
> ? or is it
> just unupdated ?

I took a closer look now. Xsltconfig.h is not in the CVS at all (just
did a clean checkout and it wasn't delivered). A platform without the
configure stage must create this file manually by copying and editing
xsltconfig.h.in. Can it be you are having some remains on your disc?

> This question applies similarly to xsltwin32config.h...
> As I understand it, those platforms will contain confused 
> version info,
> because they are unable to generate these files before compilation.

You are right.

Xsltwin32config.h exists in the CVS, but should be treated the same as
xsltconfig.h - nonexistent. A Platform which cannot run the configure
script and needs this file should remove it from the disc, create
xsltconfig.h as described above and make a copy of that xsltconfig.h
naming it xsltwin32config.h. This is exactly what configure script on
Windows does.

Xsltconfig.h and xsltwin32config.h were different in the past. Today
they are identical and that makes xsltwin32config.h(.in) obsolete. This
"win32-specific" configs should be removed, in fact I was about to post
such proposal to both libxml and libxslt and actually do it if no
objections arise during the weekend.

> In fact I need this to automate the process of releasing the 
> libxml2-pas and
> libxslt-pas packages, which are Pascal bindings for 
> respective libraries.
> Using one of the translated header files as a source of 
> version info would
> be very elegant, but I think it will not be a problem to involve the
> configure.in file.

If you are on Windows, nothing prevents you from running the
configuration script (win32/configure.js) within that automated process.
The configuration script neither uses nor depends on a particular C
compiler and would generate the relevant headers for you.

Ciao
Igor



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