> 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. > 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. 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. 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. 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. 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. 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. 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. 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). --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
