"Arnold, Curt" wrote:
>
> > No, I have said several times that this will not require any
> > existing apps to change the way that they #include the
> > Xerces-C++ headers. Read the thread.
>
> Actually, I had read every message in the thread before posting. I had not been
>following the thread but started to see things that looked troubling, read all the
>previous messages, but never saw a
> clear statement of the problem that was trying to be fixed, though I got the
>impression that it had something to do with building apps using Xerces on Linux. I
>knew (or at least hoped) that there was
> a significant motivation other than just a directory name preference.
Of course. That would be silly. The first issue (now solved) was that
the headers should have been installed in *a* directory to prevent
pollution of the include directory. This will mean nothing to you if you
never developed on Unix.
>
> > 1. You will not have to do any more work than you already
> > have to do for each new Xerces release. I have made that
> > clear. 2. It's stupid to say that all change is bad.
>
> But achieving the objective with a minimum of change is a good thing.
>
> Since there is a substantial number of Xerces-C users who don't build C++ apps on
>Linux and directory
> renaming, if done poorly, could force them to touch most of their files, it seems
>justified to
> explain the motivation and potential solutions in a manner that does not assume
>knowledge of Linux
> conventions.
If I remember correctly, in your App's Visual C+ project's properties
dialog, you have to provide a path to the header files of any library
that that App uses. You would need to add a path. For *every* new
Xerces-C release you *already* need to go into your project properties
to give it the new name of the Xerces-C library because the version
number is part of the name. You will not need to change your own source
files, though you will now be able to make your #includes clearer if you
so desire.
That is all analogous with what will happen on Unix/Linux. If anything
it's easier because you have a GUI to do it with.
This is not a complicated issue, nor is it a linux-specific issue.
> The potential solutions should have the pros and cons outlined especially how
> "framework/something.hpp" and "xercesc/framework/something.hpp" includes would be
>resolved against
> both a source and binary distribution.
> Then let the list comment and the committers vote.
As far as I know, the binary distribution is just the source
distribution with the binaries included. Tell me if I'm wrong. If I'm
right, then whether it is a binary or source distribution is irrelevant.
The only difference would be whether you built the library or whether
the library was built for you by xml.apache.org. And that wouldn't
affect what you did with it after it was built.
>
> Here is what I've gathered so far:
>
> A) If Xerces header files from a binary distribution for Linux are going to be
>included in a C++ source file without changing the standard include path, it would be
>necessary (or at least good form)
> to have some distinctive fragment in the path name so there isn't a conflict with
>similarly named files from other libraries.
Not just good form. Necessary. Using obviously generic directory names
was plain wrong. Namespace pollution always becomes a problem
eventually.
>
> B) If this is done, if your source file does:
>
> #include <xercesc/parsers/DOMParser.hpp>
>
> (hopefully there isn't a difference between <xercesc/parsers/DOMParser.hpp> and
>"xercesc/parsers/DOMParser.hpp" for this discussion, if there is please enlighten me.)
>
> It compile on Linux without needing to muck with the include path.
Yes, if it's installed in the standard prefix. In practice there should
be a way to ask the system where the headers have been installed. But
that will be another ridiculously verbose battle in future.
> Existing source with includes like:
>
> #include <parsers/DOMParser.hpp>
>
> Could still compile but they would require doing the same mucking with the include
>path that previous
> distributions would need.
Almost correct. That should read 'same mucking with the build directives
(previously mucking with the linking directives was required) that *each
new* distribution requires'.
>
> Nested includes in Xerces-C header files would need to be changed to use
><xercesc/...> however includes within the Xerces-C source files would not need to be
>changed since the include path would be
> appropriately mucked.
Yes, obviously I would make any necessary makefile changes. I'm not
going to submit a patch that stops Xerces-C from building.
>
> C) Source files that #include <xercesc/...> would not compile against the source
>tree as currently
> configured since there is not xercesc directory in the source tree.
They will currently compile with this style of #include if you are using
an *installed* version of Xerces-C on unix. But you have to provide 2
include paths to fix the current problem. Note that using a local copy
of Xerces-C instead of an installed copy pretty much loses the
advantages of shared libraries and slows open source development because
people tend not to be in sync.
> Any solution to this must work
> on all platforms since xercesc would be in the nested include files so symbolic
>links wouldn't be an adequate solution. To address this, the current src directory
>could be renamed xercesc (which
> Arnaud outlined the different approaches and their effect on the CVS).
That is the better solution, but would require a bigger decision to be
made by the maintainer. However, this would be a small step in the right
direction. If we did this now then we would not need to change the
Xerces-C source files again when we rename src to xercesc.
Since it has been so difficult to get a decision on this simple fix I
have no confidence that we will get a decision to rename src to xercesc
in cvs. When I started using Xerces-C the maintainers were incredibly
responsive and problems were fixed immediately. Now I am not sure that
it is being actively maintained. I have to post simple emails several
times before they even get a response. I worry that other people are not
so persistent so good feedback and patches are therefore being ignored,
and that useful contributors may be discouraged.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
Murray Cumming
www.murrayc.com
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
