Re: [xml] Windows build

Hi Peter!

I'm in major time troubles and so I haven't tested the newest tarball and
can't promise to do so the next days.

Take your time. We are in no hurry. All of us have compilers and text
editors and can do temporary local changes where necessary. My point is just
to discuss these and to see what could be done so that the source fits
everyone on a long term.

1. Keep the JavaScript configuration step as transparent as possible so
that it can be done by a human instead.


2. Don't do messy
#if (defined(_MY_COMPILER) || defined(__YOUR_COMPILER__) ||
on many places.

Seperate compilers and features:

The compiler part:



The feature part

#undef snprintf
#define snprintf _snprintf

That is clean, yes. The problem is that we don't have a fixed set of
compiler-features, but every compiler has its own oddities. Common features
are rare. What I thought is rather something like

  #ifdef __MSVCRT__
  #undef snprintf
  #define snprintf _snprintf

and whoever uses MS C runtime, or a compatible one, MUST define that
__MSVCRT__ macro on her compiler's command line, no matter which compiler is
used. Only one macro would be referenced in the source. See, almost
everything behind those _MSC_VER, __MINGW32__, __BORLANDC__ and friends is
related to the C-runtime, not the compiler. The compiler-specific features
are used only on two occasions:
  * __declspec(dllimport/dllexport), which seems to be the one feature
common to and required by all Windows compilers.
  * __declspec(thread) for TLS in threads.c.
Everything else represents the oddities of the runtime, not the compiler. I
find it is important to differ between the runtime-feature and a

3. Beware of those windows headers.
The win32 headers declaring zillions of macros and
functions are a *bad* thing. Don't force their inclusion
if it can be avoided.

Eh? I never included windows.h. Only the WinCE port does that. I don't have
the possibility to test it, but I assume that WinCE port needs the header
for some reason, its C-runtime seems to be quite limited. Desktop Windows
does not need that header. Okay, it is included in threads.c if the native
thread implementation is selected, but that I didn't do and it happened
about a year ago.

I know there is the #include <everything> and pre-compile
school but I strongly disagree.

I disagree with that school as well. I wonder what makes you think I would
follow that lead? Am I missing something?


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