xerces-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Pierce" <jpie...@nyc.rr.com>
Subject Re: Bugs and Compile Problems in 1.4.0
Date Sun, 04 Feb 2001 00:27:27 GMT

Thanks for all of your feedback. I guessed that most of the problems related
to dead files,or files for other platforms. I'll try to look at the make
files for the various platforms to decide what files to include.

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.

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 a lot easier for porting to other
platforms if it were made more clear.

Why not make it obvious what is included in each platform and which
platforms are fully implemented? That way dead code can be moved out and
incomplete platforms can also be seperated from working ones.

Instead of

How about:


3. What about my previous #5 question? Is this another dead file?

>> I needed to explicitly include /util/XMLString.hpp in
/src/framework/XMLRefInfo.hpp since it references XMLString::replicate

Thanks again,


----- Original Message -----
From: "Bill Schindler" <developer@bitranch.com>
To: <xerces-c-dev@xml.apache.org>
Sent: Saturday, February 03, 2001 6:47 PM
Subject: Re: Bugs and Compile Problems in 1.4.0

> Most of your problems seem to stem from a shotgun approach to creating a
> project. You picked up files for other platforms and unused headers, which
> produced several bogus errors.
> "Jonathan Pierce" <jpierce@nyc.rr.com> wrote:
> > If anyone cares, I am using CodeWarrior 6 on Windows
> > [ ... ]
> > 1.1 #include <strings.h> should be removed from
> Shouldn't you be using the WinSock version rather than the Unix version of
> the NetAccessors?
> > 2. The class name in /src/dom/MemDebug.hpp is in the wrong case on line
> Looks like a dead file to me. Nothing includes it. The real file is named
> DomMemDebug.hpp (and DomMemDebug.cpp).
> > 3.1 The /src/dom/NameNodeFilter.hpp includes non-existent file:
"NodeFilterImpl.hpp" so I had to remove it.
> > 3.2 I also had to redefine the class to not include the non-existent
superclass interface.
> Another dead header. (Hint: When nothing #includes a header and there's no
> implementation code to back the class, it's probably a piece of dead
> > The build process should not depend on specifying a precompiled header
to be included automatically in all files.
> As far as I can tell, the build process doesn't support precompiled
> at all. The rules surrounding creating and using precompiled headers are
> very compiler and vendor specific in any case. (I just checked the docs on
> ~5 compilers to verify that. Every vendor specfies different rules for
> implementing, creating, and using precompiled headers.)
> > 6. I made the following changes to:
> If that breaks the Mac support, I'd suggest creating separate CodeWarrior
> Windows and CodeWarrior Mac headers.
> > 7. I replaced the contents of /src/util/NoDefTranscoderException.cpp ...
> I assume you meant the .hpp file, since there's no .cpp. This looks like
> another dead file. NoDefTranscoder is a panic -- Xerces doesn't throw an
> exception here, it dies an ugly death. (See the various Platform files.)
> > 8. I needed to change the way gXercesVersionStr and
gXercesFullVersionStr were defined in /src/util/XercesDefs.hpp
> > so that I could include them in my precompiled header which does not
support the contain the const strings.
> That sounds more like a compiler bug.
> > 9. I needed to add the following to /src/util/XMLUni.cpp to support the
... NoDefTranscoderExceptionClass.
> ...and...
> > 10.  I needed to add the following to /src/util/XMLUni.hpp to support
... the NoDefTranscoderExceptionClass.
> No need. (See #7 above.)
> --Bill
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org

View raw message