FW: [xml] Win32/MSVC Facelift

Igor -- oops, meant to send to the mailing list instead of directly to you!
fat fingers...


1. xml(win32)version.h

I strongly agree that xmlwin32version.h should be removed.  I believe, but
am not sure, that it was created to simplify some of the win32 c-runtime
issues, such as the strange behaviours when including winsock2 headers.
However, it is virtually the same and annoying as it seems sometimes it is
used, and other times xmlversion.h is used.  Seems redundant.

4. trio

Agreed.  In my case binary size is EXTREMELY important.  I have always had
to go in and exclude trio.c from being compiled.  Why not remove trio.c
entirely from the project (.dsp) as this will never be used on win32 and
only causes confusion by having it and #define's listed for it.

5. Binaries

Can I recommend building both _so and _a versions for distribution.  LIke I
said earlier, my release builds will always be custom builds to minimize
size, but full debug builds with all features would be nice for 'fixed in
cvs' tests.

 6. DSP Files

We shall see when I try and use 'em tomorrow :)  I heard you say you have a
global workspace (.dsw).  I think you should attempt to properly use the
dependencies of each project, especially when using dynamic libraries.

7. Test Utilities
You can use any combination of debug/release when
building the utilities, it does not matter due to the new build process.

Really?  I've always seem to encounter profiling/debug features in the
utilites that would only build when some of hte debug features were
#define'ed in that wouldn't typically be included in a release build.

Did I forget something? Hmm.. I hope not. Cheers.

I think we need to throw in some #pragma pack(push,8) and #pragma pack(pop)
when including the libxml2 and libxslt headers.  It is unsafe to assume that
everyone uses 8 byte struct alignment.  Also, it is unsafe to assume
everyone will
use the same calling convention (__cdecl verses __stdcall).  I am not sure
if you can define this with a #pragma or some equivalent.  The only way I
know to do it is to use a macro with each function header, i.e.

void CALLTYPE function(arg)

where on win32 CALLTYPE is defined as __cdecl.  Obviously this is to be
avoided, as it causes too much confusion/annoyance to un*x programmers.  Do
you know of a way to set a default call type within a given header without
having to change it for a project?  Consider using libxml2 as a dynamic
library from a program with a default call type of stdcall (/Gz compile


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