You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@xerces.apache.org by "Arnold, Curt" <Cu...@hyprotech.com> on 2001/08/17 01:26:37 UTC
RE: Changing include to include/xercesc [recap for non-Linuxites]
> 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: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Changing include to include/xercesc (What about Xalan?)
Posted by Murray Cumming <Mu...@BetaResearch.de>.
Paul Emberson wrote:
>
> Currently xalanc and xercesc have the same file hierarchy. Surely for
> consistency you'd have to change xalan as well. It would make sense to do
> it all at the same time.
It would make sense to do it for all, but not necessarily at the same
time. Shortly afterwards, maybe.
> Paul
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
--
Murray Cumming
www.murrayc.com
murrayc@usa.net
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Changing include to include/xercesc (What about Xalan?)
Posted by Paul Emberson <pa...@fsc.co.uk>.
Currently xalanc and xercesc have the same file hierarchy. Surely for
consistency you'd have to change xalan as well. It would make sense to do
it all at the same time.
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Changing include to include/xercesc - Vote Results
Posted by "Jason E. Stewart" <ja...@openinformatics.com>.
"Murray Cumming" <Mu...@BetaResearch.de> writes:
> Here's a list of votes from my mail archive, with the most recent votes
> first:
>
> Martin Kalen: -1
> Bob Vaughn: 0
> Arnold Curt: -0
> John Mark Newton +1
> Olivier Schmitt: +1
> Jason E. Stewart +1
> Hans Silvisberg: +1
> J.J. Merelo: -1
> Gary Gale: +1
> Erik Rydgren: -1
> Peter A. Volchek: -1
> Steve Hespelt: 1
> Christopher Dam Brunn: 1
> Jesse Pelton: +0
> David Adams: -1 (said 0, but said 'No')
> Murray Cumming: +1
> Tinny Ng: 0
>
> Totals:
> -1: 5
> 0: 4
> +1: 8
> Simple Total: +3
>
> The only list of committers that I have is here:
> http://marc.theaimsgroup.com/?l=xerces-c-dev&m=99805694327734&w=2
> It doesn't look like any committer apart form Tinny Ng actually voted.
I'm a committer via Xerces-P.
jas.
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Changing include to include/xercesc - Vote Results
Posted by Murray Cumming <Mu...@BetaResearch.de>.
Here's a list of votes from my mail archive, with the most recent votes
first:
Martin Kalen: -1
Bob Vaughn: 0
Arnold Curt: -0
John Mark Newton +1
Olivier Schmitt: +1
Jason E. Stewart +1
Hans Silvisberg: +1
J.J. Merelo: -1
Gary Gale: +1
Erik Rydgren: -1
Peter A. Volchek: -1
Steve Hespelt: 1
Christopher Dam Brunn: 1
Jesse Pelton: +0
David Adams: -1 (said 0, but said 'No')
Murray Cumming: +1
Tinny Ng: 0
Totals:
-1: 5
0: 4
+1: 8
Simple Total: +3
The only list of committers that I have is here:
http://marc.theaimsgroup.com/?l=xerces-c-dev&m=99805694327734&w=2
It doesn't look like any committer apart form Tinny Ng actually voted.
I extracted these votes from paragraphs of text, and I am capable of
human error, so feel free to do your own counts.
--
Murray Cumming
www.murrayc.com
murrayc@usa.net
"Jason E. Stewart" wrote:
>
> "Murray Cumming" <Mu...@BetaResearch.de> writes:
>
> > "Jason E. Stewart" wrote:
> > >
> > > "Murray Cumming" <Mu...@BetaResearch.de> writes:
> > >
> > > > re-posting:
> > > >
> > > > Murray Cumming wrote:
> > > > >
> > > > > So what's the result of the vote?
> > > > >
> > >
> > > The result is as it has been all along. No one but you is really fired
> > > up over this issue. If you want a vote summary, go through the archive
> > > and count it, and write it up here and if it looks good, threaten to
> > > start committing files unless people respond...
> >
> > I assumed that the guy who started the vote would count the vote. He
> > probably has a better idea than me about who's vote counts. Mine
> > doesn't, and I don't have cvs commit rights.
>
> Yes, but....
>
> Tinny has already said he's agnostic about this topic, so it's
> unlikely he's going to do much.
>
> I'm in favor of the changes, but I'm also too busy to do much (like
> tallying votes).
>
> On the other hand, I do have commit priveleges.
>
> So...
>
> My suggestion stands:
>
> * count the votes, and print us a summary with email addresses and how
> they voted (Tinny wanted to open this up to all Xerces users, so
> let's give that a try).
>
> * what are the vote rules?? Can't have more than Y -1's?
>
> * if favorable we need to start the discussion of how to implement the
> changes. I believe there where two ideas, CVS repos fiddling, and
> bulk remove, bulk add.
>
> jas.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
--
Murray Cumming
www.murrayc.com
murrayc@usa.net
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Changing include to include/xercesc - Summary and Vote
Posted by "Jason E. Stewart" <ja...@openinformatics.com>.
"Tinny Ng" <tn...@ca.ibm.com> writes:
> So depends on the type of "Action Items" this issue belongs to, it
> is either classified as consensus (i.e. no vetos) or majority vote
> (i.e. +1s > -1s). I think this "changeing include" issue either
> belongs to "Showstoppers" or "Product changes" category and thus
> should be subject to lazy consensus. Since we have limited number
> of committers and we initially opened this vote to all users, we can
> count all users' vote. If there is any veto, and if you disagree
> with the veto, you should lobby the person who cast the veto. Until
> all vetos are resolved, then we can move on from there.
Next time we feel a vote is required, I think that this should be
decided *before* the vote, yes? Then we can point out to people what
the significance of voting -1 really is, yes?
Ok. So my advice for proceeding is that Murray make all the necessary
changes to Xerces, and provide me with a working source tarball. I
will put it on the WWW site in the experimental/ section.
At that point, Murray can indicate *exactly* what people need to do
that is different from what they currently do, *and* they can download
it and test it.
Then we discuss it.
jas.
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Changing include to include/xercesc - Summary and Vote
Posted by "Jason E. Stewart" <ja...@openinformatics.com>.
"Arnaud Le Hors" <le...@us.ibm.com> writes:
> "Jason E. Stewart" wrote:
> >
> > I believe that Tinny indicated that since he opened the vote to all
> > developers, *any* -1 vote is a veto.
>
> Just so you know, Tinny is probably too shy to mention it but you should
> have written:
>
> I believe that Tinny indicated that since SHE opened the vote to all
> developers, *any* -1 vote is a veto.
>
> Nope, this is not a male only project. :-)
Thanks Arnaud, my bad assumption. I'm sorry Tinny for being
chauvenistic.
Cheers,
jas.
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Changing include to include/xercesc - Summary and Vote
Posted by Arnaud Le Hors <le...@us.ibm.com>.
"Jason E. Stewart" wrote:
>
> I believe that Tinny indicated that since he opened the vote to all
> developers, *any* -1 vote is a veto.
Just so you know, Tinny is probably too shy to mention it but you should
have written:
I believe that Tinny indicated that since SHE opened the vote to all
developers, *any* -1 vote is a veto.
Nope, this is not a male only project. :-)
--
Arnaud Le Hors - IBM, XML Standards Strategy Group / W3C AC Rep.
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Changing include to include/xercesc - Summary and Vote
Posted by "Jason E. Stewart" <ja...@openinformatics.com>.
"Murray Cumming" <Mu...@BetaResearch.de> writes:
> Tinny Ng wrote:
>
> > If there is any veto, and if you disagree
> > with the veto, you should lobby the person who cast the veto. Until
> > all vetos are resolved, then we can move on from there.
> >
> > Tinny
>
> Are there any vetos?
> == Are there any -1s from committers?
I believe that Tinny indicated that since he opened the vote to all
developers, *any* -1 vote is a veto.
jas.
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Changing include to include/xercesc - Experimental tarball
Posted by "Jason E. Stewart" <ja...@openinformatics.com>.
"Murray Cumming" <Mu...@BetaResearch.de> writes:
> Here's a tarball of a Xerces-C++ with the discussed changes:
> http://www.murrayc.com/temp/xercesc_sane_includes.tar.gz
> Apparently I'm supposed to upload this to the 'experimental folder'.
> Maybe somebody could do this or tell me where that folder is.
Done. Plus I added your email as a README:
http://xml.apache.org/dist/xerces-c/experimental/
I'll give it try. Thanks Murray!
jas.
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Changing include to include/xercesc - Experimental tarball
Posted by Murray Cumming <Mu...@BetaResearch.de>.
Here's a tarball of a Xerces-C++ with the discussed changes:
http://www.murrayc.com/temp/xercesc_sane_includes.tar.gz
Apparently I'm supposed to upload this to the 'experimental folder'.
Maybe somebody could do this or tell me where that folder is.
I expect that we still need to make minor include path changes to
project files such as the MS Visual C++ and Borland project files, but I
don't have the setup for that.
Here's a recap:
What does this give you?
- You may now do this:
#include "xercesc/somefolder/someheader.h"
instead of this:
#include "somefolder/someheader.h"
- This should prevent clashes with headers of the same name, as well as
making your code clearer.
What do you need to do differently?
- Either
a) Change your #include lines to contain 'xercesc/'. This is the best
choice in the long term.
or b) Change the include path in your build files/projects:
- if your include path is e.g.
/home/murrayc/xercescdownload/include,
then change it to
/home/murrayc/xercescdownload/include/xerces.
- if your include path is /usr/local/include then change it to
/usr/local/include/xercesc.
- Be careful if using /usr/include. With gcc, you probably shouldn't
specify this yourself because it is an implict include path, and
specifying it seems to override other implicit include paths.
- This will be supereasy in future if we provide a command-line script
which our build files can call to get the appropriate include and
linking arguments.
What changes were made to achieve this?
- The src directory was renamed to xercesc.
- Makefile.incl files were changed to copy into ../include/xercesc
instead od ../include
- Makefile.incl files were changed to use the appropriate include path.
- All #includes in the code were changed to use "xerces/" where
necessary.
How will we integrate these changes again later:
- Just rename xercesc back to src, create a diff, apply the diff to the
up-to-date code, and rename src to xercesc.
- The changes are simple and they are in parts of the files which are
unlikely to be touched by other work.
Murray Cumming
www.murrayc.com
murrayc@usa.net
Murray Cumming wrote:
>
> Tinny Ng wrote:
> >
> > According to your summary of count, if we count committers votes only,
> > then we don't have any vetos, but we also don't have enough 3 binding +1
> > votes. If we count all users' votes, we have enough 3 +1 votes, but then
> > there are -1s as well ....
> >
> > Anyway, I think Jason's suggestion sounds good. Put the source tar in the
> > experimental folder and let people play with it for a couple of months.
> > Set a deadline for testing period. If no complaints, then put into CVS
> > later after the deadline ....
>
> OK. I will do that. Thank you.
>
> I just asked, because I thought that you were saying that I had to do
> some more lobbying. Nevermind.
>
> > Tinny
> >
> > Murray Cumming wrote:
> >
> > > Tinny Ng wrote:
> > >
> > > > If there is any veto, and if you disagree
> > > > with the veto, you should lobby the person who cast the veto. Until
> > > > all vetos are resolved, then we can move on from there.
> > > >
> > > > Tinny
> > >
> > > Are there any vetos?
> > > == Are there any -1s from committers?
> > >
> > > --
> > > Murray Cumming
> > > www.murrayc.com
> > > murrayc@usa.net
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> > > For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> > For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
> --
> Murray Cumming
> www.murrayc.com
> murrayc@usa.net
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
--
Murray Cumming
www.murrayc.com
murrayc@usa.net
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Changing include to include/xercesc - Summary and Vote
Posted by Murray Cumming <Mu...@BetaResearch.de>.
Tinny Ng wrote:
>
> According to your summary of count, if we count committers votes only,
> then we don't have any vetos, but we also don't have enough 3 binding +1
> votes. If we count all users' votes, we have enough 3 +1 votes, but then
> there are -1s as well ....
>
> Anyway, I think Jason's suggestion sounds good. Put the source tar in the
> experimental folder and let people play with it for a couple of months.
> Set a deadline for testing period. If no complaints, then put into CVS
> later after the deadline ....
OK. I will do that. Thank you.
I just asked, because I thought that you were saying that I had to do
some more lobbying. Nevermind.
> Tinny
>
> Murray Cumming wrote:
>
> > Tinny Ng wrote:
> >
> > > If there is any veto, and if you disagree
> > > with the veto, you should lobby the person who cast the veto. Until
> > > all vetos are resolved, then we can move on from there.
> > >
> > > Tinny
> >
> > Are there any vetos?
> > == Are there any -1s from committers?
> >
> > --
> > Murray Cumming
> > www.murrayc.com
> > murrayc@usa.net
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> > For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
--
Murray Cumming
www.murrayc.com
murrayc@usa.net
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Changing include to include/xercesc - Summary and Vote
Posted by "Jason E. Stewart" <ja...@openinformatics.com>.
"Tinny Ng" <tn...@ca.ibm.com> writes:
> According to your summary of count, if we count committers votes only,
> then we don't have any vetos, but we also don't have enough 3 binding +1
> votes. If we count all users' votes, we have enough 3 +1 votes, but then
> there are -1s as well ....
>
> Anyway, I think Jason's suggestion sounds good. Put the source tar in the
> experimental folder and let people play with it for a couple of months.
> Set a deadline for testing period. If no complaints, then put into CVS
> later after the deadline ....
Perfect. Thanks Tinny. The testing period with a deadline, with a new
round of (possible) complaints is very useful.
jas.
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Changing include to include/xercesc - Summary and Vote
Posted by Tinny Ng <tn...@ca.ibm.com>.
According to your summary of count, if we count committers votes only,
then we don't have any vetos, but we also don't have enough 3 binding +1
votes. If we count all users' votes, we have enough 3 +1 votes, but then
there are -1s as well ....
Anyway, I think Jason's suggestion sounds good. Put the source tar in the
experimental folder and let people play with it for a couple of months.
Set a deadline for testing period. If no complaints, then put into CVS
later after the deadline ....
Tinny
Murray Cumming wrote:
> Tinny Ng wrote:
>
> > If there is any veto, and if you disagree
> > with the veto, you should lobby the person who cast the veto. Until
> > all vetos are resolved, then we can move on from there.
> >
> > Tinny
>
> Are there any vetos?
> == Are there any -1s from committers?
>
> --
> Murray Cumming
> www.murrayc.com
> murrayc@usa.net
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Changing include to include/xercesc - Summary and Vote
Posted by Murray Cumming <Mu...@BetaResearch.de>.
Tinny Ng wrote:
> If there is any veto, and if you disagree
> with the veto, you should lobby the person who cast the veto. Until
> all vetos are resolved, then we can move on from there.
>
> Tinny
Are there any vetos?
== Are there any -1s from committers?
--
Murray Cumming
www.murrayc.com
murrayc@usa.net
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Changing include to include/xercesc - Summary and Vote
Posted by Tinny Ng <tn...@ca.ibm.com>.
"Jason E. Stewart" wrote:
>
> * what are the vote rules?? Can't have more than Y -1's?
>
Here is the guideline from Apache: http://xml.apache.org/decisions.html
Decision Making
All Developers are encouraged to participate in decisions,
but the
decision itself is made by those that have Committer status
in the
Project. In other words, the Project is a "Minimum Threshold
Meritocracy".
Any Developer may vote on any issue or action item. However,
the
only binding votes are those cast by a Committer. If the vote
is about a
change to the source code or documentation and the primary
author is
a Developer and not a Commiter, the primary author of what is
being
changed may also cast a binding vote on that issue.
The act of voting carries certain obligations. Voting members
are not
only stating their opinion, they are also agreeing to help do
the work.
Each vote can be made in one of three flavors:
+1 - "Yes," "Agree," or "the action should be
performed." On
some issues this is only binding if the voter has tested
the action
on their own system(s).
+/-0 - "Abstain," "no opinion". An abstention may have
detrimental effects if too many people abstain.
-1 - "No." On issues where consensus is required, this
vote
counts as a veto. All vetos must contain an explanation
of why
the veto is appropriate. Vetos with no explanation are
void. No
veto can be overruled. If you disagree with the veto,
you should
lobby the person who cast the veto. Voters intending to
veto an
action item should make their opinions known to the
group
immediately so that the problem can be remedied as early
as
possible.
An action requiring consensus approval must receive at least
3
binding +1 votes and no binding vetos. An action requiring
majority
approval must receive at least 3 binding +1 votes and more +1
votes than -1 votes. All other action items are considered to
have lazy
approval until somebody votes - 1, after which point they are
decided
by either consensus or majority vote, depending on the type
of action
item.
Action Items
All decisions revolve around "Action Items." Action Items
consist of the
following:
Long Term Plans
Short Term Plans
Release Plan
Release Testing
Showstoppers
Product Changes
Long Term Plans
Long term plans are simply announcements that group members
are working on
particular issues related to the Project. These are not
voted on, but Developers
who do not agree with a particular plan, or think that an
alternative plan would be
better, are obligated to inform the group of their feelings.
Short Term Plans
Short term plans are announcements that a developer is
working on a particular
set of documentation or code files with the implication that
other developers
should avoid them or try to coordinate their changes.
Release Plan
A release plan is used to keep all Developers aware of when
a release is desired,
who will be the release manager, when the repository will be
frozen to create a
release, and other assorted information to keep Developers
from tripping over each
other. Lazy majority decides each issue in a release plan.
Release Testing
After a new release is built, it must be tested before being
released to the public.
Majority approval is required before the release can be
made.
Showstoppers
Showstoppers are issues that require a fix be in place
before the next public
release. They are listed in the status file in order to
focus special attention on
these problems. An issue becomes a showstopper when it is
listed as such in the
status file and remains so by lazy consensus.
Product Changes
Changes to the products of the Project, including code and
documentation, will
appear as action items in the status file. All product
changes to the currently
active repository are subject to lazy consensus.
So depends on the type of "Action Items" this issue belongs to, it is either
classified as consensus (i.e. no vetos) or majority vote (i.e. +1s > -1s).
I think this "changeing include" issue either belongs to "Showstoppers" or
"Product changes" category and thus should be subject to lazy consensus.
Since we have limited number of committers and we initially opened this vote
to all users, we can count all users' vote. If there is any veto, and if you
disagree with the veto, you should lobby the person who cast the veto. Until
all vetos are resolved, then we can move on from there.
Tinny
Re: Changing include to include/xercesc - Summary and Vote
Posted by "Jason E. Stewart" <ja...@openinformatics.com>.
"Murray Cumming" <Mu...@BetaResearch.de> writes:
> "Jason E. Stewart" wrote:
> >
> > "Murray Cumming" <Mu...@BetaResearch.de> writes:
> >
> > > re-posting:
> > >
> > > Murray Cumming wrote:
> > > >
> > > > So what's the result of the vote?
> > > >
> >
> > The result is as it has been all along. No one but you is really fired
> > up over this issue. If you want a vote summary, go through the archive
> > and count it, and write it up here and if it looks good, threaten to
> > start committing files unless people respond...
>
> I assumed that the guy who started the vote would count the vote. He
> probably has a better idea than me about who's vote counts. Mine
> doesn't, and I don't have cvs commit rights.
Yes, but....
Tinny has already said he's agnostic about this topic, so it's
unlikely he's going to do much.
I'm in favor of the changes, but I'm also too busy to do much (like
tallying votes).
On the other hand, I do have commit priveleges.
So...
My suggestion stands:
* count the votes, and print us a summary with email addresses and how
they voted (Tinny wanted to open this up to all Xerces users, so
let's give that a try).
* what are the vote rules?? Can't have more than Y -1's?
* if favorable we need to start the discussion of how to implement the
changes. I believe there where two ideas, CVS repos fiddling, and
bulk remove, bulk add.
jas.
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Changing include to include/xercesc - Summary and Vote
Posted by Murray Cumming <Mu...@BetaResearch.de>.
"Jason E. Stewart" wrote:
>
> "Murray Cumming" <Mu...@BetaResearch.de> writes:
>
> > re-posting:
> >
> > Murray Cumming wrote:
> > >
> > > So what's the result of the vote?
> > >
>
> The result is as it has been all along. No one but you is really fired
> up over this issue. If you want a vote summary, go through the archive
> and count it, and write it up here and if it looks good, threaten to
> start committing files unless people respond...
I assumed that the guy who started the vote would count the vote. He
probably has a better idea than me about who's vote counts. Mine
doesn't, and I don't have cvs commit rights.
--
Murray Cumming
www.murrayc.com
murrayc@usa.net
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Changing include to include/xercesc - Summary and Vote
Posted by "Jason E. Stewart" <ja...@openinformatics.com>.
"Murray Cumming" <Mu...@BetaResearch.de> writes:
> re-posting:
>
> Murray Cumming wrote:
> >
> > So what's the result of the vote?
> >
The result is as it has been all along. No one but you is really fired
up over this issue. If you want a vote summary, go through the archive
and count it, and write it up here and if it looks good, threaten to
start committing files unless people respond...
jas.
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Changing include to include/xercesc - Summary and Vote
Posted by Murray Cumming <Mu...@BetaResearch.de>.
re-posting:
Murray Cumming wrote:
>
> So what's the result of the vote?
>
--
Murray Cumming
www.murrayc.com
murrayc@usa.net
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Changing include to include/xercesc - Summary and Vote
Posted by Murray Cumming <Mu...@BetaResearch.de>.
So what's the result of the vote?
--
Murray Cumming
www.murrayc.com
murrayc@usa.net
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Changing include to include/xercesc - Summary and Vote
Posted by Martin Kalen <ma...@todaysystems.com.au>.
----- Original Message -----
From: "Murray Cumming" <Mu...@BetaResearch.de>
Sent: Tuesday, August 21, 2001 5:10 PM
Subject: Re: Changing include to include/xercesc - Summary and Vote
> > I said that I would
> > gladly welcome a major change to directory/make-structure if it was
just
> > that - a major change and I could see all the benefits from it. I
clearly
> > said that if autoconf support had been there I would happily vote yes
for a
> > directory renaming. Now it will mean two takes at changing the
environment.
>
> A valid point. If this vote isn't passed, then I might suggest a far
> more ambitious Xerces-C++2 branch in which we could make far more
> ambitious changes.
Agreed. Sounds like a good idea! Perhaps too much administration work for
the CVS-people? I'm +(a lot) for this, though.
> I'm quite capable of being annoying just be sticking to the technical
details.
True. :-)
> A vote is a vote, but you should expect comments to be replied to.
I do, but I thought you overexaggerated and the last thing I want on this
list is a flamewar (that's why I thought we could take it to personal
mail). But any comments that are valid for the whole list should still be
here, so no harm done.
Regards,
Martin.
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Changing include to include/xercesc - Summary and Vote
Posted by Murray Cumming <Mu...@BetaResearch.de>.
Martin Kalen wrote:
>
> (The following is a personal response and may or may not be in line with my
> company's official opinions.)
>
> ----- Original Message -----
> From: "Murray Cumming" <Mu...@BetaResearch.de>
> Sent: Monday, August 20, 2001 5:48 PM
> Subject: Re: Changing include to include/xercesc - Summary and Vote
>
> > You should expect far more major changes to libraries at certain
> > intervals. A properly maintained library would keep a stable API for a
> > long time, and occasionally make large incompatible changes. If you say
> > that no incompatible changes should ever be made then you are opting for
> > stagnation. However, I repeat that this particular change should require
> > only minimal changes to existing builds.
>
> Nope, I did not (and still don't) say such a thing. I said that I would
> gladly welcome a major change to directory/make-structure if it was just
> that - a major change and I could see all the benefits from it. I clearly
> said that if autoconf support had been there I would happily vote yes for a
> directory renaming. Now it will mean two takes at changing the environment.
A valid point. If this vote isn't passed, then I might suggest a far
more ambitious Xerces-C++2 branch in which we could make far more
ambitious changes.
> And besides - I did not even mention anything about the code or the API. As
> far as I know, those are not related to directory naming.
I often talk about API and build changes together because they both
cause changes to the externally visible developer experience. It's
easier to talk about API stability specifically because C++ is more
clearly defined than build behaviour.
> > Your environment should be able to cope with minor directory renames. If
> > not, then I don't think that we should all be punished for your
> > mistakes.
>
> Sadly enough, the environment is not mine. This is a beast, whose soul came
> alive over ten years ago. But that is slightly off topic... :-)
>
> Please, get off it - I am not punishing you or anyone else for our
> environment. What I did was simply respond to Tinny Ng's request about
> voting and those views presented in the original mail still holds. By
> saying that I think this is a bad idea I am not saying that I think that
> you are a bad person.
I didn't interpret it that way. I'm quite capable of being annoying just
be sticking to the technical details. A vote is a vote, but you should
expect comments to be replied to.
>
> Please reply to my mailbox and not the list if you want to elaborate
> further on this issue.
No need.
--
Murray Cumming
www.murrayc.com
murrayc@usa.net
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Changing include to include/xercesc - Summary and Vote
Posted by Martin Kalen <ma...@todaysystems.com.au>.
(The following is a personal response and may or may not be in line with my
company's official opinions.)
----- Original Message -----
From: "Murray Cumming" <Mu...@BetaResearch.de>
Sent: Monday, August 20, 2001 5:48 PM
Subject: Re: Changing include to include/xercesc - Summary and Vote
> You should expect far more major changes to libraries at certain
> intervals. A properly maintained library would keep a stable API for a
> long time, and occasionally make large incompatible changes. If you say
> that no incompatible changes should ever be made then you are opting for
> stagnation. However, I repeat that this particular change should require
> only minimal changes to existing builds.
Nope, I did not (and still don't) say such a thing. I said that I would
gladly welcome a major change to directory/make-structure if it was just
that - a major change and I could see all the benefits from it. I clearly
said that if autoconf support had been there I would happily vote yes for a
directory renaming. Now it will mean two takes at changing the environment.
And besides - I did not even mention anything about the code or the API. As
far as I know, those are not related to directory naming.
> Your environment should be able to cope with minor directory renames. If
> not, then I don't think that we should all be punished for your
> mistakes.
Sadly enough, the environment is not mine. This is a beast, whose soul came
alive over ten years ago. But that is slightly off topic... :-)
Please, get off it - I am not punishing you or anyone else for our
environment. What I did was simply respond to Tinny Ng's request about
voting and those views presented in the original mail still holds. By
saying that I think this is a bad idea I am not saying that I think that
you are a bad person.
Please reply to my mailbox and not the list if you want to elaborate
further on this issue.
Regards,
Martin.
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Changing include to include/xercesc - Summary and Vote
Posted by Murray Cumming <Mu...@BetaResearch.de>.
Martin Kalen wrote:
>
> Martin Kalen: NO/-1
>
> We use Xerces-C on Windows NT4/2000, HP-UX, Linux, Solaris, AIX,
> OpenServer, UnixWare and Tru64 so I am neither pro-UNIX or pro-Windows.
>
> We have numerous hours invested in integrating the Xerces-C directory- and
> make-structure into our own automated make- and regression-test
> environment. Any change to the directory names would be a major setback for
> us.
1.
Your environment should be able to cope with minor directory renames. If
not, then I don't think that we should all be punished for your
mistakes.
2.
You should expect far more major changes to libraries at certain
intervals. A properly maintained library would keep a stable API for a
long time, and occasionally make large incompatible changes. If you say
that no incompatible changes should ever be made then you are opting for
stagnation. However, I repeat that this particular change should require
only minimal changes to existing builds.
>
> I think Peter Volchek et. al. summarised this very good - there are other
> issues that need to be dealt with before doing this. (The different ports
> are hopelessly out of synch with regards to the "main"/samples/tests
> directories, for one...)
>
> If there were no Murphy's law about diskcrashes and that autoconf-work had
> been saved, I would have voted differently. Now, it's just not worth it.
>
> Keep up the good work with Xerces-C!
>
> --
> Martin Kalen
> Software Engineer
> TODAY Systems, Inc.
> http://www.todaysystems.com.au/
> Tel +61-3-9536 3900 - Fax +61-3-9536 3901
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
--
Murray Cumming
www.murrayc.com
murrayc@usa.net
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Changing include to include/xercesc - Summary and Vote
Posted by Martin Kalen <ma...@todaysystems.com.au>.
Martin Kalen: NO/-1
We use Xerces-C on Windows NT4/2000, HP-UX, Linux, Solaris, AIX,
OpenServer, UnixWare and Tru64 so I am neither pro-UNIX or pro-Windows.
We have numerous hours invested in integrating the Xerces-C directory- and
make-structure into our own automated make- and regression-test
environment. Any change to the directory names would be a major setback for
us.
I think Peter Volchek et. al. summarised this very good - there are other
issues that need to be dealt with before doing this. (The different ports
are hopelessly out of synch with regards to the "main"/samples/tests
directories, for one...)
If there were no Murphy's law about diskcrashes and that autoconf-work had
been saved, I would have voted differently. Now, it's just not worth it.
Keep up the good work with Xerces-C!
--
Martin Kalen
Software Engineer
TODAY Systems, Inc.
http://www.todaysystems.com.au/
Tel +61-3-9536 3900 - Fax +61-3-9536 3901
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Changing include to include/xercesc - Summary and Vote
Posted by Murray Cumming <Mu...@BetaResearch.de>.
Tinny Ng wrote:
>
> Murray Cumming wrote:
>
> > My understanding is that if we rename src to xercesc then there will be
> > no need to have an include directory.
>
> No. In the binary distribution, we don't ship the source. Binary distribution only ships parts that are needed to "Run" the applications, i.e., the headers, the binaries, docs, and samples. Thus renaming src
> to xercesc is not enough for users who use the binary distribution which does not have the src folder at all.
OK, I didn't realise.
>
> > I do not believe that it will be necessary to do #3 if we do #1 and #2
> > because the files in src will include the copied headers in
> > include/xercesc/.
>
> Yes we need. For users who build from CVS tree or source distribution directly, the "include" folder does not exist at all. So if we only do #1 and #2 without #3, then users who build from CVS tree directly
> will for sure be broken.
OK, I didn't realise that there is never an include directory for source
distributions. I forgot to use my eyes when looking.
This brings up a new issue - Surely binary distribution should be via
rpm/deb/pkgadd etc. I don't see the sense in shared libraries which
aren't installed. Luckily, if we make these changes then we will be one
step closer to a build system that can do that easily.
Naturally I vote 1. It's unfortunate that the cvs work has to be done,
but I believe that problems should be fixed. And I want Xerces-C++ to be
easy to install and use, and I want to see it in Redhat/Mandrake/Suse so
that my users don't have to download it.
> Tinny
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
--
Murray Cumming
www.murrayc.com
murrayc@usa.net
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Changing include to include/xercesc - Summary and Vote
Posted by Tinny Ng <tn...@ca.ibm.com>.
Murray Cumming wrote:
> My understanding is that if we rename src to xercesc then there will be
> no need to have an include directory.
No. In the binary distribution, we don't ship the source. Binary distribution only ships parts that are needed to "Run" the applications, i.e., the headers, the binaries, docs, and samples. Thus renaming src
to xercesc is not enough for users who use the binary distribution which does not have the src folder at all.
> I do not believe that it will be necessary to do #3 if we do #1 and #2
> because the files in src will include the copied headers in
> include/xercesc/.
Yes we need. For users who build from CVS tree or source distribution directly, the "include" folder does not exist at all. So if we only do #1 and #2 without #3, then users who build from CVS tree directly
will for sure be broken.
Tinny
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Changing include to include/xercesc - Summary and Vote
Posted by Murray Cumming <Mu...@BetaResearch.de>.
Tinny Ng wrote:
>
> So far here is what I understand from Murray's proposal:
>
> Proposed changes to be made in the Xerces-C Project
> =====================================
> 1. Xerces-C source code: all #include insides the headers (e.g. DOMParser.hpp) and the source files (e.g. DOMParser.cpp) will be modified with 'xercesc' added, e.g.
> #include <xercesc/dom/DOM.hpp>
> And the samples, build instruction, perl script, Makefiles, project files that part of the Xerces-C will all be modified together.
>
> 2. Binary distribution: include folder rename from $XERCESCROOT/include/<subfolders> to $XERCESCROOT/include/xercesc/<subfolders>
>
> 3. CVS tree and thus source distribution: src folder rename from $XERCESCROOT/src/<subfolders> to $XERCESCROOT/xercesc/<subfolders>
My understanding is that if we rename src to xercesc then there will be
no need to have an include directory.
>
> For the solution to work for ALL different builds (windows or unix build; build from CVS directly or build from binary distribution or build from source distribution), all 3 of the above must all be done,
> we cannot just do # 1 and #3 without doing #2, nor just #1 and #2 without doing #3.
I do not believe that it will be necessary to do #3 if we do #1 and #2
because the files in src will include the copied headers in
include/xercesc/.
>
> User migration required after the changes
> ============================
> 1. Either modify all the #include in the user application with 'xercesc' added
> Or modify the include search path (-I) in the Makefile or project files
> 2. And for users who build from CVS or src path directly must modify the include search path to change from '-I {prefix}/src' to '-I {prefix}/xercesc'
>
> But a long term recommendation is to use "#include <xercesc/parsers/DOM.hpp>" in the Apps
>
> Murray, please correct me if I missed anything.
>
> And so far here is what I understand about the pros and cons:
>
> Good:
> ====
> 1. It helps addressing the name collisions between header files from various libraries that, unfortunately(but realistically), have the same names. Different products (3rd party or user applications) can
> also have e.g. <util/Base64.hpp> or <util/Mutexes.hpp>. So, why not have the Xerces include paths start with <xercesc/...> which makes things more obvious and can help avoid some problems.
> 2. Besides it would make the include directory inside the distribution resemble the include directory created by 'make install'. Since make install is already placing the header files under
> <prefix>/include/xercesc/* it's silly that user apps have to reference both -I<prefix>/include and -I<prefix>/include/xercesc just because the header files don't use #include <xercesc/header.h>. Changing
> the internal #includes to <xercesc/whateverwastherebefore> would make the client code build with just -I<prefix>/include (or maybe no -I at all if that's the default gcc include path). Xerces-C would
> then seem a little bit more sane.
>
> Against:
> ======
> 1. Users migration is required. Although Murray keeps mentioning modifying Makefile / Project file is not a big deal, still there is impact to user build environment and documentation which can be big.
> 2. Rename folder in CVS is not straight forward as outlined by Arnaud. We will either lose the revision history or break user CVS checkouts.
>
> Based on above summary, how about we call for vote? ALL active Xerces-C users have the right to vote, since this impact each and every user. +1 agree, -1 against, 0 no comment
>
> I will start 0. I don't think it worths the effort and worths to break users' environment/documentation, but well, if this is something that really helps the UNIX users and achieve sane build behavior, I
> am not against it ... so my vote is 0.
--
Murray Cumming
www.murrayc.com
murrayc@usa.net
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Changing include to include/xercesc - Summary and Vote
Posted by "Jason E. Stewart" <ja...@openinformatics.com>.
"Tinny Ng" <tn...@ca.ibm.com> writes:
> Good:
> ====
> 1. It helps addressing the name collisions between header files
> from various libraries that, unfortunately(but realistically),
> have the same names. Different products (3rd party or user
> applications) can also have e.g. <util/Base64.hpp> or
> <util/Mutexes.hpp>. So, why not have the Xerces include paths
> start with <xercesc/...> which makes things more obvious and can
> help avoid some problems.
> 2. Besides it would make the include directory inside the
> distribution resemble the include directory created by 'make
> install'. Since make install is already placing the header
> files under <prefix>/include/xercesc/* it's silly that user apps
> have to reference both -I<prefix>/include and
> -I<prefix>/include/xercesc just because the header files don't
> use #include <xercesc/header.h>. Changing the internal
> #includes to <xercesc/whateverwastherebefore> would make the
> client code build with just -I<prefix>/include (or maybe no -I
> at all if that's the default gcc include path). Xerces-C
> would then seem a little bit more sane.
within the past 9 months I remember two occasions were a Xerces header
conflicted with a Xalan header file. This is silly and avoidable, it
should not be allowed to happen again.
I vote +1 for the change.
> I will start 0. I don't think it worths the effort and worths to
> break users' environment/documentation, but well, if this is
> something that really helps the UNIX users and achieve sane build
> behavior, I am not against it ... so my vote is 0.
I appreciate tinny's effort to make this more democratic than other
votes that require commit privelege, but any vote we have ever taken
affects all users, perhaps just as much as this one. Also, this is a
*maintenance* issue, not a user fix. It affects how future maintainers
of xerces will deal with header file conflicts, and system
integration.
Also, it is a Unix specific issue, and doesn't affect windows
users. Tinny has graciously bowed out of the vote with a '0', but
given that there seem to be more windows users of Xerces-C out there,
I don't know if this is a truly fair means to achieve the vote.
Finally, if we're going to open this vote up to all users, then we
should open up the rest of them as well (except perhaps to vote in new
committers).
jas.
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Changing include to include/xercesc - Summary and Vote
Posted by Murray Cumming <Mu...@BetaResearch.de>.
"J. J. Merelo" wrote:
>
> Murray Cumming wrote:
> >
> > "J. J. Merelo" wrote:
> > >
> > > -1
> > >
> > > > 1. It helps addressing the name collisions between header files from various libraries that, unfortunately(but realistically), have the same names. Different products (3rd party or user applications) can
> > > > also have e.g. <util/Base64.hpp> or <util/Mutexes.hpp>. So, why not have the Xerces include paths start with <xercesc/...> which makes things more obvious and can help avoid some problems.
> > >
> > > Those can be addressed individually, on a file-by-file basis.
> >
> > Please elaborate on this last sentence.
> >
>
> Sure! if you have a src/veryCommonName.hpp and you need to include
> another veryCommonName.hpp from another source, you just change
> veryCommonName.hpp in xerces to notSoCommonName.hpp, or to
> xerces_veryCommonName.hpp.
That's a far more disruptive change. Also I find the repetition
distasteful. Directories are a better way to organize files than
prefixing filenames. Do you advocate putting all the source files in one
flat directory with very long filenames for each file? Of course not.
> Class name conflicts can be fixed using
> namespaces (OK,OK; nobody in xerces wants to use namespaces...) .
I'd love to use namespaces, but that's just because I have no respect
for old compilers. However, that wouldn't solve the problem of
conflicting header names. That's a different kind of namespace.
> That
> might mean changing also the name of the class, but you will have to do
> it only from time to time, and only if the file-not-in-xerces is so
> common everybody needs to include.
It's a mistake to ever believe that you can anticipate the contents of
all 3rd party libraries. That's why we have namespaces and directories,
and it's why decent C libraries use prefixes.
> In any case, there's another fix to filename conflicts: use prefixes;
> most libraries nowadays prefix class and library names with a,
> preferably uncommon, name. But that would mean renaming each and every
> file, and would be as bad, or worse, than changing a directory name.
Most classes in Xerces *are* prefixed with DOM, DOM_, or SAX_, etc. I
think there are still a few with very generic names in the global space
but I don't remember which ones they are.
--
Murray Cumming
www.murrayc.com
murrayc@usa.net
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Changing include to include/xercesc - Summary and Vote
Posted by Murray Cumming <Mu...@BetaResearch.de>.
"J. J. Merelo" wrote:
>
> -1
>
> > 1. It helps addressing the name collisions between header files from various libraries that, unfortunately(but realistically), have the same names. Different products (3rd party or user applications) can
> > also have e.g. <util/Base64.hpp> or <util/Mutexes.hpp>. So, why not have the Xerces include paths start with <xercesc/...> which makes things more obvious and can help avoid some problems.
>
> Those can be addressed individually, on a file-by-file basis.
Please elaborate on this last sentence.
> J
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
--
Murray Cumming
www.murrayc.com
murrayc@usa.net
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Changing include to include/xercesc - Summary and Vote
Posted by "J. J. Merelo" <jm...@geneura.ugr.es>.
-1
> 1. It helps addressing the name collisions between header files from various libraries that, unfortunately(but realistically), have the same names. Different products (3rd party or user applications) can
> also have e.g. <util/Base64.hpp> or <util/Mutexes.hpp>. So, why not have the Xerces include paths start with <xercesc/...> which makes things more obvious and can help avoid some problems.
Those can be addressed individually, on a file-by-file basis.
J
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
RE: Changing include to include/xercesc - Summary and Vote
Posted by Olivier Schmitt <sc...@metaintegration.net>.
I vote +1 for the change.
Olivier Schmitt
-----Original Message-----
From: Tinny Ng [mailto:tng-xml@ca.ibm.com]
Sent: Friday, August 17, 2001 6:18 AM
To: xerces-c-dev@xml.apache.org
Subject: Changing include to include/xercesc - Summary and Vote
So far here is what I understand from Murray's proposal:
Proposed changes to be made in the Xerces-C Project
=====================================
1. Xerces-C source code: all #include insides the headers (e.g.
DOMParser.hpp) and the source files (e.g. DOMParser.cpp) will be
modified with 'xercesc' added, e.g.
#include <xercesc/dom/DOM.hpp>
And the samples, build instruction, perl script, Makefiles, project
files that part of the Xerces-C will all be modified together.
2. Binary distribution: include folder rename from
$XERCESCROOT/include/<subfolders> to
$XERCESCROOT/include/xercesc/<subfolders>
3. CVS tree and thus source distribution: src folder rename from
$XERCESCROOT/src/<subfolders> to $XERCESCROOT/xercesc/<subfolders>
For the solution to work for ALL different builds (windows or unix
build; build from CVS directly or build from binary distribution or
build from source distribution), all 3 of the above must all be done,
we cannot just do # 1 and #3 without doing #2, nor just #1 and #2
without doing #3.
User migration required after the changes
============================
1. Either modify all the #include in the user application with
'xercesc' added
Or modify the include search path (-I) in the Makefile or project
files
2. And for users who build from CVS or src path directly must modify
the include search path to change from '-I {prefix}/src' to '-I
{prefix}/xercesc'
But a long term recommendation is to use "#include
<xercesc/parsers/DOM.hpp>" in the Apps
Murray, please correct me if I missed anything.
And so far here is what I understand about the pros and cons:
Good:
====
1. It helps addressing the name collisions between header files from
various libraries that, unfortunately(but realistically), have the same
names. Different products (3rd party or user applications) can
also have e.g. <util/Base64.hpp> or <util/Mutexes.hpp>. So, why not
have the Xerces include paths start with <xercesc/...> which makes
things more obvious and can help avoid some problems.
2. Besides it would make the include directory inside the distribution
resemble the include directory created by 'make install'. Since make
install is already placing the header files under
<prefix>/include/xercesc/* it's silly that user apps have to reference
both -I<prefix>/include and -I<prefix>/include/xercesc just because the
header files don't use #include <xercesc/header.h>. Changing
the internal #includes to <xercesc/whateverwastherebefore> would make
the client code build with just -I<prefix>/include (or maybe no -I at
all if that's the default gcc include path). Xerces-C would
then seem a little bit more sane.
Against:
======
1. Users migration is required. Although Murray keeps mentioning
modifying Makefile / Project file is not a big deal, still there is
impact to user build environment and documentation which can be big.
2. Rename folder in CVS is not straight forward as outlined by Arnaud.
We will either lose the revision history or break user CVS checkouts.
Based on above summary, how about we call for vote? ALL active Xerces-C
users have the right to vote, since this impact each and every user.
+1 agree, -1 against, 0 no comment
I will start 0. I don't think it worths the effort and worths to break
users' environment/documentation, but well, if this is something that
really helps the UNIX users and achieve sane build behavior, I
am not against it ... so my vote is 0.
Tinny
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
RE: Changing include to include/xercesc - Summary and Vote
Posted by John-Mark Newton <jo...@commedica.com>.
+1 for me, I've been bitten more then once by clashing header files while
using xerces,
John-Mark
-----Original Message-----
From: Tinny Ng [mailto:tng-xml@ca.ibm.com]
Sent: 17 August 2001 14:18
To: xerces-c-dev@xml.apache.org
Subject: Changing include to include/xercesc - Summary and Vote
So far here is what I understand from Murray's proposal:
[SNIP]
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
RE: Changing include to include/xercesc - Summary and Vote
Posted by Erik Rydgren <er...@mandarinen.se>.
Since I'm a lazy bastard and currently have no problems with the code except
to keep up with all the patches.
My vote is -1.
I don't need more work and I definately do not want a longer include path
(our include path for the project is almost to long for windows to handle
already).
Erik Rydgren
Mandarinen systems AB
Sweden
-----Original Message-----
From: Tinny Ng [mailto:tng-xml@ca.ibm.com]
Sent: den 17 augusti 2001 15:18
To: xerces-c-dev@xml.apache.org
Subject: Changing include to include/xercesc - Summary and Vote
So far here is what I understand from Murray's proposal:
Proposed changes to be made in the Xerces-C Project
=====================================
1. Xerces-C source code: all #include insides the headers (e.g.
DOMParser.hpp) and the source files (e.g. DOMParser.cpp) will be modified
with 'xercesc' added, e.g.
#include <xercesc/dom/DOM.hpp>
And the samples, build instruction, perl script, Makefiles, project files
that part of the Xerces-C will all be modified together.
2. Binary distribution: include folder rename from
$XERCESCROOT/include/<subfolders> to
$XERCESCROOT/include/xercesc/<subfolders>
3. CVS tree and thus source distribution: src folder rename from
$XERCESCROOT/src/<subfolders> to $XERCESCROOT/xercesc/<subfolders>
For the solution to work for ALL different builds (windows or unix build;
build from CVS directly or build from binary distribution or build from
source distribution), all 3 of the above must all be done,
we cannot just do # 1 and #3 without doing #2, nor just #1 and #2 without
doing #3.
User migration required after the changes
============================
1. Either modify all the #include in the user application with 'xercesc'
added
Or modify the include search path (-I) in the Makefile or project files
2. And for users who build from CVS or src path directly must modify the
include search path to change from '-I {prefix}/src' to '-I
{prefix}/xercesc'
But a long term recommendation is to use "#include
<xercesc/parsers/DOM.hpp>" in the Apps
Murray, please correct me if I missed anything.
And so far here is what I understand about the pros and cons:
Good:
====
1. It helps addressing the name collisions between header files from
various libraries that, unfortunately(but realistically), have the same
names. Different products (3rd party or user applications) can
also have e.g. <util/Base64.hpp> or <util/Mutexes.hpp>. So, why not have
the Xerces include paths start with <xercesc/...> which makes things more
obvious and can help avoid some problems.
2. Besides it would make the include directory inside the distribution
resemble the include directory created by 'make install'. Since make
install is already placing the header files under
<prefix>/include/xercesc/* it's silly that user apps have to reference
both -I<prefix>/include and -I<prefix>/include/xercesc just because the
header files don't use #include <xercesc/header.h>. Changing
the internal #includes to <xercesc/whateverwastherebefore> would make the
client code build with just -I<prefix>/include (or maybe no -I at all if
that's the default gcc include path). Xerces-C would
then seem a little bit more sane.
Against:
======
1. Users migration is required. Although Murray keeps mentioning modifying
Makefile / Project file is not a big deal, still there is impact to user
build environment and documentation which can be big.
2. Rename folder in CVS is not straight forward as outlined by Arnaud. We
will either lose the revision history or break user CVS checkouts.
Based on above summary, how about we call for vote? ALL active Xerces-C
users have the right to vote, since this impact each and every user. +1
agree, -1 against, 0 no comment
I will start 0. I don't think it worths the effort and worths to break
users' environment/documentation, but well, if this is something that really
helps the UNIX users and achieve sane build behavior, I
am not against it ... so my vote is 0.
Tinny
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Changing include to include/xercesc - Summary and Vote
Posted by Tinny Ng <tn...@ca.ibm.com>.
So far here is what I understand from Murray's proposal:
Proposed changes to be made in the Xerces-C Project
=====================================
1. Xerces-C source code: all #include insides the headers (e.g. DOMParser.hpp) and the source files (e.g. DOMParser.cpp) will be modified with 'xercesc' added, e.g.
#include <xercesc/dom/DOM.hpp>
And the samples, build instruction, perl script, Makefiles, project files that part of the Xerces-C will all be modified together.
2. Binary distribution: include folder rename from $XERCESCROOT/include/<subfolders> to $XERCESCROOT/include/xercesc/<subfolders>
3. CVS tree and thus source distribution: src folder rename from $XERCESCROOT/src/<subfolders> to $XERCESCROOT/xercesc/<subfolders>
For the solution to work for ALL different builds (windows or unix build; build from CVS directly or build from binary distribution or build from source distribution), all 3 of the above must all be done,
we cannot just do # 1 and #3 without doing #2, nor just #1 and #2 without doing #3.
User migration required after the changes
============================
1. Either modify all the #include in the user application with 'xercesc' added
Or modify the include search path (-I) in the Makefile or project files
2. And for users who build from CVS or src path directly must modify the include search path to change from '-I {prefix}/src' to '-I {prefix}/xercesc'
But a long term recommendation is to use "#include <xercesc/parsers/DOM.hpp>" in the Apps
Murray, please correct me if I missed anything.
And so far here is what I understand about the pros and cons:
Good:
====
1. It helps addressing the name collisions between header files from various libraries that, unfortunately(but realistically), have the same names. Different products (3rd party or user applications) can
also have e.g. <util/Base64.hpp> or <util/Mutexes.hpp>. So, why not have the Xerces include paths start with <xercesc/...> which makes things more obvious and can help avoid some problems.
2. Besides it would make the include directory inside the distribution resemble the include directory created by 'make install'. Since make install is already placing the header files under
<prefix>/include/xercesc/* it's silly that user apps have to reference both -I<prefix>/include and -I<prefix>/include/xercesc just because the header files don't use #include <xercesc/header.h>. Changing
the internal #includes to <xercesc/whateverwastherebefore> would make the client code build with just -I<prefix>/include (or maybe no -I at all if that's the default gcc include path). Xerces-C would
then seem a little bit more sane.
Against:
======
1. Users migration is required. Although Murray keeps mentioning modifying Makefile / Project file is not a big deal, still there is impact to user build environment and documentation which can be big.
2. Rename folder in CVS is not straight forward as outlined by Arnaud. We will either lose the revision history or break user CVS checkouts.
Based on above summary, how about we call for vote? ALL active Xerces-C users have the right to vote, since this impact each and every user. +1 agree, -1 against, 0 no comment
I will start 0. I don't think it worths the effort and worths to break users' environment/documentation, but well, if this is something that really helps the UNIX users and achieve sane build behavior, I
am not against it ... so my vote is 0.
Tinny
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Changing include to include/xercesc [recap for non-Linuxites]
Posted by Murray Cumming <Mu...@BetaResearch.de>.
"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: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
--
Murray Cumming
www.murrayc.com
murrayc@usa.net
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org