Re: [xml] Windows build

[Igor Zlatkovic <igor stud fh-frankfurt de>]

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.

Okay.

> 2. Don't do messy
> #if (defined(_MY_COMPILER) || defined(__YOUR_COMPILER__) ||
> on many places.
>
> Seperate compilers and features:
>
> The compiler part:
>
> #ifdef _MY_COMPILER
> #define SNPRINTF_HAS_UNDERSCORE
> #define THIS_FEATURE
> #define THAT_FEATURE
> #endif
>
> #ifdef _MY_COMPILER
> #define THIS_FEATURE
> #endif
>
> The feature part
>
> #ifdef SNPRINTF_HAS_UNDERSCORE
> #undef snprintf
> #define snprintf _snprintf
> #endif

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
  #endif

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

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

Ciao
Igor