Hello all. I have some patches regarding the Win23/MSVC platform and here they are for your review. Please read the notes at the end of the message. Please? Pleaseeeee! By the way, this fixes the newly introduced problem where the compiler claimed it knew nothing about EAGAIN and EINTR. New Project/Workspace Files --------------------------- The attached zip file contains the new project files which are different and therefore incompatible to the old ones. Things that have changed are: 1. Correct variable export from the shared library. 2. New object file layout which saves disk space and ensures easier maintenance. 3. Project files for all available test tools, including testCatalog, testHTML, testSAX, testDocbook, testURI and testXPath. 4. A workspace which includes all project and their dependencies. The zip file should be extracted into the win32 subdirectory of the source tree. The project files we have been using so far are untouched and shall lurk around for a while until we are sure noone needs them anymore. Source patches -------------- The diff against libxml2-2.4.1 is attached to this message and contains the following changes: ./DOCBParser.c: A trivial change which eliminates the 'wrong parameter type' warning produced by MSVC. Since this is a warning and not an error, the diff should be applied only if it is OK with UNIX people. ./include/libxml/xmlversion.h: The LIBXML_DLL_IMPORT macro has been redefined so it actually works. This change introduces two new macros, one for libxml and the other for the client code which links against libxml statically. Both are specific for Win32/MSVC and need not be considered under other platforms. ./include/libxml/xmlwin32version.h: The same as for xmlversion.h, and plus brought the file to the same format as xmlversion.h. ./include/win32config.h: Added HAVE_ERRNO_H definition, conditionally redirected isnan() and isinf() to the implementations found in MS C-runtime, deactivated trio support, included xmlversion.h for compilers other than MSVC. Here I assume every C runtime under Win32 provides errno.h and everyone wants to include xml(win32)version.h. I hope this is OK with those who use watcom compiler. Mr Jacobi? ./nanohttp.c: A trivial change which eliminates the 'wrong parameter type' warning produced by MSVC. Since this is a warning and not an error, the diff should be applied only if it is OK with UNIX people. ./testCatalog.c: Included a missing header file. ./testHTML.c: Removed offending #undef ./testSAX.c: Removed offending #undef ./win32/README.MSDev: Updated to reflect new project file status. Notes ----- 1. xml(win32)version.h At some point we have given MSVC its very own xmlversion file. I cannot remember why this has been done, but there has been a reason. Ideally, we would now remove all WIn32/MSVC-specific stuff from xmlversion.h and keep it in xmlwin32version.h, but since that stuff still lurks in the depths of xmlversion.h, I patched it to be correct rather then leaving it incorrect. Actually, I really don't remember why there are two files. The library builds equally good with either file and if you take a closer look, you shall see the files are identical. Can anyone remember why xmlwin32version.h was introduced? 2. ENAMETOOLONG, ENOTEMPTY These two values, which can be read from errno under certain circumstances, have two different definitions. Once they are defined in errno.h by Microsoft, the second time in win32config.h by Peter Jacobi. Peter's definition is correct because it does not redefine anything, it simply maps to the socket errors. If the other one is correct, is a topic for argue. However, the two definitions are different and I have commented out ours, because no code in libxml checks for these errors at the moment. Stay tuned and listen. If some socket code starts using these in the future, it shall use the definitions from errno.h and thus probably check for wrong values. I must think of a way to handle this. 3. isnan(), isinf() The first of these has a sister in MS C-runtime named _isnan(). The second one has a, well, half-brother named _finite() which returns exactly the opposite. Since MS functions know best about MS internal floating-point oddities and MS reserves the right to change anything anytime without notice, we should use their runtime functions where possible. 4. trio I have disabled trio in the Win32/MSVC build. This is not because there is a problem with trio, but because there is no easy way to conditionally include a source file in the compilation process with MSVC. If xmlversion.h is to decide if trio is enabled or not, then we must compile and link all trio functionality into the executable, regardless if these funtions actually get called somewhere or not. Since MS C-runtime provides all string-manipulation functions we need in libxml, trio is not really necessary. If someone needs trio still, drop me a note. I must think of a way to include sources conditionally in the project file and should I get an idea about how to do this in the meantime, I shall reinclude trio in any event. For now, trio.c is not a part of the project file and if you #define WITH_TRIO in xml(win32)version.h, win32config.h is going to #undef it again. Note that all this happens ONLY when using MS compiler. 5. Binaries I shall be providing precompiled binaries of libxml for every release starting tomorrow. Daniel, can these be placed in the contrib directory on ftp://xmlsoft.org? If yes, how would you like to receive them? Is email OK, or do you prefer a download location? 6. DSP Files Now, the new project files are qute different to what a normal Win32/MSVC developer is used to. I know many of our Win32/MSVC lot whose habits die hard and who have difficulties when acclimating to anything that differs from the defaults set by Microsoft. These project files violate most of those defaults and I stand behind each and every violation, claiming it is better than the default. If anyone has a problem with this, a different opinion about how things should be handled, please contact me. We shall find a solution. 7. Test Utilities Test utilities, like testSAX, testHTML and friends, are all configured to link against the static version of libxml. Linking against the dynamic one shall come shortly, when I figure the problems which occur on the libxslt side. The dependency to the libxml2_a project is intentionally left out, so you must first compile libxml2_a and then any of the utilities. You can use any combination of debug/release when building the utilities, it does not matter due to the new build process. 8. Thanks Gigantic thanks for bearing with me. I didn't really believe one would bring the patience to read all of it :-)) Did I forget something? Hmm.. I hope not. Cheers. Igor
Attachment:
dsp.zip
Description: dsp.zip
Attachment:
libxml2.diff
Description: libxml2.diff