xerces-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Schindler <develo...@bitranch.com>
Subject Re: Bugs and Compile Problems in 1.4.0
Date Sun, 04 Feb 2001 05:19:01 GMT
"Jonathan Pierce" <jpierce@nyc.rr.com> wrote:
> 1. There may still be a problem with #include <util/XercesDefs.hpp> not
> being in every header or .c file that doesn't include other headers. Many
> source files reference variables defined there.

If I remember correctly, the .c files are template code that may or may not
be included into the corresponding header, depending on the requirements and
limitations of various compilers. (such as FlagJanitor.hpp includes
FlagJanitor.c -OR- vice versa) After a quick glance through the .hpp files
that correspond to the .c files, it looks like all the .hpp files include
XercesDefs.hpp.

> 2. Do you think the sources should be organized so that dead files are not
> present in the distribution directory, and so that it is obvious which files
> are platform specific?

It would be nice to not have dead files in the tree. But determining if a
file is truly dead may not be so easy. We could move the ones we _think_ are
dead off to a holding directory and then wait to see if any of the various
platform maintainers complain. Grep-ing through all the code, configs,
makefiles, scripts, and projects gives me a fairly high confidence on
particular files being dead, but....

Also, maintainers come and go. A platform may go stale. Since there's
always a chance that someone will submit patches to bring a long-stale
platform up-to-date, when is it dead code?

As for making it obvious which files are platform specific. Well, if you
look at the directory and file names, it should be easy to tell what the
primary platform is. But there is some sharing of platform code and -- as
Dean points out -- there's a range of generic to specific in the directories
under utils (utils/Transcoders, utils/MsgLoaders, utils/NetAccessors). Most
of the builds can be configured to use the really generic stuff, the
semi-specific stuff (such as ICU), or the very platform-specific stuff
(MacOS, Win32, 390, etc). Some platforms are either very different or
near-identical depending on the compiler used (gcc versus MS VC). Or the
compiler is almost identical cross-platform, but there are some small
platform differences (gcc or CodeWarrior, for example).

Yes, the current structure is a compromise. But any other structure is also
a compromise. I personally think the functionality-based
compartmentalization is better than a platform-based version.


--Bill

Mime
View raw message