build structure

[Peter Koellner <pe...@mezzo.net>]

so far, i have eliminated 90% of src/util/Compilers and Platforms.

to replace the Compilers/*.cpp files, configure.in gets a test for stricmp
and strnicmp, strcasecmp and strncasecmp that defines 
HAVE_STRCMP and so on. so there is a new source file stricmp.cpp defining at
most 4 functions which is sufficient for all platforms. you get the idea. the
same scheme applies to the type of XMLCh, FileHandle, availability of native
bool, etc.

for the necessary unification of PlatformUtils, i would like someone
knowledgable to confirm that on OS2 and Tandem the stdio function
fputs is not POSIX conformant as returning a zero instead of standard EOF on 
failure.

-- 
peter koellner <pe...@mezzo.net>
canbox mobile reaction forces ;-)

Re: build structure

[Bill Schindler <de...@bitranch.com>]

Just back from vacation and trying to catch up on messages...

Peter Koellner <pe...@mezzo.net> wrote:
> to replace the Compilers/*.cpp files, configure.in gets a test for stricmp
> and strnicmp, strcasecmp and strncasecmp that defines 
> HAVE_STRCMP and so on.

A quick glance at configure.in and friends indicates that they expect a
compiler that takes a source file name and some parameters as input and
outputs an object file or an executable. They also assume the existence of
Unix-style tools, a Unix-style shell, and a GNU-ish make and makefiles.

All of which is a problem, because some platforms/compilers do not (and
cannot) work the way configure expects them to work.

If you look in the xml-xerces/c/Projects directory, you'll discover a
handful of platforms that use their own special build systems. The OS/2
VAC++ 4.0 compiler, for instance, _requires_ a project file in order to
build anything -- even a single-source-file executable. I believe the
Macintosh has a slightly different flavor of the same "limitations" (plus
Mac OS 9 doesn't have a command line, so shell scripts and their ilk can
present some interesting problems). Since there's also project files for
Win32, there's a good chance that platform will be problematic in a unified
build.

(Note: Although the OS/2 platform files have some support written for GCC
and VAC++ 3.x, there's currently no build support for those compilers.)

I'm not sure how these special-case platforms could be merged into a
unified build process. I suspect that the automake/autoconf process would
require some major hacking before it would work.

> for the necessary unification of PlatformUtils, i would like someone
> knowledgable to confirm that on OS2 and Tandem the stdio function
> fputs is not POSIX conformant as returning a zero instead of standard EOF on 
> failure.

For OS/2, the two WriteUStrStd...() routines -- the only place that fputs()
is used -- are dead code and should probably be deleted. (In fact, these
functions aren't used in the Linux code, either. Some code clean-up may be
in order.)

The code for Tandem looks like it's _way_ out of date and wouldn't compile
as it stands.



--Bill