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 06:19:09 GMT
Bill,

Thanks for your feedback again.

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

I just got access to a copy of Visual C++, and was able to build the project
without modification. I'm in the process of getting things to build in
CodeWarrior for Windows now that I know which files to exclude. The
CodeWarrior files should be the same as the VC++ files.

Once I get it working, I can submit my CodeWarrior for Windows project and
settings files for the platform. I can't guarantee that I can keep it up to
date with the releases, but at least it can be included as an unsupported
build platform.

For the most part, I should be able to keep my needed modifications for the
CodeWarrior build localized to the platform specific settings file.

I did need to remove the call to #include<memory.h>  in
/validators/DTD/CWStateSet.cpp to the new ANSI C++ way since codewarrior
didn't have a memory.h file now that it has been deprecated.
//#include<memory.h>
#include <memory>
using namespace std;

In general, shouldn't all the files use the new ANSI standard style for C++
files? I realize that some compilers don't support the new standard, but
some also may not continue support indefinitely for the deprecated style.

#include <iostream>
using namespace std;

should replace

#include <iostream.h>

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

The ones that don't compile on any platform must be dead, or the release
wouldn't build.
It might be worth the effort to at least move files that are known to be
deprecated.

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

Whenever a release is labeled, any platforms that don't build should be
considered dead. If a release is ready, it may have to wait for a maintainer
for the platform to bring the platform up to date, or the platform should be
moved into a different tree that is not dead, but not supported by the
release.

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

I'd rather be able to rely on the directory rather than the file name to
determine whether a platform specific implementation exists and whether it
is required. Hopefully, the compromise will evolve some over time.

Jonathan



Mime
View raw message