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 "D. Stimits" <st...@idcomm.com> on 2001/10/10 19:02:28 UTC
Interested in getting changes into main Xerces distribution
Where would I post, or ask for changes to the official Xerces
distribution? Right now, the immediate change (and I can provide
Makefile patches if desired) would be that make install fails to place
headers for devel in any conventional location, and anything depending
on Xerces ends up hard coding include paths to a tarball unpack of
Xerces. For example, and this could be relocateable, make install should
also install headers at /usr/include/xerces/ or
/usr/local/include/xerces/ on Linux (and variations for most UNIX
flavors). Is it possible to communicate with official developers
concerning configuration and packaging issues? Is there a more active
mailing list for such things?
D. Stimits, stimits@idcomm.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Interested in getting changes into main Xerces distribution
Posted by "Jason E. Stewart" <ja...@openinformatics.com>.
"Michael Huedepohl" <mi...@mozquito.com> writes:
> Excuse me for intervening, but I can confirm that - e.g. on Solaris 8 -
> if you don't specify anything for <prefix>, i.e. using the default /usr/local
> (and I haven't seen documented how to configure the prefix),
> the "make install" does install the library, but not the include files!
> Instead, they are installed in the source tree in several subdirectories
> named "NONE":
>
> $ cd $XERCESCROOT/src
> $ ./runConfigure -p solaris -cgcc -xg++ -nsocket -tnative -rpthread
> (...)
> $ make
> (...)
> $ make install
> cd util && make install && cd ..
> make[1]: Entering directory `/home/michael/xerces/src/util'
> mkdir -p NONE/include/xercesc/util
Yes this is the behavior on debian linux as well.
jas.
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
[PATCH] Re: Interested in getting changes into main Xerces
distribution
Posted by Murray Cumming <mu...@t-online.de>.
On Thu, 2001-10-11 at 17:02, Michael Huedepohl wrote:
> Murray Cumming wrote:
> >
> > On Thu, 2001-10-11 at 15:09, Michael Huedepohl wrote:
> > > Murray Cumming wrote:
> > > >
> > > > On Thu, 2001-10-11 at 01:01, D. Stimits wrote:
> > > > > Murray Cumming wrote:
> > > > > >
> > > > > > On Thu, 2001-10-11 at 00:02, D. Stimits wrote:
> > > > > > > Murray Cumming wrote:
> > > > > > > >
> > > > > > > > On Wed, 2001-10-10 at 19:02, D. Stimits wrote:
> > > > > > > > > Where would I post, or ask for changes to the official Xerces
> > > > > > > > > distribution?
> > > > > > > >
> > > > > > > > Erm, this list, of course.
> > > > > > > >
> > > > > > > > Right now, the immediate change (and I can provide
> > > > > > > > > Makefile patches if desired) would be that make install fails to place
> > > > > > > > > headers for devel in any conventional location,
> > > > > > > >
> > > > > > > > Since Xerces-C 1.5.1, the headers have gone into <prefix>/include.
> > > > > > > > What's wrong with that?
> > > > > > >
> > > > > > > Well, in general, "include" is a _really bad_ (did I mention "really
> > > > > > > really" bad also?)
> > > > > >
> > > > > > Sorry, I mean that since 1.5.1 the headers have gone into
> > > > > > <prefix>/include/xercesc. There is no problem with where the headers are
> > > > > > installed.
> > > > >
> > > > > This is good. I'm using 1.5.1 though, and headers are not being
> > > > > installed at all during make install.
> > > >
> > > > First you say that they are installed to 'random' locations, then you
> > > > say that they are not installed at all. I'm sure that it's working for
> > > > me. I personally changed the headers install path from <prefix>/include
> > > > to <prefix>/include/xercesc so I know that there stuff in there to
> > > > install the headers.
> > >
> > > Excuse me for intervening, but I can confirm that - e.g. on Solaris 8 -
> > > if you don't specify anything for <prefix>, i.e. using the default /usr/local
> > > (and I haven't seen documented how to configure the prefix),
> >
> > ./runConfigure -P<prefix>, I think.
> >
> > runConfigure has help output, either with no args or with --help, I
> > don't remember.
>
> Sorry, I found it just after sending my email - indeed, it's printed with the
> help message (runConfigure with no args).
> I tried runConfigure earlier (pre 1.5.1) and didn't get a message about the
> install prefix, and I missed to check it again with version 1.5.1.
> >
> > > the "make install" does install the library, but not the include files!
> >
> > OK, I haven't discovered this because I always need to specify /usr on
> > Redhat. Would anyone like to try to fix this? Sorry, I'm busy on other
> > stuff at the moment.
>
> Well, I've analyzed the configure file and found a solution:
> You only have to move the setting of prefix_include behind the check
> `test "x$prefix" = xNONE && prefix=$ac_default_prefix'.
> I.e., remove line 1289 and insert it after line 1376.
> Here is the diff output:
> diff -r1.4 configure
> 1289d1288
> < prefix_include=${prefix}/include/xercesc
> 1376a1376
> > prefix_include=${prefix}/include/xercesc
Well done. Simple problem, simple fix.
> Can you commit this change?
Sorry, I don't have commit access. Please add it to bugzilla if nobody
else applies it.
>
> Cheers, Michael
>
> >
> > > Instead, they are installed in the source tree in several subdirectories
> > > named "NONE":
> > >
> > > $ cd $XERCESCROOT/src
> > > $ ./runConfigure -p solaris -cgcc -xg++ -nsocket -tnative -rpthread
> > > (...)
> > > $ make
> > > (...)
> > > $ make install
> > > cd util && make install && cd ..
> > > make[1]: Entering directory `/home/michael/xerces/src/util'
> > > mkdir -p NONE/include/xercesc/util
> > > (...)
>
>
--
Murray Cumming
murrayc@usa.net
www.murrayc.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Interested in getting changes into main Xerces distribution
Posted by "D. Stimits" <st...@idcomm.com>.
Michael Huedepohl wrote:
>
> "Jason E. Stewart" wrote:
> >
> > "Michael Huedepohl" <mi...@mozquito.com> writes:
> >
> > > "Jason E. Stewart" wrote:
> > > >
> > > > "Michael Huedepohl" <mi...@mozquito.com> writes:
> > > >
> > > > > Well, I've analyzed the configure file and found a solution:
> > > > > You only have to move the setting of prefix_include behind the check
> > > > > `test "x$prefix" = xNONE && prefix=$ac_default_prefix'.
> > > > > I.e., remove line 1289 and insert it after line 1376.
> > > > > Here is the diff output:
> > > > > diff -r1.4 configure
> > > > > 1289d1288
> > > > > < prefix_include=${prefix}/include/xercesc
> > > > > 1376a1376
> > > > > > prefix_include=${prefix}/include/xercesc
> > > > >
> > > > > Can you commit this change?
> > > >
> > > > No. Because configure is automatically generated from configure.in
> > > > using autoconf. Any changes to configure will be lost the next time
> > > > someone runs autoconf.
> > >
> > > Are you really sure?
> >
> > $ cp ./configure ./configure.bak
> > $ autoconf
> > $ diff ./configure ./configure.bak
> > $
> >
> > Seems to be.
>
> Okay, I had to step deeper into the autoconf mechanism.
> Now I found a solution for configure.in, here is the diff
> for configure.in:
>
> 66c66
> < prefix_include=${prefix}/include/xercesc
> ---
> > prefix_include='${PREFIX}/include/xercesc'
This does not fix the problem for me. Maybe our bash interpreters are
different. The quoting does propagate to the generated configure as
shown below, so this is not the problem. Are you including this quoting
change on more than one configure.in? So far I've been assuming that
only the toplevel configure.in was changed.
In any case, the generated bash script does not contain any conditional
to test for the emptiness of prefix while putting together the
prefix_include. It blindly accepts whatever is there, whereas some other
steps test the value of prefix and then do the intelligent thing. This
behavior is the same whether an explicit runConfigure -P value is used,
or if defaults are used.
D. Stimits, stimits@idcomm.com
>
> And here is the diff for configure (identical to the result of autoconf,
> for systems without autoconf):
>
> 1289c1289
> < prefix_include=${prefix}/include/xercesc
> ---
> > prefix_include='${PREFIX}/include/xercesc'
>
> I tested this with the default prefix setting and with the -P option
> for runConfigure, and it worked.
>
> Hope you can commit it now.
>
> Michael
>
> ---------------------------------------------------------------------
> 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: Interested in getting changes into main Xerces distribution
Posted by "D. Stimits" <st...@idcomm.com>.
Michael Huedepohl wrote:
>
> "Jason E. Stewart" wrote:
> >
> > "Michael Huedepohl" <mi...@mozquito.com> writes:
> >
> > > "Jason E. Stewart" wrote:
> > > >
> > > > "Michael Huedepohl" <mi...@mozquito.com> writes:
> > > >
> > > > > Well, I've analyzed the configure file and found a solution:
> > > > > You only have to move the setting of prefix_include behind the check
> > > > > `test "x$prefix" = xNONE && prefix=$ac_default_prefix'.
> > > > > I.e., remove line 1289 and insert it after line 1376.
> > > > > Here is the diff output:
> > > > > diff -r1.4 configure
> > > > > 1289d1288
> > > > > < prefix_include=${prefix}/include/xercesc
> > > > > 1376a1376
> > > > > > prefix_include=${prefix}/include/xercesc
> > > > >
> > > > > Can you commit this change?
> > > >
> > > > No. Because configure is automatically generated from configure.in
> > > > using autoconf. Any changes to configure will be lost the next time
> > > > someone runs autoconf.
> > >
> > > Are you really sure?
> >
> > $ cp ./configure ./configure.bak
> > $ autoconf
> > $ diff ./configure ./configure.bak
> > $
> >
> > Seems to be.
>
> Okay, I had to step deeper into the autoconf mechanism.
> Now I found a solution for configure.in, here is the diff
> for configure.in:
>
> 66c66
> < prefix_include=${prefix}/include/xercesc
> ---
> > prefix_include='${PREFIX}/include/xercesc'
Aha! The famous snafu bug. The minor detail of quoting. I can't test it
ATM, but will try it out also later.
D. Stimits, stimits@idcomm.com
>
> And here is the diff for configure (identical to the result of autoconf,
> for systems without autoconf):
>
> 1289c1289
> < prefix_include=${prefix}/include/xercesc
> ---
> > prefix_include='${PREFIX}/include/xercesc'
>
> I tested this with the default prefix setting and with the -P option
> for runConfigure, and it worked.
>
> Hope you can commit it now.
>
> Michael
>
> ---------------------------------------------------------------------
> 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: Interested in getting changes into main Xerces distribution
Posted by "Jason E. Stewart" <ja...@openinformatics.com>.
"Michael Huedepohl" <mi...@mozquito.com> writes:
> Please apply the patch as I described it above, not only adding
> single quotes!!! It's necessary to use PREFIX in upper case
> letters, too!
Actually, I don't understand what the quotes are for. The patch that I
committed only used the capital PREFIX which fixed the problem on
linux.
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: Interested in getting changes into main Xerces distribution
Posted by "D. Stimits" <st...@idcomm.com>.
Michael Huedepohl wrote:
>
> "D. Stimits" wrote:
> >
> > "D. Stimits" wrote:
> > >
> > > Michael Huedepohl wrote:
> > > >
> > > > "Jason E. Stewart" wrote:
> > > > >
> > > > > "Michael Huedepohl" <mi...@mozquito.com> writes:
> > > > >
> > > > > > "Jason E. Stewart" wrote:
> > > > > > >
> > > > > > > "Michael Huedepohl" <mi...@mozquito.com> writes:
> > > > > > >
> > > > > > > > Well, I've analyzed the configure file and found a solution:
> > > > > > > > You only have to move the setting of prefix_include behind the check
> > > > > > > > `test "x$prefix" = xNONE && prefix=$ac_default_prefix'.
> > > > > > > > I.e., remove line 1289 and insert it after line 1376.
> > > > > > > > Here is the diff output:
> > > > > > > > diff -r1.4 configure
> > > > > > > > 1289d1288
> > > > > > > > < prefix_include=${prefix}/include/xercesc
> > > > > > > > 1376a1376
> > > > > > > > > prefix_include=${prefix}/include/xercesc
> > > > > > > >
> > > > > > > > Can you commit this change?
> > > > > > >
> > > > > > > No. Because configure is automatically generated from configure.in
> > > > > > > using autoconf. Any changes to configure will be lost the next time
> > > > > > > someone runs autoconf.
> > > > > >
> > > > > > Are you really sure?
> > > > >
> > > > > $ cp ./configure ./configure.bak
> > > > > $ autoconf
> > > > > $ diff ./configure ./configure.bak
> > > > > $
> > > > >
> > > > > Seems to be.
> > > >
> > > > Okay, I had to step deeper into the autoconf mechanism.
> > > > Now I found a solution for configure.in, here is the diff
> > > > for configure.in:
> > > >
> > > > 66c66
> > > > < prefix_include=${prefix}/include/xercesc
> > > > ---
> > > > > prefix_include='${PREFIX}/include/xercesc'
> > >
> > > Unfortunately, this didn't seem to fix it for me (on Redhat 7.1). The
> > > quoting change appears to be a valid addition, but insufficient. The
> > > generated configure file has this line unchanged:
> > > ac_default_prefix=/usr/local
> > > ...which looks right, but it is being ignored.
> > >
> > > Further down in the configure file, the additional quotes come through
> > > correctly, but "prefix" is till not even looking at ac_default_prefix
> > > (it appears ac_default_prefix is inert):
> > > prefix=NONE
> > >
> > > I did not investigate if there is code somewhere that is supposed to
> > > test "prefix" for "NONE", and substitute "/usr/local" only if it is
> > > currently "NONE", but the install still failed to copy header files. The
> > > "NONE" directories are still being used, rather than
> > > /usr/local/include/xercesc/.
> > >
> > > It would be interesting if autoconf and friends had a debugger with
> > > breakpoints and watches, oh well.
> > >
> > > D. Stimits, stimits@idcomm.com
> >
> > Ok, I am coming up with a new twist. Careful view of text ("tee" is a
> > wonderful tool), I discovered it is installing to
> > /include/xercesc/....in other words, it is creating "include" in the
> > root of the entire filesystem. I have the changes to add single quotes
> > for prefix_include, so instead of going to "NONE" it is now calling it
> > an empty string, and then it is directly appending "/include/xercesc" to
> > that. More testing later, but it very much appears that
> > ac_default_prefix is completely ignored.
>
> Please apply the patch as I described it above, not only adding single quotes!!!
> It's necessary to use PREFIX in upper case letters, too!
> Don't you know the patch command?
> Apply it to configure - or apply it to configure.in and use autoconf.
> If in doubt, look into Makefile.in (e.g. in the util directory)
> where prefix_include is used.
> For me, it works with and without the -P option on Linux, Solaris and FreeBSD.
>
> Michael
Ok, I missed the CAP letters before. I'll give that a shot.
D. Stimits, stimits@idcomm.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Interested in getting changes into main Xerces distribution
Posted by Dean Roddey <dr...@charmedquark.com>.
> I am curious how much IBM is involved in this? I known they've done a
> lot with java, JFS, and a few other things to use linux with e-commerce,
> but I hadn't heard anything about involvement directly with Apache or
> Xerces-c. (just curious)
>
IBM employees have provided the bulk of the development effort of
Xerces-C/J, and of Xalan-C/J as well AFAIK. Obiovusly they ain't making big
bucks off of it, so they are doing a large service to the XML community. Of
course, it does serve their purposes, since it gives them an important seat
at the XML table; but, nonetheless, I believe that IBM should be given
credit where credit is due. More and more 'outsiders', so to speak, have
contributed to the product over time, and their contributions should not be
minimized. But IBM has shouldered the bulk of the development costs of the
Xerces products.
--------------------------
Dean Roddey
The Charmed Quark Controller
Charmed Quark Software
droddey@charmedquark.com
http://www.charmedquark.com
"If it don't have a control port, don't buy it!"
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Interested in getting changes into main Xerces distribution
Posted by "D. Stimits" <st...@idcomm.com>.
"Jason E. Stewart" wrote:
>
> "D. Stimits" <st...@idcomm.com> writes:
>
> > Is there an approximation of what a typical time is between releases for
> > bugfixes? Is it typical for it to occur monthly?
>
> No, but things are changing. The IBM team hasn't really had a policy
> of bugfix releases that occur on a regular basis. Instead they make
> nightly builds available for the supported platforms, see:
>
> http://xml.apache.org/dist/xerces-c/nightly/
>
> The 1.5 release has already had one bugfix release, 1.5.1, and 1.5.2
> is on its way. These have each been motivated by users requesting new
> releases.
Unfortunately, my reason for wanting to see this is because of a need
for packaging simplifications in other projects. The goal being that
Xerces-c unpack become a non-issue, and not require special steps for
users that want to unpack, configure, build, install. Since it is
required in both Linux and win32, both the install prefix bug and the
directory structure need to be updated before this can happen. Knowing
it will eventually be fixed is a great aid, but the best way to deal
with it also depends on timing.
I am curious how much IBM is involved in this? I known they've done a
lot with java, JFS, and a few other things to use linux with e-commerce,
but I hadn't heard anything about involvement directly with Apache or
Xerces-c. (just curious)
D. Stimits, stimits@idcomm.com
>
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Interested in getting changes into main Xerces distribution
Posted by "Jason E. Stewart" <ja...@openinformatics.com>.
"D. Stimits" <st...@idcomm.com> writes:
> Is there an approximation of what a typical time is between releases for
> bugfixes? Is it typical for it to occur monthly?
No, but things are changing. The IBM team hasn't really had a policy
of bugfix releases that occur on a regular basis. Instead they make
nightly builds available for the supported platforms, see:
http://xml.apache.org/dist/xerces-c/nightly/
The 1.5 release has already had one bugfix release, 1.5.1, and 1.5.2
is on its way. These have each been motivated by users requesting new
releases.
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: Interested in getting changes into main Xerces distribution
Posted by "D. Stimits" <st...@idcomm.com>.
I don't know why, but I always get two copies of replies.
Murray Cumming wrote:
>
> On Wed, 2001-10-17 at 22:51, D. Stimits wrote:
> > Murray Cumming wrote:
> > >
> > ...snip...
> > > >
> > > >
> > > > What is required to get the ball rolling on this as a change? Should I
> > > > submit an altered package that is similar to the sane_includes?
> > >
> > > sane_includes fixes all of the problems. I will push for those changes
> > > to be applied *after* the next bugfix release. We've already been
> > > through the process with that.
> >
> > Don't forget to propagate the make install prefix bug fix to
> > sane_includes, it looks like it was formed before the prefix changes.
>
> Of course.
>
> > >
> > > > This is
> > > > holding back a project due to wanting to see whether it gets fixed on
> > > > both win32 and linux (the cvs change already fixed the broken make
> > > > install on linux/UNIX) for the package layout. I suspect that maybe it
> > > > is fear of the dramatic changes to the cvs tree, more than anything,
> > > > that is delaying a more sane official package layout.
> > >
> > > I believe that we decided that that's worthwhile and possible. There's
> > > no point in discussing it until after the next release.
> >
> > What kind of time frame is expected for the next bugfix release? It also
> > sounds like the bugfix release itself will not reflect sane_includes, is
> > that correct?
>
> Haven't I just been saying that? If I'm waiting until after the release
> to make the changes, then it's likely that the release will not include
> the changes.
>
> If the bugfix release does not reflect sane_includes, is
> > there a probable time frame beyond the bugfix release that will reflect
> > sane_includes?
>
> Nobody can predict the future.
Is there an approximation of what a typical time is between releases for
bugfixes? Is it typical for it to occur monthly?
D. Stimits, stimits@idcomm.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Interested in getting changes into main Xerces distribution
Posted by Murray Cumming <mu...@t-online.de>.
On Wed, 2001-10-17 at 22:51, D. Stimits wrote:
> Murray Cumming wrote:
> >
> ...snip...
> > >
> > >
> > > What is required to get the ball rolling on this as a change? Should I
> > > submit an altered package that is similar to the sane_includes?
> >
> > sane_includes fixes all of the problems. I will push for those changes
> > to be applied *after* the next bugfix release. We've already been
> > through the process with that.
>
> Don't forget to propagate the make install prefix bug fix to
> sane_includes, it looks like it was formed before the prefix changes.
Of course.
> >
> > > This is
> > > holding back a project due to wanting to see whether it gets fixed on
> > > both win32 and linux (the cvs change already fixed the broken make
> > > install on linux/UNIX) for the package layout. I suspect that maybe it
> > > is fear of the dramatic changes to the cvs tree, more than anything,
> > > that is delaying a more sane official package layout.
> >
> > I believe that we decided that that's worthwhile and possible. There's
> > no point in discussing it until after the next release.
>
> What kind of time frame is expected for the next bugfix release? It also
> sounds like the bugfix release itself will not reflect sane_includes, is
> that correct?
Haven't I just been saying that? If I'm waiting until after the release
to make the changes, then it's likely that the release will not include
the changes.
If the bugfix release does not reflect sane_includes, is
> there a probable time frame beyond the bugfix release that will reflect
> sane_includes?
Nobody can predict the future.
>
> D. Stimits, stimits@idcomm.com
>
> >
> > --
> > Murray Cumming
> > murrayc@usa.net
> > www.murrayc.com
> >
> > ---------------------------------------------------------------------
> > 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
murrayc@usa.net
www.murrayc.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Interested in getting changes into main Xerces distribution
Posted by "D. Stimits" <st...@idcomm.com>.
Murray Cumming wrote:
>
...snip...
> >
> >
> > What is required to get the ball rolling on this as a change? Should I
> > submit an altered package that is similar to the sane_includes?
>
> sane_includes fixes all of the problems. I will push for those changes
> to be applied *after* the next bugfix release. We've already been
> through the process with that.
Don't forget to propagate the make install prefix bug fix to
sane_includes, it looks like it was formed before the prefix changes.
>
> > This is
> > holding back a project due to wanting to see whether it gets fixed on
> > both win32 and linux (the cvs change already fixed the broken make
> > install on linux/UNIX) for the package layout. I suspect that maybe it
> > is fear of the dramatic changes to the cvs tree, more than anything,
> > that is delaying a more sane official package layout.
>
> I believe that we decided that that's worthwhile and possible. There's
> no point in discussing it until after the next release.
What kind of time frame is expected for the next bugfix release? It also
sounds like the bugfix release itself will not reflect sane_includes, is
that correct? If the bugfix release does not reflect sane_includes, is
there a probable time frame beyond the bugfix release that will reflect
sane_includes?
D. Stimits, stimits@idcomm.com
>
> --
> Murray Cumming
> murrayc@usa.net
> www.murrayc.com
>
> ---------------------------------------------------------------------
> 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: Interested in getting changes into main Xerces distribution
Posted by Murray Cumming <mu...@t-online.de>.
On Wed, 2001-10-17 at 19:49, D. Stimits wrote:
> "D. Stimits" wrote:
> >
> > Murray Cumming wrote:
> > >
> ...snip...
> > > > > I really have no idea what you're talking about. Could you try to
> > > > > explain more concisely?
> > > >
> > > > Yes, I see a flaw in my argument (the paragraph above that says "src"
> > > > doesn't need to be renamed still applies though). More change would be
> > > > required than a simple repackaging. But perhaps a description of the
> > > > goal would help, forgive my repetition about to show up, I'd like to
> > > > have the problem statement available here.
> > > >
> > > > On every UNIX/Linux system that the header install bug is fixed on,
> > > > regardless of whether a default prefix is used, or a custom prefix, the
> > > > headers will be available on a path with this:
> > > > ..../include/xercesc/....
> > > >
> > > > For example, somewhere on the system will be:
> > > > ..../include/xercesc/dom/DOM_Attr.hpp
> > > >
> > > > The "...." could be /usr/local, it could be /usr, it might be
> > > > ~/myheaders. No matter what that prefix is, one can include DOM_Attr.hpp
> > > > via:
> > > > #include <xercesc/dom/DOM_Attr.hpp>
> > > > (and also adding a '-I${prefix}/include' to the compile line...changing
> > > > this will allow relocation of the headers anywhere wilthout altering the
> > > > include statement itself, and without using a quoted and inflexible
> > > > format, e.g., without "#include
> > > > "../../xercesc1_5_1/include/dom/DOM_Attrib.hpp")
> > > >
> > > > Unfortunately, windows is a somewhat sucky development environment, it
> > > > does not have the concept of a system header directory or standard build
> > > > filesystem hierarchy. One does not install Xerces-c headers to a known
> > > > location. Instead the source is unpacked, then you either point an
> > > > environment variable at it, or adjust a project file. Fine, it's part of
> > > > life. But since the unpacked source does not currently follow the same
> > > > directory tree that a UNIX/Linux install would point at, include
> > > > DOM_Attrib.hpp would require a different include line:
> > > > #include <dom/DOM_Attrib.hpp>
> > > > Versus:
> > > > #include <xercesc/dom/DOM_Attrib.hpp>
> > >
> > > The unpacked source *does* follow the same directory tree that a
> > > UNIX/linux install would point at. When it's unpacked it sits in
> > > somewhere/xercesc/
> > > When it's installed on UNIX the headers are in
> > > <prefix>/xercesc
> > >
> > > Windows users should, and can with the sane_includes tarball, do
> > > #include <xercesc/dom/DOM_Attrib.hpp>
> >
> > What I said above I specifically said it is a restatement of the problem
> > on the current Xerces-c, NOT the sane_includes version. This is the part
> > about the sane_includes that I said should become part of the regular
> > Xerces-c distribution.
> >
> > >
> > > And they can, if they want to use the old stupid way
> > > ( #include <dom/DOM_Attrib.hpp> )
> > > just by changing their include path. Where is the problem?
> >
> > The problem is not the sane_includes, it is the regular official
> > package. My only point of disagreement in the sane_includes was that it
> > is not necessary to also rename "src" as "xercesc"...the includes are
> > after all part of the xercesc project also, and "src" seems to me to
> > more accurately describe the source portion of the package. I also said
> > that it doesn't particularly bother me that "src" is renamed "xercesc",
> > only that I felt it was irrelevant to accomplishing the
> > "include/xercesc/" include path adjustment.
> >
> > >
> > > >
> > > > Possibly one could get around that with #ifdef __win32__, but that's
> > > > ugly. Solution 1 would be for the developer on win32 to manually copy
> > > > the include source so that it is in "include/xercesc/" instead of
> > > > "include/" somewhere else. Solution 2 would be preferable, that Xerces-c
> > > > unpacks directly to a structure of "include/xercesc/". It saves either
> > > > condition includes or manual directory copying.
> > > >
> > > > The only change that is needed to the current Xerces-c source structure
> > > > to make this work is that the include directory not directly contain
> > > > "dom", "framework", "idom", and so on, but that it contain "xercesc" and
> > > > that in turn "xercesc" contains those other directories. If the current
> > > > "src" subdirectory is to be renamed, fine, but I am saying that it is
> > > > not necessary. The xercesc_sane_includes changes the include directory
> > > > correctly, it is a needed change, other changes are not needed.
> > >
> > > I think that this doesn't make sense in light of my comments above.
> >
> > It makes perfect sense because it wasn't a comment on the sane_includes
> > except for the part where it suggests renaming "src" as "xercesc" is
> > unnecessary. I am in total agreement that the include subdirectory needs
> > to have rearrangement in the way that sane_includes does. But it looks
> > like this subject has been ongoing long before I posted on it...why
> > didn't anyone change the include directory in all this time have
> > "xercesc" subdirectory? Does it need to be entered as a bugzilla report?
> >
> > D. Stimits, stimits@idcomm.com
> >
> ...snip...
>
>
> What is required to get the ball rolling on this as a change? Should I
> submit an altered package that is similar to the sane_includes?
sane_includes fixes all of the problems. I will push for those changes
to be applied *after* the next bugfix release. We've already been
through the process with that.
> This is
> holding back a project due to wanting to see whether it gets fixed on
> both win32 and linux (the cvs change already fixed the broken make
> install on linux/UNIX) for the package layout. I suspect that maybe it
> is fear of the dramatic changes to the cvs tree, more than anything,
> that is delaying a more sane official package layout.
I believe that we decided that that's worthwhile and possible. There's
no point in discussing it until after the next release.
--
Murray Cumming
murrayc@usa.net
www.murrayc.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Interested in getting changes into main Xerces distribution
Posted by "D. Stimits" <st...@idcomm.com>.
"D. Stimits" wrote:
>
> Murray Cumming wrote:
> >
...snip...
> > > > I really have no idea what you're talking about. Could you try to
> > > > explain more concisely?
> > >
> > > Yes, I see a flaw in my argument (the paragraph above that says "src"
> > > doesn't need to be renamed still applies though). More change would be
> > > required than a simple repackaging. But perhaps a description of the
> > > goal would help, forgive my repetition about to show up, I'd like to
> > > have the problem statement available here.
> > >
> > > On every UNIX/Linux system that the header install bug is fixed on,
> > > regardless of whether a default prefix is used, or a custom prefix, the
> > > headers will be available on a path with this:
> > > ..../include/xercesc/....
> > >
> > > For example, somewhere on the system will be:
> > > ..../include/xercesc/dom/DOM_Attr.hpp
> > >
> > > The "...." could be /usr/local, it could be /usr, it might be
> > > ~/myheaders. No matter what that prefix is, one can include DOM_Attr.hpp
> > > via:
> > > #include <xercesc/dom/DOM_Attr.hpp>
> > > (and also adding a '-I${prefix}/include' to the compile line...changing
> > > this will allow relocation of the headers anywhere wilthout altering the
> > > include statement itself, and without using a quoted and inflexible
> > > format, e.g., without "#include
> > > "../../xercesc1_5_1/include/dom/DOM_Attrib.hpp")
> > >
> > > Unfortunately, windows is a somewhat sucky development environment, it
> > > does not have the concept of a system header directory or standard build
> > > filesystem hierarchy. One does not install Xerces-c headers to a known
> > > location. Instead the source is unpacked, then you either point an
> > > environment variable at it, or adjust a project file. Fine, it's part of
> > > life. But since the unpacked source does not currently follow the same
> > > directory tree that a UNIX/Linux install would point at, include
> > > DOM_Attrib.hpp would require a different include line:
> > > #include <dom/DOM_Attrib.hpp>
> > > Versus:
> > > #include <xercesc/dom/DOM_Attrib.hpp>
> >
> > The unpacked source *does* follow the same directory tree that a
> > UNIX/linux install would point at. When it's unpacked it sits in
> > somewhere/xercesc/
> > When it's installed on UNIX the headers are in
> > <prefix>/xercesc
> >
> > Windows users should, and can with the sane_includes tarball, do
> > #include <xercesc/dom/DOM_Attrib.hpp>
>
> What I said above I specifically said it is a restatement of the problem
> on the current Xerces-c, NOT the sane_includes version. This is the part
> about the sane_includes that I said should become part of the regular
> Xerces-c distribution.
>
> >
> > And they can, if they want to use the old stupid way
> > ( #include <dom/DOM_Attrib.hpp> )
> > just by changing their include path. Where is the problem?
>
> The problem is not the sane_includes, it is the regular official
> package. My only point of disagreement in the sane_includes was that it
> is not necessary to also rename "src" as "xercesc"...the includes are
> after all part of the xercesc project also, and "src" seems to me to
> more accurately describe the source portion of the package. I also said
> that it doesn't particularly bother me that "src" is renamed "xercesc",
> only that I felt it was irrelevant to accomplishing the
> "include/xercesc/" include path adjustment.
>
> >
> > >
> > > Possibly one could get around that with #ifdef __win32__, but that's
> > > ugly. Solution 1 would be for the developer on win32 to manually copy
> > > the include source so that it is in "include/xercesc/" instead of
> > > "include/" somewhere else. Solution 2 would be preferable, that Xerces-c
> > > unpacks directly to a structure of "include/xercesc/". It saves either
> > > condition includes or manual directory copying.
> > >
> > > The only change that is needed to the current Xerces-c source structure
> > > to make this work is that the include directory not directly contain
> > > "dom", "framework", "idom", and so on, but that it contain "xercesc" and
> > > that in turn "xercesc" contains those other directories. If the current
> > > "src" subdirectory is to be renamed, fine, but I am saying that it is
> > > not necessary. The xercesc_sane_includes changes the include directory
> > > correctly, it is a needed change, other changes are not needed.
> >
> > I think that this doesn't make sense in light of my comments above.
>
> It makes perfect sense because it wasn't a comment on the sane_includes
> except for the part where it suggests renaming "src" as "xercesc" is
> unnecessary. I am in total agreement that the include subdirectory needs
> to have rearrangement in the way that sane_includes does. But it looks
> like this subject has been ongoing long before I posted on it...why
> didn't anyone change the include directory in all this time have
> "xercesc" subdirectory? Does it need to be entered as a bugzilla report?
>
> D. Stimits, stimits@idcomm.com
>
...snip...
What is required to get the ball rolling on this as a change? Should I
submit an altered package that is similar to the sane_includes? This is
holding back a project due to wanting to see whether it gets fixed on
both win32 and linux (the cvs change already fixed the broken make
install on linux/UNIX) for the package layout. I suspect that maybe it
is fear of the dramatic changes to the cvs tree, more than anything,
that is delaying a more sane official package layout.
D. Stimits, stimits@idcomm.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Interested in getting changes into main Xerces distribution
Posted by "D. Stimits" <st...@idcomm.com>.
Murray Cumming wrote:
>
> On Tue, 2001-10-16 at 01:26, D. Stimits wrote:
> > Murray Cumming wrote:
> > >
> > > On Mon, 2001-10-15 at 23:51, D. Stimits wrote:
> > ...snip...
> > > > >
> > > > > Please comment on the sane_includes tarball.
> > > >
> > > > This tarball does what is required for portability in terms of providing
> > > > a "xercesc" prefix to include files, regardless of whether it is via
> > > > install or directly pointing at the source. It does, however, make other
> > > > directory changes which are not necessary.
> > >
> > > Such as?
> >
> > The 1.5.1 tarball unpacks with a scheme where the toplevel configure.in
> > is at:
> > ./src/configure.in
> > (and includes at ./include/DOM/ and family)
> >
> > The sane includes unpacks such that "src" is renamed "xercesc". While
> > consistent with the project name, it isn't necessary to change the "src"
> > subdirectory. It's possible it might have some aesthetic appeal, but I'd
> > personally stick to "src".
> >
> > >
> > > For those testing, it still
> > > > has the default install prefix bug, the toplevel configure.in line:
> > > > prefix_include=${prefix}/include/xercesc
> > > >
> > > > Should be edited to be:
> > > > prefix_include='${PREFIX}/include/xercesc'
> > > >
> > > > Now I don't know if this was only intended as a partial install sample,
> > > > but it also dies later (my unpack directory was
> > > > /home/home1/stimits/tmp9/) with this at install:
> > > >
> > > > cp -fp
> > > > /home/home1/stimits/tmp9/xercesc_sane_includes/lib/libxerces-c1_5_1.so
> > > > /usr/local/lib
> > > > cp: cannot stat
> > > > `/home/home1/stimits/tmp9/xercesc_sane_includes/lib/libxerces-c1_5_1.so':
> > > > No such file or directory
> > > > make[1]: [install] Error 1 (ignored)
> > > > make[1]: Leaving directory
> > > > `/home/home1/stimits/tmp9/xercesc_sane_includes/obj'
> > >
> > > I can't reproduce that problem. Could you investigate?
> >
> > Ahh, the great bane of configuration pain. I'll try to find out, but I
> > can't promise I'll succeed. I did add the patch to the toplevel
> > configure.in to produce:
> > prefix_include='${PREFIX}/include/xercesc'
> > (adds quotes, and capitalizes PREFIX)
> >
> > Without that, the headers don't install. Possibly this also caused
> > something else to break. I'll see if I can figure it out over the
> > weekend.
> >
> > >
> > > >
> > > >
> > > > If the entire tarball had unpacked into a directory of pseudo-format
> > > > "version-dependent/xercesc/the_rest_of_what_it_already_is/", then no
> > > > source code would require modification, and the same results would be
> > > > achieved. For reference the current pseudo-code-directory-tree is
> > > > "version-dependent/the_rest_of_what_it_already_is".
> > >
> > > I really have no idea what you're talking about. Could you try to
> > > explain more concisely?
> >
> > Yes, I see a flaw in my argument (the paragraph above that says "src"
> > doesn't need to be renamed still applies though). More change would be
> > required than a simple repackaging. But perhaps a description of the
> > goal would help, forgive my repetition about to show up, I'd like to
> > have the problem statement available here.
> >
> > On every UNIX/Linux system that the header install bug is fixed on,
> > regardless of whether a default prefix is used, or a custom prefix, the
> > headers will be available on a path with this:
> > ..../include/xercesc/....
> >
> > For example, somewhere on the system will be:
> > ..../include/xercesc/dom/DOM_Attr.hpp
> >
> > The "...." could be /usr/local, it could be /usr, it might be
> > ~/myheaders. No matter what that prefix is, one can include DOM_Attr.hpp
> > via:
> > #include <xercesc/dom/DOM_Attr.hpp>
> > (and also adding a '-I${prefix}/include' to the compile line...changing
> > this will allow relocation of the headers anywhere wilthout altering the
> > include statement itself, and without using a quoted and inflexible
> > format, e.g., without "#include
> > "../../xercesc1_5_1/include/dom/DOM_Attrib.hpp")
> >
> > Unfortunately, windows is a somewhat sucky development environment, it
> > does not have the concept of a system header directory or standard build
> > filesystem hierarchy. One does not install Xerces-c headers to a known
> > location. Instead the source is unpacked, then you either point an
> > environment variable at it, or adjust a project file. Fine, it's part of
> > life. But since the unpacked source does not currently follow the same
> > directory tree that a UNIX/Linux install would point at, include
> > DOM_Attrib.hpp would require a different include line:
> > #include <dom/DOM_Attrib.hpp>
> > Versus:
> > #include <xercesc/dom/DOM_Attrib.hpp>
>
> The unpacked source *does* follow the same directory tree that a
> UNIX/linux install would point at. When it's unpacked it sits in
> somewhere/xercesc/
> When it's installed on UNIX the headers are in
> <prefix>/xercesc
>
> Windows users should, and can with the sane_includes tarball, do
> #include <xercesc/dom/DOM_Attrib.hpp>
What I said above I specifically said it is a restatement of the problem
on the current Xerces-c, NOT the sane_includes version. This is the part
about the sane_includes that I said should become part of the regular
Xerces-c distribution.
>
> And they can, if they want to use the old stupid way
> ( #include <dom/DOM_Attrib.hpp> )
> just by changing their include path. Where is the problem?
The problem is not the sane_includes, it is the regular official
package. My only point of disagreement in the sane_includes was that it
is not necessary to also rename "src" as "xercesc"...the includes are
after all part of the xercesc project also, and "src" seems to me to
more accurately describe the source portion of the package. I also said
that it doesn't particularly bother me that "src" is renamed "xercesc",
only that I felt it was irrelevant to accomplishing the
"include/xercesc/" include path adjustment.
>
> >
> > Possibly one could get around that with #ifdef __win32__, but that's
> > ugly. Solution 1 would be for the developer on win32 to manually copy
> > the include source so that it is in "include/xercesc/" instead of
> > "include/" somewhere else. Solution 2 would be preferable, that Xerces-c
> > unpacks directly to a structure of "include/xercesc/". It saves either
> > condition includes or manual directory copying.
> >
> > The only change that is needed to the current Xerces-c source structure
> > to make this work is that the include directory not directly contain
> > "dom", "framework", "idom", and so on, but that it contain "xercesc" and
> > that in turn "xercesc" contains those other directories. If the current
> > "src" subdirectory is to be renamed, fine, but I am saying that it is
> > not necessary. The xercesc_sane_includes changes the include directory
> > correctly, it is a needed change, other changes are not needed.
>
> I think that this doesn't make sense in light of my comments above.
It makes perfect sense because it wasn't a comment on the sane_includes
except for the part where it suggests renaming "src" as "xercesc" is
unnecessary. I am in total agreement that the include subdirectory needs
to have rearrangement in the way that sane_includes does. But it looks
like this subject has been ongoing long before I posted on it...why
didn't anyone change the include directory in all this time have
"xercesc" subdirectory? Does it need to be entered as a bugzilla report?
D. Stimits, stimits@idcomm.com
>
> > D. Stimits, stimits@idcomm.com
> >
> >
> > >
> > > > Now I noticed someone saying any changes would break their long-standing
> > > > project configurations (which dealt with problematic Xerces-c
> > > > structure), but a simple packaging scheme to have "xercesc" in the
> > > > unpack would avoid that breakage, and still give a portable directory
> > > > tree for both win and non-win users. The thing is that everyone (well,
> > > > of the projects I've seen) seems to be pointing directly at xerces
> > > > source now, rather than say /usr/local/include/, and skipping the naming
> > > > of "xercesc" stem for the include path, which is bad. But that is also
> > > > incorrect, it's better to have a modular structure to avoid future
> > > > compatibility and hack problems. The sane includes would not be a
> > > > problem for me, but I think it is a bit invasive. There are a lot of
> > > > ways it could be fixed to be uniform on both windows and non-windows,
> > > > having that extra subdirectory in unpacking just seems to be least
> > > > invasive.
> > > >
> > > > D. Stimits, stimits@idcomm.com
> > > >
> > > > >
> > > > > --
> > > > > Murray Cumming
> > > > > murrayc@usa.net
> > > > > www.murrayc.com
> > > > >
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Interested in getting changes into main Xerces distribution
Posted by Murray Cumming <mu...@t-online.de>.
On Tue, 2001-10-16 at 01:26, D. Stimits wrote:
> Murray Cumming wrote:
> >
> > On Mon, 2001-10-15 at 23:51, D. Stimits wrote:
> ...snip...
> > > >
> > > > Please comment on the sane_includes tarball.
> > >
> > > This tarball does what is required for portability in terms of providing
> > > a "xercesc" prefix to include files, regardless of whether it is via
> > > install or directly pointing at the source. It does, however, make other
> > > directory changes which are not necessary.
> >
> > Such as?
>
> The 1.5.1 tarball unpacks with a scheme where the toplevel configure.in
> is at:
> ./src/configure.in
> (and includes at ./include/DOM/ and family)
>
> The sane includes unpacks such that "src" is renamed "xercesc". While
> consistent with the project name, it isn't necessary to change the "src"
> subdirectory. It's possible it might have some aesthetic appeal, but I'd
> personally stick to "src".
>
> >
> > For those testing, it still
> > > has the default install prefix bug, the toplevel configure.in line:
> > > prefix_include=${prefix}/include/xercesc
> > >
> > > Should be edited to be:
> > > prefix_include='${PREFIX}/include/xercesc'
> > >
> > > Now I don't know if this was only intended as a partial install sample,
> > > but it also dies later (my unpack directory was
> > > /home/home1/stimits/tmp9/) with this at install:
> > >
> > > cp -fp
> > > /home/home1/stimits/tmp9/xercesc_sane_includes/lib/libxerces-c1_5_1.so
> > > /usr/local/lib
> > > cp: cannot stat
> > > `/home/home1/stimits/tmp9/xercesc_sane_includes/lib/libxerces-c1_5_1.so':
> > > No such file or directory
> > > make[1]: [install] Error 1 (ignored)
> > > make[1]: Leaving directory
> > > `/home/home1/stimits/tmp9/xercesc_sane_includes/obj'
> >
> > I can't reproduce that problem. Could you investigate?
>
> Ahh, the great bane of configuration pain. I'll try to find out, but I
> can't promise I'll succeed. I did add the patch to the toplevel
> configure.in to produce:
> prefix_include='${PREFIX}/include/xercesc'
> (adds quotes, and capitalizes PREFIX)
>
> Without that, the headers don't install. Possibly this also caused
> something else to break. I'll see if I can figure it out over the
> weekend.
>
> >
> > >
> > >
> > > If the entire tarball had unpacked into a directory of pseudo-format
> > > "version-dependent/xercesc/the_rest_of_what_it_already_is/", then no
> > > source code would require modification, and the same results would be
> > > achieved. For reference the current pseudo-code-directory-tree is
> > > "version-dependent/the_rest_of_what_it_already_is".
> >
> > I really have no idea what you're talking about. Could you try to
> > explain more concisely?
>
> Yes, I see a flaw in my argument (the paragraph above that says "src"
> doesn't need to be renamed still applies though). More change would be
> required than a simple repackaging. But perhaps a description of the
> goal would help, forgive my repetition about to show up, I'd like to
> have the problem statement available here.
>
> On every UNIX/Linux system that the header install bug is fixed on,
> regardless of whether a default prefix is used, or a custom prefix, the
> headers will be available on a path with this:
> ..../include/xercesc/....
>
> For example, somewhere on the system will be:
> ..../include/xercesc/dom/DOM_Attr.hpp
>
> The "...." could be /usr/local, it could be /usr, it might be
> ~/myheaders. No matter what that prefix is, one can include DOM_Attr.hpp
> via:
> #include <xercesc/dom/DOM_Attr.hpp>
> (and also adding a '-I${prefix}/include' to the compile line...changing
> this will allow relocation of the headers anywhere wilthout altering the
> include statement itself, and without using a quoted and inflexible
> format, e.g., without "#include
> "../../xercesc1_5_1/include/dom/DOM_Attrib.hpp")
>
> Unfortunately, windows is a somewhat sucky development environment, it
> does not have the concept of a system header directory or standard build
> filesystem hierarchy. One does not install Xerces-c headers to a known
> location. Instead the source is unpacked, then you either point an
> environment variable at it, or adjust a project file. Fine, it's part of
> life. But since the unpacked source does not currently follow the same
> directory tree that a UNIX/Linux install would point at, include
> DOM_Attrib.hpp would require a different include line:
> #include <dom/DOM_Attrib.hpp>
> Versus:
> #include <xercesc/dom/DOM_Attrib.hpp>
The unpacked source *does* follow the same directory tree that a
UNIX/linux install would point at. When it's unpacked it sits in
somewhere/xercesc/
When it's installed on UNIX the headers are in
<prefix>/xercesc
Windows users should, and can with the sane_includes tarball, do
#include <xercesc/dom/DOM_Attrib.hpp>
And they can, if they want to use the old stupid way
( #include <dom/DOM_Attrib.hpp> )
just by changing their include path. Where is the problem?
>
> Possibly one could get around that with #ifdef __win32__, but that's
> ugly. Solution 1 would be for the developer on win32 to manually copy
> the include source so that it is in "include/xercesc/" instead of
> "include/" somewhere else. Solution 2 would be preferable, that Xerces-c
> unpacks directly to a structure of "include/xercesc/". It saves either
> condition includes or manual directory copying.
>
> The only change that is needed to the current Xerces-c source structure
> to make this work is that the include directory not directly contain
> "dom", "framework", "idom", and so on, but that it contain "xercesc" and
> that in turn "xercesc" contains those other directories. If the current
> "src" subdirectory is to be renamed, fine, but I am saying that it is
> not necessary. The xercesc_sane_includes changes the include directory
> correctly, it is a needed change, other changes are not needed.
I think that this doesn't make sense in light of my comments above.
> D. Stimits, stimits@idcomm.com
>
>
> >
> > > Now I noticed someone saying any changes would break their long-standing
> > > project configurations (which dealt with problematic Xerces-c
> > > structure), but a simple packaging scheme to have "xercesc" in the
> > > unpack would avoid that breakage, and still give a portable directory
> > > tree for both win and non-win users. The thing is that everyone (well,
> > > of the projects I've seen) seems to be pointing directly at xerces
> > > source now, rather than say /usr/local/include/, and skipping the naming
> > > of "xercesc" stem for the include path, which is bad. But that is also
> > > incorrect, it's better to have a modular structure to avoid future
> > > compatibility and hack problems. The sane includes would not be a
> > > problem for me, but I think it is a bit invasive. There are a lot of
> > > ways it could be fixed to be uniform on both windows and non-windows,
> > > having that extra subdirectory in unpacking just seems to be least
> > > invasive.
> > >
> > > D. Stimits, stimits@idcomm.com
> > >
> > > >
> > > > --
> > > > Murray Cumming
> > > > murrayc@usa.net
> > > > www.murrayc.com
> > > >
> > > > ---------------------------------------------------------------------
> > > > 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
> > murrayc@usa.net
> > www.murrayc.com
> >
> > ---------------------------------------------------------------------
> > 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
murrayc@usa.net
www.murrayc.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Interested in getting changes into main Xerces distribution
Posted by "D. Stimits" <st...@idcomm.com>.
Murray Cumming wrote:
>
> On Mon, 2001-10-15 at 23:51, D. Stimits wrote:
...snip...
> > >
> > > Please comment on the sane_includes tarball.
> >
> > This tarball does what is required for portability in terms of providing
> > a "xercesc" prefix to include files, regardless of whether it is via
> > install or directly pointing at the source. It does, however, make other
> > directory changes which are not necessary.
>
> Such as?
The 1.5.1 tarball unpacks with a scheme where the toplevel configure.in
is at:
./src/configure.in
(and includes at ./include/DOM/ and family)
The sane includes unpacks such that "src" is renamed "xercesc". While
consistent with the project name, it isn't necessary to change the "src"
subdirectory. It's possible it might have some aesthetic appeal, but I'd
personally stick to "src".
>
> For those testing, it still
> > has the default install prefix bug, the toplevel configure.in line:
> > prefix_include=${prefix}/include/xercesc
> >
> > Should be edited to be:
> > prefix_include='${PREFIX}/include/xercesc'
> >
> > Now I don't know if this was only intended as a partial install sample,
> > but it also dies later (my unpack directory was
> > /home/home1/stimits/tmp9/) with this at install:
> >
> > cp -fp
> > /home/home1/stimits/tmp9/xercesc_sane_includes/lib/libxerces-c1_5_1.so
> > /usr/local/lib
> > cp: cannot stat
> > `/home/home1/stimits/tmp9/xercesc_sane_includes/lib/libxerces-c1_5_1.so':
> > No such file or directory
> > make[1]: [install] Error 1 (ignored)
> > make[1]: Leaving directory
> > `/home/home1/stimits/tmp9/xercesc_sane_includes/obj'
>
> I can't reproduce that problem. Could you investigate?
Ahh, the great bane of configuration pain. I'll try to find out, but I
can't promise I'll succeed. I did add the patch to the toplevel
configure.in to produce:
prefix_include='${PREFIX}/include/xercesc'
(adds quotes, and capitalizes PREFIX)
Without that, the headers don't install. Possibly this also caused
something else to break. I'll see if I can figure it out over the
weekend.
>
> >
> >
> > If the entire tarball had unpacked into a directory of pseudo-format
> > "version-dependent/xercesc/the_rest_of_what_it_already_is/", then no
> > source code would require modification, and the same results would be
> > achieved. For reference the current pseudo-code-directory-tree is
> > "version-dependent/the_rest_of_what_it_already_is".
>
> I really have no idea what you're talking about. Could you try to
> explain more concisely?
Yes, I see a flaw in my argument (the paragraph above that says "src"
doesn't need to be renamed still applies though). More change would be
required than a simple repackaging. But perhaps a description of the
goal would help, forgive my repetition about to show up, I'd like to
have the problem statement available here.
On every UNIX/Linux system that the header install bug is fixed on,
regardless of whether a default prefix is used, or a custom prefix, the
headers will be available on a path with this:
..../include/xercesc/....
For example, somewhere on the system will be:
..../include/xercesc/dom/DOM_Attr.hpp
The "...." could be /usr/local, it could be /usr, it might be
~/myheaders. No matter what that prefix is, one can include DOM_Attr.hpp
via:
#include <xercesc/dom/DOM_Attr.hpp>
(and also adding a '-I${prefix}/include' to the compile line...changing
this will allow relocation of the headers anywhere wilthout altering the
include statement itself, and without using a quoted and inflexible
format, e.g., without "#include
"../../xercesc1_5_1/include/dom/DOM_Attrib.hpp")
Unfortunately, windows is a somewhat sucky development environment, it
does not have the concept of a system header directory or standard build
filesystem hierarchy. One does not install Xerces-c headers to a known
location. Instead the source is unpacked, then you either point an
environment variable at it, or adjust a project file. Fine, it's part of
life. But since the unpacked source does not currently follow the same
directory tree that a UNIX/Linux install would point at, include
DOM_Attrib.hpp would require a different include line:
#include <dom/DOM_Attrib.hpp>
Versus:
#include <xercesc/dom/DOM_Attrib.hpp>
Possibly one could get around that with #ifdef __win32__, but that's
ugly. Solution 1 would be for the developer on win32 to manually copy
the include source so that it is in "include/xercesc/" instead of
"include/" somewhere else. Solution 2 would be preferable, that Xerces-c
unpacks directly to a structure of "include/xercesc/". It saves either
condition includes or manual directory copying.
The only change that is needed to the current Xerces-c source structure
to make this work is that the include directory not directly contain
"dom", "framework", "idom", and so on, but that it contain "xercesc" and
that in turn "xercesc" contains those other directories. If the current
"src" subdirectory is to be renamed, fine, but I am saying that it is
not necessary. The xercesc_sane_includes changes the include directory
correctly, it is a needed change, other changes are not needed.
D. Stimits, stimits@idcomm.com
>
> > Now I noticed someone saying any changes would break their long-standing
> > project configurations (which dealt with problematic Xerces-c
> > structure), but a simple packaging scheme to have "xercesc" in the
> > unpack would avoid that breakage, and still give a portable directory
> > tree for both win and non-win users. The thing is that everyone (well,
> > of the projects I've seen) seems to be pointing directly at xerces
> > source now, rather than say /usr/local/include/, and skipping the naming
> > of "xercesc" stem for the include path, which is bad. But that is also
> > incorrect, it's better to have a modular structure to avoid future
> > compatibility and hack problems. The sane includes would not be a
> > problem for me, but I think it is a bit invasive. There are a lot of
> > ways it could be fixed to be uniform on both windows and non-windows,
> > having that extra subdirectory in unpacking just seems to be least
> > invasive.
> >
> > D. Stimits, stimits@idcomm.com
> >
> > >
> > > --
> > > Murray Cumming
> > > murrayc@usa.net
> > > www.murrayc.com
> > >
> > > ---------------------------------------------------------------------
> > > 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
> murrayc@usa.net
> www.murrayc.com
>
> ---------------------------------------------------------------------
> 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: Interested in getting changes into main Xerces distribution
Posted by Murray Cumming <mu...@t-online.de>.
On Mon, 2001-10-15 at 23:51, D. Stimits wrote:
> Murray Cumming wrote:
> >
> > On Mon, 2001-10-15 at 21:21, D. Stimits wrote:
> > > Michael Huedepohl wrote:
> > > >
> > > ...snip...
> > > > > > > > > > "Michael Huedepohl" <mi...@mozquito.com> writes:
> > > > > > > > > >
> > > > > > > > > > > Well, I've analyzed the configure file and found a solution:
> > > > > > > > > > > You only have to move the setting of prefix_include behind the check
> > > > > > > > > > > `test "x$prefix" = xNONE && prefix=$ac_default_prefix'.
> > > > > > > > > > > I.e., remove line 1289 and insert it after line 1376.
> > > > > > > > > > > Here is the diff output:
> > > > > > > > > > > diff -r1.4 configure
> > > > > > > > > > > 1289d1288
> > > > > > > > > > > < prefix_include=${prefix}/include/xercesc
> > > > > > > > > > > 1376a1376
> > > > > > > > > > > > prefix_include=${prefix}/include/xercesc
> > > ...snip...
> > > >
> > > > Please apply the patch as I described it above, not only adding single quotes!!!
> > > > It's necessary to use PREFIX in upper case letters, too!
> > > > Don't you know the patch command?
> > > > Apply it to configure - or apply it to configure.in and use autoconf.
> > > > If in doubt, look into Makefile.in (e.g. in the util directory)
> > > > where prefix_include is used.
> > > > For me, it works with and without the -P option on Linux, Solaris and FreeBSD.
> > > >
> > > > Michael
> > >
> > >
> > > Ok, that definitely did the trick. Now I'm going to tempt fate once
> > > more, and try to talk people into the wisdom of one change in packaging.
> > > My reason for this is to bring into alignment the Windows and
> > > non-Windows use of this package in an interchangeable way.
> > >
> > > First, the problem description. Many people have been pointing their
> > > packagages that depend on Xerces-c directly at the root of the Xerces-c
> > > unpack, and not using the /usr/local/include/xerces-c/ location (this
> > > was necessary because until now, the install was broken in
> > > configure.in). Now that this is fixed, anyone in non-windows can simply
> > > use include statements of this format:
> > > #include <xercesc/DOM/whatever...>
> > > ...and then use -I/usr/local/include, or some other variation, in the
> > > Makefile, nicely avoiding all kinds of pitfalls.
> > >
> > > Windows authors, on the other hand, do not have an install option like
> > > this. Windows users must still point at the root of the Xerces-c unpack
> > > (through a project setting or environment setting), and their source
> > > files must avoid using the "xercesc" portion of the path:
> > > #include <DOM/whatever...>
> > >
> > > This means a portable application must either have both projects pointed
> > > directly at the Xerces-c source unpack, or the windows app must use a
> > > different #include line (without "xercesc" as the prefix).
> > >
> > > The solution to making both the source tree unpacking or the correct
> > > install locations on non-windows useful would be to move the current
> > > unpack tree include directory, such that:
> > > ./include/whatever...
> > > ./src/...
> > > instead becomes:
> > > ./xercesc/whatever...
> > > ./src/...
> > >
> > > An easier (but less direct) solution would be to unpack not just into a
> > > versioned directory name, e.g., the current:
> > > ./xerces-c-src1_5_1/include/....
> > > ./xerces-c-src1_5_1/src/....
> > >
> > > But instead to:
> > > ./xerces-c-src1_5_1/xercesc/include/....
> > > ./xerces-c-src1_5_1/xercesc/src/....
> > >
> > > This latter approach would completely avoid any source file changes,
> > > only a tarball creation would change. Windows and linux/UNIX people
> > > could then both use format of #include <xercesc/...> consistently,
> > > without special installation steps or conditionals.
> >
> > Please see the archive for a big discussion, vote, and test tarball
> > about a similar issue:
> > http://marc.theaimsgroup.com/?l=xerces-c-dev&m=100013310415407&w=2
> >
> > and some relevant background mails:
> > http://marc.theaimsgroup.com/?l=xerces-c-dev&w=2&r=2&s=xercesc&q=b
> >
> > Please comment on the sane_includes tarball.
>
> This tarball does what is required for portability in terms of providing
> a "xercesc" prefix to include files, regardless of whether it is via
> install or directly pointing at the source. It does, however, make other
> directory changes which are not necessary.
Such as?
For those testing, it still
> has the default install prefix bug, the toplevel configure.in line:
> prefix_include=${prefix}/include/xercesc
>
> Should be edited to be:
> prefix_include='${PREFIX}/include/xercesc'
>
> Now I don't know if this was only intended as a partial install sample,
> but it also dies later (my unpack directory was
> /home/home1/stimits/tmp9/) with this at install:
>
> cp -fp
> /home/home1/stimits/tmp9/xercesc_sane_includes/lib/libxerces-c1_5_1.so
> /usr/local/lib
> cp: cannot stat
> `/home/home1/stimits/tmp9/xercesc_sane_includes/lib/libxerces-c1_5_1.so':
> No such file or directory
> make[1]: [install] Error 1 (ignored)
> make[1]: Leaving directory
> `/home/home1/stimits/tmp9/xercesc_sane_includes/obj'
I can't reproduce that problem. Could you investigate?
>
>
> If the entire tarball had unpacked into a directory of pseudo-format
> "version-dependent/xercesc/the_rest_of_what_it_already_is/", then no
> source code would require modification, and the same results would be
> achieved. For reference the current pseudo-code-directory-tree is
> "version-dependent/the_rest_of_what_it_already_is".
I really have no idea what you're talking about. Could you try to
explain more concisely?
> Now I noticed someone saying any changes would break their long-standing
> project configurations (which dealt with problematic Xerces-c
> structure), but a simple packaging scheme to have "xercesc" in the
> unpack would avoid that breakage, and still give a portable directory
> tree for both win and non-win users. The thing is that everyone (well,
> of the projects I've seen) seems to be pointing directly at xerces
> source now, rather than say /usr/local/include/, and skipping the naming
> of "xercesc" stem for the include path, which is bad. But that is also
> incorrect, it's better to have a modular structure to avoid future
> compatibility and hack problems. The sane includes would not be a
> problem for me, but I think it is a bit invasive. There are a lot of
> ways it could be fixed to be uniform on both windows and non-windows,
> having that extra subdirectory in unpacking just seems to be least
> invasive.
>
> D. Stimits, stimits@idcomm.com
>
> >
> > --
> > Murray Cumming
> > murrayc@usa.net
> > www.murrayc.com
> >
> > ---------------------------------------------------------------------
> > 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
murrayc@usa.net
www.murrayc.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Interested in getting changes into main Xerces distribution
Posted by "D. Stimits" <st...@idcomm.com>.
Murray Cumming wrote:
>
> On Mon, 2001-10-15 at 21:21, D. Stimits wrote:
> > Michael Huedepohl wrote:
> > >
> > ...snip...
> > > > > > > > > "Michael Huedepohl" <mi...@mozquito.com> writes:
> > > > > > > > >
> > > > > > > > > > Well, I've analyzed the configure file and found a solution:
> > > > > > > > > > You only have to move the setting of prefix_include behind the check
> > > > > > > > > > `test "x$prefix" = xNONE && prefix=$ac_default_prefix'.
> > > > > > > > > > I.e., remove line 1289 and insert it after line 1376.
> > > > > > > > > > Here is the diff output:
> > > > > > > > > > diff -r1.4 configure
> > > > > > > > > > 1289d1288
> > > > > > > > > > < prefix_include=${prefix}/include/xercesc
> > > > > > > > > > 1376a1376
> > > > > > > > > > > prefix_include=${prefix}/include/xercesc
> > ...snip...
> > >
> > > Please apply the patch as I described it above, not only adding single quotes!!!
> > > It's necessary to use PREFIX in upper case letters, too!
> > > Don't you know the patch command?
> > > Apply it to configure - or apply it to configure.in and use autoconf.
> > > If in doubt, look into Makefile.in (e.g. in the util directory)
> > > where prefix_include is used.
> > > For me, it works with and without the -P option on Linux, Solaris and FreeBSD.
> > >
> > > Michael
> >
> >
> > Ok, that definitely did the trick. Now I'm going to tempt fate once
> > more, and try to talk people into the wisdom of one change in packaging.
> > My reason for this is to bring into alignment the Windows and
> > non-Windows use of this package in an interchangeable way.
> >
> > First, the problem description. Many people have been pointing their
> > packagages that depend on Xerces-c directly at the root of the Xerces-c
> > unpack, and not using the /usr/local/include/xerces-c/ location (this
> > was necessary because until now, the install was broken in
> > configure.in). Now that this is fixed, anyone in non-windows can simply
> > use include statements of this format:
> > #include <xercesc/DOM/whatever...>
> > ...and then use -I/usr/local/include, or some other variation, in the
> > Makefile, nicely avoiding all kinds of pitfalls.
> >
> > Windows authors, on the other hand, do not have an install option like
> > this. Windows users must still point at the root of the Xerces-c unpack
> > (through a project setting or environment setting), and their source
> > files must avoid using the "xercesc" portion of the path:
> > #include <DOM/whatever...>
> >
> > This means a portable application must either have both projects pointed
> > directly at the Xerces-c source unpack, or the windows app must use a
> > different #include line (without "xercesc" as the prefix).
> >
> > The solution to making both the source tree unpacking or the correct
> > install locations on non-windows useful would be to move the current
> > unpack tree include directory, such that:
> > ./include/whatever...
> > ./src/...
> > instead becomes:
> > ./xercesc/whatever...
> > ./src/...
> >
> > An easier (but less direct) solution would be to unpack not just into a
> > versioned directory name, e.g., the current:
> > ./xerces-c-src1_5_1/include/....
> > ./xerces-c-src1_5_1/src/....
> >
> > But instead to:
> > ./xerces-c-src1_5_1/xercesc/include/....
> > ./xerces-c-src1_5_1/xercesc/src/....
> >
> > This latter approach would completely avoid any source file changes,
> > only a tarball creation would change. Windows and linux/UNIX people
> > could then both use format of #include <xercesc/...> consistently,
> > without special installation steps or conditionals.
>
> Please see the archive for a big discussion, vote, and test tarball
> about a similar issue:
> http://marc.theaimsgroup.com/?l=xerces-c-dev&m=100013310415407&w=2
>
> and some relevant background mails:
> http://marc.theaimsgroup.com/?l=xerces-c-dev&w=2&r=2&s=xercesc&q=b
>
> Please comment on the sane_includes tarball.
This tarball does what is required for portability in terms of providing
a "xercesc" prefix to include files, regardless of whether it is via
install or directly pointing at the source. It does, however, make other
directory changes which are not necessary. For those testing, it still
has the default install prefix bug, the toplevel configure.in line:
prefix_include=${prefix}/include/xercesc
Should be edited to be:
prefix_include='${PREFIX}/include/xercesc'
Now I don't know if this was only intended as a partial install sample,
but it also dies later (my unpack directory was
/home/home1/stimits/tmp9/) with this at install:
cp -fp
/home/home1/stimits/tmp9/xercesc_sane_includes/lib/libxerces-c1_5_1.so
/usr/local/lib
cp: cannot stat
`/home/home1/stimits/tmp9/xercesc_sane_includes/lib/libxerces-c1_5_1.so':
No such file or directory
make[1]: [install] Error 1 (ignored)
make[1]: Leaving directory
`/home/home1/stimits/tmp9/xercesc_sane_includes/obj'
If the entire tarball had unpacked into a directory of pseudo-format
"version-dependent/xercesc/the_rest_of_what_it_already_is/", then no
source code would require modification, and the same results would be
achieved. For reference the current pseudo-code-directory-tree is
"version-dependent/the_rest_of_what_it_already_is".
Now I noticed someone saying any changes would break their long-standing
project configurations (which dealt with problematic Xerces-c
structure), but a simple packaging scheme to have "xercesc" in the
unpack would avoid that breakage, and still give a portable directory
tree for both win and non-win users. The thing is that everyone (well,
of the projects I've seen) seems to be pointing directly at xerces
source now, rather than say /usr/local/include/, and skipping the naming
of "xercesc" stem for the include path, which is bad. But that is also
incorrect, it's better to have a modular structure to avoid future
compatibility and hack problems. The sane includes would not be a
problem for me, but I think it is a bit invasive. There are a lot of
ways it could be fixed to be uniform on both windows and non-windows,
having that extra subdirectory in unpacking just seems to be least
invasive.
D. Stimits, stimits@idcomm.com
>
> --
> Murray Cumming
> murrayc@usa.net
> www.murrayc.com
>
> ---------------------------------------------------------------------
> 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: Interested in getting changes into main Xerces distribution
Posted by Murray Cumming <mu...@t-online.de>.
On Mon, 2001-10-15 at 21:21, D. Stimits wrote:
> Michael Huedepohl wrote:
> >
> ...snip...
> > > > > > > > "Michael Huedepohl" <mi...@mozquito.com> writes:
> > > > > > > >
> > > > > > > > > Well, I've analyzed the configure file and found a solution:
> > > > > > > > > You only have to move the setting of prefix_include behind the check
> > > > > > > > > `test "x$prefix" = xNONE && prefix=$ac_default_prefix'.
> > > > > > > > > I.e., remove line 1289 and insert it after line 1376.
> > > > > > > > > Here is the diff output:
> > > > > > > > > diff -r1.4 configure
> > > > > > > > > 1289d1288
> > > > > > > > > < prefix_include=${prefix}/include/xercesc
> > > > > > > > > 1376a1376
> > > > > > > > > > prefix_include=${prefix}/include/xercesc
> ...snip...
> >
> > Please apply the patch as I described it above, not only adding single quotes!!!
> > It's necessary to use PREFIX in upper case letters, too!
> > Don't you know the patch command?
> > Apply it to configure - or apply it to configure.in and use autoconf.
> > If in doubt, look into Makefile.in (e.g. in the util directory)
> > where prefix_include is used.
> > For me, it works with and without the -P option on Linux, Solaris and FreeBSD.
> >
> > Michael
>
>
> Ok, that definitely did the trick. Now I'm going to tempt fate once
> more, and try to talk people into the wisdom of one change in packaging.
> My reason for this is to bring into alignment the Windows and
> non-Windows use of this package in an interchangeable way.
>
> First, the problem description. Many people have been pointing their
> packagages that depend on Xerces-c directly at the root of the Xerces-c
> unpack, and not using the /usr/local/include/xerces-c/ location (this
> was necessary because until now, the install was broken in
> configure.in). Now that this is fixed, anyone in non-windows can simply
> use include statements of this format:
> #include <xercesc/DOM/whatever...>
> ...and then use -I/usr/local/include, or some other variation, in the
> Makefile, nicely avoiding all kinds of pitfalls.
>
> Windows authors, on the other hand, do not have an install option like
> this. Windows users must still point at the root of the Xerces-c unpack
> (through a project setting or environment setting), and their source
> files must avoid using the "xercesc" portion of the path:
> #include <DOM/whatever...>
>
> This means a portable application must either have both projects pointed
> directly at the Xerces-c source unpack, or the windows app must use a
> different #include line (without "xercesc" as the prefix).
>
> The solution to making both the source tree unpacking or the correct
> install locations on non-windows useful would be to move the current
> unpack tree include directory, such that:
> ./include/whatever...
> ./src/...
> instead becomes:
> ./xercesc/whatever...
> ./src/...
>
> An easier (but less direct) solution would be to unpack not just into a
> versioned directory name, e.g., the current:
> ./xerces-c-src1_5_1/include/....
> ./xerces-c-src1_5_1/src/....
>
> But instead to:
> ./xerces-c-src1_5_1/xercesc/include/....
> ./xerces-c-src1_5_1/xercesc/src/....
>
> This latter approach would completely avoid any source file changes,
> only a tarball creation would change. Windows and linux/UNIX people
> could then both use format of #include <xercesc/...> consistently,
> without special installation steps or conditionals.
Please see the archive for a big discussion, vote, and test tarball
about a similar issue:
http://marc.theaimsgroup.com/?l=xerces-c-dev&m=100013310415407&w=2
and some relevant background mails:
http://marc.theaimsgroup.com/?l=xerces-c-dev&w=2&r=2&s=xercesc&q=b
Please comment on the sane_includes tarball.
--
Murray Cumming
murrayc@usa.net
www.murrayc.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Interested in getting changes into main Xerces distribution
Posted by "D. Stimits" <st...@idcomm.com>.
Michael Huedepohl wrote:
>
...snip...
> > > > > > > "Michael Huedepohl" <mi...@mozquito.com> writes:
> > > > > > >
> > > > > > > > Well, I've analyzed the configure file and found a solution:
> > > > > > > > You only have to move the setting of prefix_include behind the check
> > > > > > > > `test "x$prefix" = xNONE && prefix=$ac_default_prefix'.
> > > > > > > > I.e., remove line 1289 and insert it after line 1376.
> > > > > > > > Here is the diff output:
> > > > > > > > diff -r1.4 configure
> > > > > > > > 1289d1288
> > > > > > > > < prefix_include=${prefix}/include/xercesc
> > > > > > > > 1376a1376
> > > > > > > > > prefix_include=${prefix}/include/xercesc
...snip...
>
> Please apply the patch as I described it above, not only adding single quotes!!!
> It's necessary to use PREFIX in upper case letters, too!
> Don't you know the patch command?
> Apply it to configure - or apply it to configure.in and use autoconf.
> If in doubt, look into Makefile.in (e.g. in the util directory)
> where prefix_include is used.
> For me, it works with and without the -P option on Linux, Solaris and FreeBSD.
>
> Michael
Ok, that definitely did the trick. Now I'm going to tempt fate once
more, and try to talk people into the wisdom of one change in packaging.
My reason for this is to bring into alignment the Windows and
non-Windows use of this package in an interchangeable way.
First, the problem description. Many people have been pointing their
packagages that depend on Xerces-c directly at the root of the Xerces-c
unpack, and not using the /usr/local/include/xerces-c/ location (this
was necessary because until now, the install was broken in
configure.in). Now that this is fixed, anyone in non-windows can simply
use include statements of this format:
#include <xercesc/DOM/whatever...>
...and then use -I/usr/local/include, or some other variation, in the
Makefile, nicely avoiding all kinds of pitfalls.
Windows authors, on the other hand, do not have an install option like
this. Windows users must still point at the root of the Xerces-c unpack
(through a project setting or environment setting), and their source
files must avoid using the "xercesc" portion of the path:
#include <DOM/whatever...>
This means a portable application must either have both projects pointed
directly at the Xerces-c source unpack, or the windows app must use a
different #include line (without "xercesc" as the prefix).
The solution to making both the source tree unpacking or the correct
install locations on non-windows useful would be to move the current
unpack tree include directory, such that:
./include/whatever...
./src/...
instead becomes:
./xercesc/whatever...
./src/...
An easier (but less direct) solution would be to unpack not just into a
versioned directory name, e.g., the current:
./xerces-c-src1_5_1/include/....
./xerces-c-src1_5_1/src/....
But instead to:
./xerces-c-src1_5_1/xercesc/include/....
./xerces-c-src1_5_1/xercesc/src/....
This latter approach would completely avoid any source file changes,
only a tarball creation would change. Windows and linux/UNIX people
could then both use format of #include <xercesc/...> consistently,
without special installation steps or conditionals.
D. Stimits, stimits@idcomm.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Interested in getting changes into main Xerces distribution
Posted by Michael Huedepohl <mi...@mozquito.com>.
"D. Stimits" wrote:
>
> "D. Stimits" wrote:
> >
> > Michael Huedepohl wrote:
> > >
> > > "Jason E. Stewart" wrote:
> > > >
> > > > "Michael Huedepohl" <mi...@mozquito.com> writes:
> > > >
> > > > > "Jason E. Stewart" wrote:
> > > > > >
> > > > > > "Michael Huedepohl" <mi...@mozquito.com> writes:
> > > > > >
> > > > > > > Well, I've analyzed the configure file and found a solution:
> > > > > > > You only have to move the setting of prefix_include behind the check
> > > > > > > `test "x$prefix" = xNONE && prefix=$ac_default_prefix'.
> > > > > > > I.e., remove line 1289 and insert it after line 1376.
> > > > > > > Here is the diff output:
> > > > > > > diff -r1.4 configure
> > > > > > > 1289d1288
> > > > > > > < prefix_include=${prefix}/include/xercesc
> > > > > > > 1376a1376
> > > > > > > > prefix_include=${prefix}/include/xercesc
> > > > > > >
> > > > > > > Can you commit this change?
> > > > > >
> > > > > > No. Because configure is automatically generated from configure.in
> > > > > > using autoconf. Any changes to configure will be lost the next time
> > > > > > someone runs autoconf.
> > > > >
> > > > > Are you really sure?
> > > >
> > > > $ cp ./configure ./configure.bak
> > > > $ autoconf
> > > > $ diff ./configure ./configure.bak
> > > > $
> > > >
> > > > Seems to be.
> > >
> > > Okay, I had to step deeper into the autoconf mechanism.
> > > Now I found a solution for configure.in, here is the diff
> > > for configure.in:
> > >
> > > 66c66
> > > < prefix_include=${prefix}/include/xercesc
> > > ---
> > > > prefix_include='${PREFIX}/include/xercesc'
> >
> > Unfortunately, this didn't seem to fix it for me (on Redhat 7.1). The
> > quoting change appears to be a valid addition, but insufficient. The
> > generated configure file has this line unchanged:
> > ac_default_prefix=/usr/local
> > ...which looks right, but it is being ignored.
> >
> > Further down in the configure file, the additional quotes come through
> > correctly, but "prefix" is till not even looking at ac_default_prefix
> > (it appears ac_default_prefix is inert):
> > prefix=NONE
> >
> > I did not investigate if there is code somewhere that is supposed to
> > test "prefix" for "NONE", and substitute "/usr/local" only if it is
> > currently "NONE", but the install still failed to copy header files. The
> > "NONE" directories are still being used, rather than
> > /usr/local/include/xercesc/.
> >
> > It would be interesting if autoconf and friends had a debugger with
> > breakpoints and watches, oh well.
> >
> > D. Stimits, stimits@idcomm.com
>
> Ok, I am coming up with a new twist. Careful view of text ("tee" is a
> wonderful tool), I discovered it is installing to
> /include/xercesc/....in other words, it is creating "include" in the
> root of the entire filesystem. I have the changes to add single quotes
> for prefix_include, so instead of going to "NONE" it is now calling it
> an empty string, and then it is directly appending "/include/xercesc" to
> that. More testing later, but it very much appears that
> ac_default_prefix is completely ignored.
Please apply the patch as I described it above, not only adding single quotes!!!
It's necessary to use PREFIX in upper case letters, too!
Don't you know the patch command?
Apply it to configure - or apply it to configure.in and use autoconf.
If in doubt, look into Makefile.in (e.g. in the util directory)
where prefix_include is used.
For me, it works with and without the -P option on Linux, Solaris and FreeBSD.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Interested in getting changes into main Xerces distribution
Posted by "D. Stimits" <st...@idcomm.com>.
"D. Stimits" wrote:
>
> Michael Huedepohl wrote:
> >
> > "Jason E. Stewart" wrote:
> > >
> > > "Michael Huedepohl" <mi...@mozquito.com> writes:
> > >
> > > > "Jason E. Stewart" wrote:
> > > > >
> > > > > "Michael Huedepohl" <mi...@mozquito.com> writes:
> > > > >
> > > > > > Well, I've analyzed the configure file and found a solution:
> > > > > > You only have to move the setting of prefix_include behind the check
> > > > > > `test "x$prefix" = xNONE && prefix=$ac_default_prefix'.
> > > > > > I.e., remove line 1289 and insert it after line 1376.
> > > > > > Here is the diff output:
> > > > > > diff -r1.4 configure
> > > > > > 1289d1288
> > > > > > < prefix_include=${prefix}/include/xercesc
> > > > > > 1376a1376
> > > > > > > prefix_include=${prefix}/include/xercesc
> > > > > >
> > > > > > Can you commit this change?
> > > > >
> > > > > No. Because configure is automatically generated from configure.in
> > > > > using autoconf. Any changes to configure will be lost the next time
> > > > > someone runs autoconf.
> > > >
> > > > Are you really sure?
> > >
> > > $ cp ./configure ./configure.bak
> > > $ autoconf
> > > $ diff ./configure ./configure.bak
> > > $
> > >
> > > Seems to be.
> >
> > Okay, I had to step deeper into the autoconf mechanism.
> > Now I found a solution for configure.in, here is the diff
> > for configure.in:
> >
> > 66c66
> > < prefix_include=${prefix}/include/xercesc
> > ---
> > > prefix_include='${PREFIX}/include/xercesc'
>
> Unfortunately, this didn't seem to fix it for me (on Redhat 7.1). The
> quoting change appears to be a valid addition, but insufficient. The
> generated configure file has this line unchanged:
> ac_default_prefix=/usr/local
> ...which looks right, but it is being ignored.
>
> Further down in the configure file, the additional quotes come through
> correctly, but "prefix" is till not even looking at ac_default_prefix
> (it appears ac_default_prefix is inert):
> prefix=NONE
>
> I did not investigate if there is code somewhere that is supposed to
> test "prefix" for "NONE", and substitute "/usr/local" only if it is
> currently "NONE", but the install still failed to copy header files. The
> "NONE" directories are still being used, rather than
> /usr/local/include/xercesc/.
>
> It would be interesting if autoconf and friends had a debugger with
> breakpoints and watches, oh well.
>
> D. Stimits, stimits@idcomm.com
Ok, I am coming up with a new twist. Careful view of text ("tee" is a
wonderful tool), I discovered it is installing to
/include/xercesc/....in other words, it is creating "include" in the
root of the entire filesystem. I have the changes to add single quotes
for prefix_include, so instead of going to "NONE" it is now calling it
an empty string, and then it is directly appending "/include/xercesc" to
that. More testing later, but it very much appears that
ac_default_prefix is completely ignored.
D. Stimits, stimtis@idcomm.com
>
> >
> > And here is the diff for configure (identical to the result of autoconf,
> > for systems without autoconf):
> >
> > 1289c1289
> > < prefix_include=${prefix}/include/xercesc
> > ---
> > > prefix_include='${PREFIX}/include/xercesc'
> >
> > I tested this with the default prefix setting and with the -P option
> > for runConfigure, and it worked.
> >
> > Hope you can commit it now.
> >
> > Michael
> >
> > ---------------------------------------------------------------------
> > 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
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Interested in getting changes into main Xerces distribution
Posted by "D. Stimits" <st...@idcomm.com>.
Michael Huedepohl wrote:
>
> "Jason E. Stewart" wrote:
> >
> > "Michael Huedepohl" <mi...@mozquito.com> writes:
> >
> > > "Jason E. Stewart" wrote:
> > > >
> > > > "Michael Huedepohl" <mi...@mozquito.com> writes:
> > > >
> > > > > Well, I've analyzed the configure file and found a solution:
> > > > > You only have to move the setting of prefix_include behind the check
> > > > > `test "x$prefix" = xNONE && prefix=$ac_default_prefix'.
> > > > > I.e., remove line 1289 and insert it after line 1376.
> > > > > Here is the diff output:
> > > > > diff -r1.4 configure
> > > > > 1289d1288
> > > > > < prefix_include=${prefix}/include/xercesc
> > > > > 1376a1376
> > > > > > prefix_include=${prefix}/include/xercesc
> > > > >
> > > > > Can you commit this change?
> > > >
> > > > No. Because configure is automatically generated from configure.in
> > > > using autoconf. Any changes to configure will be lost the next time
> > > > someone runs autoconf.
> > >
> > > Are you really sure?
> >
> > $ cp ./configure ./configure.bak
> > $ autoconf
> > $ diff ./configure ./configure.bak
> > $
> >
> > Seems to be.
>
> Okay, I had to step deeper into the autoconf mechanism.
> Now I found a solution for configure.in, here is the diff
> for configure.in:
>
> 66c66
> < prefix_include=${prefix}/include/xercesc
> ---
> > prefix_include='${PREFIX}/include/xercesc'
Unfortunately, this didn't seem to fix it for me (on Redhat 7.1). The
quoting change appears to be a valid addition, but insufficient. The
generated configure file has this line unchanged:
ac_default_prefix=/usr/local
...which looks right, but it is being ignored.
Further down in the configure file, the additional quotes come through
correctly, but "prefix" is till not even looking at ac_default_prefix
(it appears ac_default_prefix is inert):
prefix=NONE
I did not investigate if there is code somewhere that is supposed to
test "prefix" for "NONE", and substitute "/usr/local" only if it is
currently "NONE", but the install still failed to copy header files. The
"NONE" directories are still being used, rather than
/usr/local/include/xercesc/.
It would be interesting if autoconf and friends had a debugger with
breakpoints and watches, oh well.
D. Stimits, stimits@idcomm.com
>
> And here is the diff for configure (identical to the result of autoconf,
> for systems without autoconf):
>
> 1289c1289
> < prefix_include=${prefix}/include/xercesc
> ---
> > prefix_include='${PREFIX}/include/xercesc'
>
> I tested this with the default prefix setting and with the -P option
> for runConfigure, and it worked.
>
> Hope you can commit it now.
>
> Michael
>
> ---------------------------------------------------------------------
> 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: Interested in getting changes into main Xerces distribution
Posted by "D. Stimits" <st...@idcomm.com>.
"Jason E. Stewart" wrote:
>
> "D. Stimits" <st...@idcomm.com> writes:
>
> > > 1289c1289
> > > < prefix_include=${prefix}/include/xercesc
> > > ---
> > > > prefix_include='${PREFIX}/include/xercesc'
> > >
> > > I tested this with the default prefix setting and with the -P option
> > > for runConfigure, and it worked.
> > >
> > > Hope you can commit it now.
> > >
> > > Michael
> >
> > Michael, I'm wondering what version of autoconf is installed on your
> > system? I'm using 2.13.
>
> No point modifying the configure file, use the modification to
> configure.in that was posted. I've tested it on debian with autoconf
> 2.13 and it works fine.
The fix was applied to the configure.in file, not configure. Then things
were configured new. Some of the changes propagated as expected to the
new configure file, but the results were not as expected. Instead of
replacing "prefix" with "/usr/local" afterwords, it turned it into an
empty string in locations it was substituted. Prior to that it played
dumb and used a literal "NONE". There is a lot going on in this kind of
configuration, I don't know where the interaction is different between
your version and mine, but versions of autoconf and friends is usually a
prime suspect (there are extreme changes over various versions of
autoconf).
D. Stimits, stimits@idcomm.com
>
> jas.
>
> ---------------------------------------------------------------------
> 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: Interested in getting changes into main Xerces distribution
Posted by "Jason E. Stewart" <ja...@openinformatics.com>.
"D. Stimits" <st...@idcomm.com> writes:
> > 1289c1289
> > < prefix_include=${prefix}/include/xercesc
> > ---
> > > prefix_include='${PREFIX}/include/xercesc'
> >
> > I tested this with the default prefix setting and with the -P option
> > for runConfigure, and it worked.
> >
> > Hope you can commit it now.
> >
> > Michael
>
> Michael, I'm wondering what version of autoconf is installed on your
> system? I'm using 2.13.
No point modifying the configure file, use the modification to
configure.in that was posted. I've tested it on debian with autoconf
2.13 and it works fine.
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: Interested in getting changes into main Xerces distribution
Posted by "D. Stimits" <st...@idcomm.com>.
Michael Huedepohl wrote:
>
> "Jason E. Stewart" wrote:
> >
> > "Michael Huedepohl" <mi...@mozquito.com> writes:
> >
> > > "Jason E. Stewart" wrote:
> > > >
> > > > "Michael Huedepohl" <mi...@mozquito.com> writes:
> > > >
> > > > > Well, I've analyzed the configure file and found a solution:
> > > > > You only have to move the setting of prefix_include behind the check
> > > > > `test "x$prefix" = xNONE && prefix=$ac_default_prefix'.
> > > > > I.e., remove line 1289 and insert it after line 1376.
> > > > > Here is the diff output:
> > > > > diff -r1.4 configure
> > > > > 1289d1288
> > > > > < prefix_include=${prefix}/include/xercesc
> > > > > 1376a1376
> > > > > > prefix_include=${prefix}/include/xercesc
> > > > >
> > > > > Can you commit this change?
> > > >
> > > > No. Because configure is automatically generated from configure.in
> > > > using autoconf. Any changes to configure will be lost the next time
> > > > someone runs autoconf.
> > >
> > > Are you really sure?
> >
> > $ cp ./configure ./configure.bak
> > $ autoconf
> > $ diff ./configure ./configure.bak
> > $
> >
> > Seems to be.
>
> Okay, I had to step deeper into the autoconf mechanism.
> Now I found a solution for configure.in, here is the diff
> for configure.in:
>
> 66c66
> < prefix_include=${prefix}/include/xercesc
> ---
> > prefix_include='${PREFIX}/include/xercesc'
>
> And here is the diff for configure (identical to the result of autoconf,
> for systems without autoconf):
>
> 1289c1289
> < prefix_include=${prefix}/include/xercesc
> ---
> > prefix_include='${PREFIX}/include/xercesc'
>
> I tested this with the default prefix setting and with the -P option
> for runConfigure, and it worked.
>
> Hope you can commit it now.
>
> Michael
Michael, I'm wondering what version of autoconf is installed on your
system? I'm using 2.13.
D. Stimits, stimits@idcomm.com
>
> ---------------------------------------------------------------------
> 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: Interested in getting changes into main Xerces distribution
Posted by Michael Huedepohl <mi...@mozquito.com>.
"Jason E. Stewart" wrote:
>
> "Michael Huedepohl" <mi...@mozquito.com> writes:
>
> > "Jason E. Stewart" wrote:
> > >
> > > "Michael Huedepohl" <mi...@mozquito.com> writes:
> > >
> > > > Well, I've analyzed the configure file and found a solution:
> > > > You only have to move the setting of prefix_include behind the check
> > > > `test "x$prefix" = xNONE && prefix=$ac_default_prefix'.
> > > > I.e., remove line 1289 and insert it after line 1376.
> > > > Here is the diff output:
> > > > diff -r1.4 configure
> > > > 1289d1288
> > > > < prefix_include=${prefix}/include/xercesc
> > > > 1376a1376
> > > > > prefix_include=${prefix}/include/xercesc
> > > >
> > > > Can you commit this change?
> > >
> > > No. Because configure is automatically generated from configure.in
> > > using autoconf. Any changes to configure will be lost the next time
> > > someone runs autoconf.
> >
> > Are you really sure?
>
> $ cp ./configure ./configure.bak
> $ autoconf
> $ diff ./configure ./configure.bak
> $
>
> Seems to be.
Okay, I had to step deeper into the autoconf mechanism.
Now I found a solution for configure.in, here is the diff
for configure.in:
66c66
< prefix_include=${prefix}/include/xercesc
---
> prefix_include='${PREFIX}/include/xercesc'
And here is the diff for configure (identical to the result of autoconf,
for systems without autoconf):
1289c1289
< prefix_include=${prefix}/include/xercesc
---
> prefix_include='${PREFIX}/include/xercesc'
I tested this with the default prefix setting and with the -P option
for runConfigure, and it worked.
Hope you can commit it now.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Interested in getting changes into main Xerces distribution
Posted by "Jason E. Stewart" <ja...@openinformatics.com>.
"Michael Huedepohl" <mi...@mozquito.com> writes:
> "Jason E. Stewart" wrote:
> >
> > "Michael Huedepohl" <mi...@mozquito.com> writes:
> >
> > > Well, I've analyzed the configure file and found a solution:
> > > You only have to move the setting of prefix_include behind the check
> > > `test "x$prefix" = xNONE && prefix=$ac_default_prefix'.
> > > I.e., remove line 1289 and insert it after line 1376.
> > > Here is the diff output:
> > > diff -r1.4 configure
> > > 1289d1288
> > > < prefix_include=${prefix}/include/xercesc
> > > 1376a1376
> > > > prefix_include=${prefix}/include/xercesc
> > >
> > > Can you commit this change?
> >
> > No. Because configure is automatically generated from configure.in
> > using autoconf. Any changes to configure will be lost the next time
> > someone runs autoconf.
>
> Are you really sure?
$ cp ./configure ./configure.bak
$ autoconf
$ diff ./configure ./configure.bak
$
Seems to be.
> At some point earlier in this thread, it was mentioned that the
> auto* tools are not (yet) used for Xerces-C.
Yes, I believe they meant that 'the GNU tools are not (properly or
completely) used ...'. Having looked at the threads in the archives
from last year when Peter Koellner was working on this problem, it
seems that there is just a lot that ought to be done with
automake/autoconf that isn't.
http://marc.theaimsgroup.com/?l=xerces-c-dev&m=97158781207970&w=2
> By sure, autoconf is not used on the target system during
> runConfigure etc.
Once you have generated configure, there is no need to use autoconf,
and configure is definately used by runConfigure.
> Remains the possibility on the Xerces side, before creating the
> tarball. The configure script is part of the tarball - and it's in
> the CVS, isn't it? If you look into "configure", you will see a lot
> of comments which don't look at all like an output of autoconf, they
> are very special. So, at the most, it might be a semi-automatic
> process in the way that configure has been created from configure.in
> and then edited manually.
>
> >
> > Something will have to be modified in configure.in.
>
> I cannot find anything wrong in configure.in, the only relevant part there is
>
> AC_SUBST(prefix)
> prefix_include=${prefix}/include/xercesc
> AC_SUBST(prefix_include)
>
> and that seems to be in the correct order.
> So I still suppose someone has edited "configure" afterwards,
> breaking the default setting of prefix_include.
like my diff shows, I don't think that was done.
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: Interested in getting changes into main Xerces distribution
Posted by Michael Huedepohl <mi...@mozquito.com>.
"Jason E. Stewart" wrote:
>
> "Michael Huedepohl" <mi...@mozquito.com> writes:
>
> > Well, I've analyzed the configure file and found a solution:
> > You only have to move the setting of prefix_include behind the check
> > `test "x$prefix" = xNONE && prefix=$ac_default_prefix'.
> > I.e., remove line 1289 and insert it after line 1376.
> > Here is the diff output:
> > diff -r1.4 configure
> > 1289d1288
> > < prefix_include=${prefix}/include/xercesc
> > 1376a1376
> > > prefix_include=${prefix}/include/xercesc
> >
> > Can you commit this change?
>
> No. Because configure is automatically generated from configure.in
> using autoconf. Any changes to configure will be lost the next time
> someone runs autoconf.
Are you really sure? At some point earlier in this thread, it was
mentioned that the auto* tools are not (yet) used for Xerces-C.
By sure, autoconf is not used on the target system during runConfigure etc.
Remains the possibility on the Xerces side, before creating the tarball.
The configure script is part of the tarball - and it's in the CVS, isn't it?
If you look into "configure", you will see a lot of comments which don't
look at all like an output of autoconf, they are very special.
So, at the most, it might be a semi-automatic process in the way that
configure has been created from configure.in and then edited manually.
>
> Something will have to be modified in configure.in.
I cannot find anything wrong in configure.in, the only relevant part there is
AC_SUBST(prefix)
prefix_include=${prefix}/include/xercesc
AC_SUBST(prefix_include)
and that seems to be in the correct order.
So I still suppose someone has edited "configure" afterwards,
breaking the default setting of prefix_include.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Interested in getting changes into main Xerces distribution
Posted by "Jason E. Stewart" <ja...@openinformatics.com>.
"Michael Huedepohl" <mi...@mozquito.com> writes:
> Well, I've analyzed the configure file and found a solution:
> You only have to move the setting of prefix_include behind the check
> `test "x$prefix" = xNONE && prefix=$ac_default_prefix'.
> I.e., remove line 1289 and insert it after line 1376.
> Here is the diff output:
> diff -r1.4 configure
> 1289d1288
> < prefix_include=${prefix}/include/xercesc
> 1376a1376
> > prefix_include=${prefix}/include/xercesc
>
> Can you commit this change?
No. Because configure is automatically generated from configure.in
using autoconf. Any changes to configure will be lost the next time
someone runs autoconf.
Something will have to be modified in configure.in.
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: Interested in getting changes into main Xerces distribution
Posted by Michael Huedepohl <mi...@mozquito.com>.
Murray Cumming wrote:
>
> On Thu, 2001-10-11 at 15:09, Michael Huedepohl wrote:
> > Murray Cumming wrote:
> > >
> > > On Thu, 2001-10-11 at 01:01, D. Stimits wrote:
> > > > Murray Cumming wrote:
> > > > >
> > > > > On Thu, 2001-10-11 at 00:02, D. Stimits wrote:
> > > > > > Murray Cumming wrote:
> > > > > > >
> > > > > > > On Wed, 2001-10-10 at 19:02, D. Stimits wrote:
> > > > > > > > Where would I post, or ask for changes to the official Xerces
> > > > > > > > distribution?
> > > > > > >
> > > > > > > Erm, this list, of course.
> > > > > > >
> > > > > > > Right now, the immediate change (and I can provide
> > > > > > > > Makefile patches if desired) would be that make install fails to place
> > > > > > > > headers for devel in any conventional location,
> > > > > > >
> > > > > > > Since Xerces-C 1.5.1, the headers have gone into <prefix>/include.
> > > > > > > What's wrong with that?
> > > > > >
> > > > > > Well, in general, "include" is a _really bad_ (did I mention "really
> > > > > > really" bad also?)
> > > > >
> > > > > Sorry, I mean that since 1.5.1 the headers have gone into
> > > > > <prefix>/include/xercesc. There is no problem with where the headers are
> > > > > installed.
> > > >
> > > > This is good. I'm using 1.5.1 though, and headers are not being
> > > > installed at all during make install.
> > >
> > > First you say that they are installed to 'random' locations, then you
> > > say that they are not installed at all. I'm sure that it's working for
> > > me. I personally changed the headers install path from <prefix>/include
> > > to <prefix>/include/xercesc so I know that there stuff in there to
> > > install the headers.
> >
> > Excuse me for intervening, but I can confirm that - e.g. on Solaris 8 -
> > if you don't specify anything for <prefix>, i.e. using the default /usr/local
> > (and I haven't seen documented how to configure the prefix),
>
> ./runConfigure -P<prefix>, I think.
>
> runConfigure has help output, either with no args or with --help, I
> don't remember.
Sorry, I found it just after sending my email - indeed, it's printed with the
help message (runConfigure with no args).
I tried runConfigure earlier (pre 1.5.1) and didn't get a message about the
install prefix, and I missed to check it again with version 1.5.1.
>
> > the "make install" does install the library, but not the include files!
>
> OK, I haven't discovered this because I always need to specify /usr on
> Redhat. Would anyone like to try to fix this? Sorry, I'm busy on other
> stuff at the moment.
Well, I've analyzed the configure file and found a solution:
You only have to move the setting of prefix_include behind the check
`test "x$prefix" = xNONE && prefix=$ac_default_prefix'.
I.e., remove line 1289 and insert it after line 1376.
Here is the diff output:
diff -r1.4 configure
1289d1288
< prefix_include=${prefix}/include/xercesc
1376a1376
> prefix_include=${prefix}/include/xercesc
Can you commit this change?
Cheers, Michael
>
> > Instead, they are installed in the source tree in several subdirectories
> > named "NONE":
> >
> > $ cd $XERCESCROOT/src
> > $ ./runConfigure -p solaris -cgcc -xg++ -nsocket -tnative -rpthread
> > (...)
> > $ make
> > (...)
> > $ make install
> > cd util && make install && cd ..
> > make[1]: Entering directory `/home/michael/xerces/src/util'
> > mkdir -p NONE/include/xercesc/util
> > (...)
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Interested in getting changes into main Xerces distribution
Posted by Murray Cumming <mu...@t-online.de>.
On Thu, 2001-10-11 at 15:09, Michael Huedepohl wrote:
> Murray Cumming wrote:
> >
> > On Thu, 2001-10-11 at 01:01, D. Stimits wrote:
> > > Murray Cumming wrote:
> > > >
> > > > On Thu, 2001-10-11 at 00:02, D. Stimits wrote:
> > > > > Murray Cumming wrote:
> > > > > >
> > > > > > On Wed, 2001-10-10 at 19:02, D. Stimits wrote:
> > > > > > > Where would I post, or ask for changes to the official Xerces
> > > > > > > distribution?
> > > > > >
> > > > > > Erm, this list, of course.
> > > > > >
> > > > > > Right now, the immediate change (and I can provide
> > > > > > > Makefile patches if desired) would be that make install fails to place
> > > > > > > headers for devel in any conventional location,
> > > > > >
> > > > > > Since Xerces-C 1.5.1, the headers have gone into <prefix>/include.
> > > > > > What's wrong with that?
> > > > >
> > > > > Well, in general, "include" is a _really bad_ (did I mention "really
> > > > > really" bad also?)
> > > >
> > > > Sorry, I mean that since 1.5.1 the headers have gone into
> > > > <prefix>/include/xercesc. There is no problem with where the headers are
> > > > installed.
> > >
> > > This is good. I'm using 1.5.1 though, and headers are not being
> > > installed at all during make install.
> >
> > First you say that they are installed to 'random' locations, then you
> > say that they are not installed at all. I'm sure that it's working for
> > me. I personally changed the headers install path from <prefix>/include
> > to <prefix>/include/xercesc so I know that there stuff in there to
> > install the headers.
>
> Excuse me for intervening, but I can confirm that - e.g. on Solaris 8 -
> if you don't specify anything for <prefix>, i.e. using the default /usr/local
> (and I haven't seen documented how to configure the prefix),
./runConfigure -P<prefix>, I think.
runConfigure has help output, either with no args or with --help, I
don't remember.
> the "make install" does install the library, but not the include files!
OK, I haven't discovered this because I always need to specify /usr on
Redhat. Would anyone like to try to fix this? Sorry, I'm busy on other
stuff at the moment.
> Instead, they are installed in the source tree in several subdirectories
> named "NONE":
>
> $ cd $XERCESCROOT/src
> $ ./runConfigure -p solaris -cgcc -xg++ -nsocket -tnative -rpthread
> (...)
> $ make
> (...)
> $ make install
> cd util && make install && cd ..
> make[1]: Entering directory `/home/michael/xerces/src/util'
> mkdir -p NONE/include/xercesc/util
> (...)
> cp -fp
> /home/michael/cvs/products/webaccess/components/xerces/lib/libxerces-c1_5_1.so
> /usr/local/lib
>
>
> Michael
>
> ---------------------------------------------------------------------
> 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
murrayc@usa.net
www.murrayc.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Interested in getting changes into main Xerces distribution
Posted by Michael Huedepohl <mi...@mozquito.com>.
Murray Cumming wrote:
>
> On Thu, 2001-10-11 at 01:01, D. Stimits wrote:
> > Murray Cumming wrote:
> > >
> > > On Thu, 2001-10-11 at 00:02, D. Stimits wrote:
> > > > Murray Cumming wrote:
> > > > >
> > > > > On Wed, 2001-10-10 at 19:02, D. Stimits wrote:
> > > > > > Where would I post, or ask for changes to the official Xerces
> > > > > > distribution?
> > > > >
> > > > > Erm, this list, of course.
> > > > >
> > > > > Right now, the immediate change (and I can provide
> > > > > > Makefile patches if desired) would be that make install fails to place
> > > > > > headers for devel in any conventional location,
> > > > >
> > > > > Since Xerces-C 1.5.1, the headers have gone into <prefix>/include.
> > > > > What's wrong with that?
> > > >
> > > > Well, in general, "include" is a _really bad_ (did I mention "really
> > > > really" bad also?)
> > >
> > > Sorry, I mean that since 1.5.1 the headers have gone into
> > > <prefix>/include/xercesc. There is no problem with where the headers are
> > > installed.
> >
> > This is good. I'm using 1.5.1 though, and headers are not being
> > installed at all during make install.
>
> First you say that they are installed to 'random' locations, then you
> say that they are not installed at all. I'm sure that it's working for
> me. I personally changed the headers install path from <prefix>/include
> to <prefix>/include/xercesc so I know that there stuff in there to
> install the headers.
Excuse me for intervening, but I can confirm that - e.g. on Solaris 8 -
if you don't specify anything for <prefix>, i.e. using the default /usr/local
(and I haven't seen documented how to configure the prefix),
the "make install" does install the library, but not the include files!
Instead, they are installed in the source tree in several subdirectories
named "NONE":
$ cd $XERCESCROOT/src
$ ./runConfigure -p solaris -cgcc -xg++ -nsocket -tnative -rpthread
(...)
$ make
(...)
$ make install
cd util && make install && cd ..
make[1]: Entering directory `/home/michael/xerces/src/util'
mkdir -p NONE/include/xercesc/util
(...)
cp -fp
/home/michael/cvs/products/webaccess/components/xerces/lib/libxerces-c1_5_1.so
/usr/local/lib
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Interested in getting changes into main Xerces distribution
Posted by "D. Stimits" <st...@idcomm.com>.
Murray Cumming wrote:
>
> On Thu, 2001-10-11 at 18:49, D. Stimits wrote:
> > Murray Cumming wrote:
> > >
> > > Part 1.1 Type: Plain Text (text/plain)
> > > Encoding: 7bit
> >
> > Environment variables pass through to Makefile variables. Having
> > environment variables set to some of the values, whether it is
> > XERCESCROOT, THREADS, CC, or CXX, means you have done the equivalent of
> > explicitly naming those values. Having environment variables set means
> > you have not used a single default setting. To test what I am saying,
> > one must not have Makefile variables set in the environment.
>
> Yada yada. If I'm not aware of having set any other environment
> variables, is it likely that I have set any other environment variables?
>
> Not only
> > have I also tested this, others have verified it. Your environment may
> > be fooling you into believing there is no bug.
>
> If you read the mails, you would see that we have all agreed that this
> *is* a problem when the prefix is not specified. Someone has already
> posted a partial fix for this.
I empty my email at night before going to sleep. When I wake up in the
morning, I average 270 to 370 new emails. I spend about half an hour
fast deleting uninteresting stuff (90%), another half hour dealing with
things I have to look at but which are quick (9%), and a few hours
dealing with the final 1%. I tend to read and respond to things in the
order they were received on that last 1%. About every 3 days I empty my
email trash when it exceeds 2000 messages. So yes, I am aware of this,
but wasn't at the moment of answering, it was out of chronological
sequence.
>
> >
> > D. Stimits, stimits@idcomm.com
> >
> > PS: Having XERCESCROOT not default to the root of the tarball unpack,
> > and having it require manual intervention, is clumsy. It interferes with
> > clean install of Xerces-c within compound projects. No, it isn't a bug,
> > but it would be better if a build didn't have to be told where its own
> > location is in order to build, it could detect this easily enough if not
> > manually specified.
>
> I agree. Do you have a patch to add this behaviour?
No, but if it is possible to get changes in, I will work on it. Just
takes time, and being convinced I won't waste my effort.
D. Stimits, stimits@idcomm.com
>
> --
> Murray Cumming
> murrayc@usa.net
> www.murrayc.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Interested in getting changes into main Xerces distribution
Posted by Murray Cumming <mu...@t-online.de>.
On Thu, 2001-10-11 at 18:49, D. Stimits wrote:
> Murray Cumming wrote:
> >
> > Part 1.1 Type: Plain Text (text/plain)
> > Encoding: 7bit
>
> Environment variables pass through to Makefile variables. Having
> environment variables set to some of the values, whether it is
> XERCESCROOT, THREADS, CC, or CXX, means you have done the equivalent of
> explicitly naming those values. Having environment variables set means
> you have not used a single default setting. To test what I am saying,
> one must not have Makefile variables set in the environment.
Yada yada. If I'm not aware of having set any other environment
variables, is it likely that I have set any other environment variables?
Not only
> have I also tested this, others have verified it. Your environment may
> be fooling you into believing there is no bug.
If you read the mails, you would see that we have all agreed that this
*is* a problem when the prefix is not specified. Someone has already
posted a partial fix for this.
>
> D. Stimits, stimits@idcomm.com
>
> PS: Having XERCESCROOT not default to the root of the tarball unpack,
> and having it require manual intervention, is clumsy. It interferes with
> clean install of Xerces-c within compound projects. No, it isn't a bug,
> but it would be better if a build didn't have to be told where its own
> location is in order to build, it could detect this easily enough if not
> manually specified.
I agree. Do you have a patch to add this behaviour?
--
Murray Cumming
murrayc@usa.net
www.murrayc.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Interested in getting changes into main Xerces distribution
Posted by "D. Stimits" <st...@idcomm.com>.
Murray Cumming wrote:
>
> Part 1.1 Type: Plain Text (text/plain)
> Encoding: 7bit
Environment variables pass through to Makefile variables. Having
environment variables set to some of the values, whether it is
XERCESCROOT, THREADS, CC, or CXX, means you have done the equivalent of
explicitly naming those values. Having environment variables set means
you have not used a single default setting. To test what I am saying,
one must not have Makefile variables set in the environment. Not only
have I also tested this, others have verified it. Your environment may
be fooling you into believing there is no bug.
D. Stimits, stimits@idcomm.com
PS: Having XERCESCROOT not default to the root of the tarball unpack,
and having it require manual intervention, is clumsy. It interferes with
clean install of Xerces-c within compound projects. No, it isn't a bug,
but it would be better if a build didn't have to be told where its own
location is in order to build, it could detect this easily enough if not
manually specified.
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Interested in getting changes into main Xerces distribution
Posted by Murray Cumming <mu...@t-online.de>.
On Thu, 2001-10-11 at 02:59, D. Stimits wrote:
> Murray Cumming wrote:
> >
> > On Thu, 2001-10-11 at 01:01, D. Stimits wrote:
> > > Murray Cumming wrote:
> > > >
> > > > On Thu, 2001-10-11 at 00:02, D. Stimits wrote:
> > > > > Murray Cumming wrote:
> > > > > >
> > > > > > On Wed, 2001-10-10 at 19:02, D. Stimits wrote:
> > > > > > > Where would I post, or ask for changes to the official Xerces
> > > > > > > distribution?
> > > > > >
> > > > > > Erm, this list, of course.
> > > > > >
> > > > > > Right now, the immediate change (and I can provide
> > > > > > > Makefile patches if desired) would be that make install fails to place
> > > > > > > headers for devel in any conventional location,
> > > > > >
> > > > > > Since Xerces-C 1.5.1, the headers have gone into <prefix>/include.
> > > > > > What's wrong with that?
> > > > >
> > > > > Well, in general, "include" is a _really bad_ (did I mention "really
> > > > > really" bad also?)
> > > >
> > > > Sorry, I mean that since 1.5.1 the headers have gone into
> > > > <prefix>/include/xercesc. There is no problem with where the headers are
> > > > installed.
> > >
> > > This is good. I'm using 1.5.1 though, and headers are not being
> > > installed at all during make install.
> >
> > First you say that they are installed to 'random' locations, then you
> > say that they are not installed at all. I'm sure that it's working for
> > me. I personally changed the headers install path from <prefix>/include
> > to <prefix>/include/xercesc so I know that there stuff in there to
> > install the headers.
>
> "random" is not meant in the mathematical sense. What it means is that
> wherever xerces is unpacked, there will be an include subdirectory to
> that, and this is the final resting place. It's up to the whims of where
> it is unpacked. This isn't a result of install. Install does not install
> any headers, all headers remain within the tarball unpack. I've run the
> install from two different unpackings in two different locations, it has
> always added the lib file, but never headers outside of the unpack tree.
>
> >
> > It's not that complex, so I suggest that you try to find out what's
> > wrong.
>
> This is why I'm trying to see what is going wrong with headers not
> installing. Again, unpacking the source appears to be the only location
> the headers exist. make install does not provide headers outside of the
> source tree. Before you do any testing, make sure you unset all
> environment variables that have anything to do with Xerces, and see how
> it does things completely fresh. Move your existing install headers and
> libs elsewhere temporarily. One note here is that since the lib file
> does in fact go to /usr/local/lib/, I have to conclude that "prefix" is
> set to /usr/local, and thus if things are as you say, then headers must
> exist in /usr/local/include/xercesc/ after install. The headers remain
> missing. For reference, I'm doing this on Redhat 7.1 linux. I see that
> documentation only shows it checked to Redhat 6.1, which is
> extraordinarily out of date; perhaps changes in the environment mean it
> no longer behaves as it did a couple years back under 6.1.
What environment variables have anything to do with Xercec-C++ apart
from XERCESCROOT? And that NEEDS to be set.
Will you please just investigate the problem, instead of wasting all
your time with these verbose emails? I have obviously already tested it
to my satisfaction (on various versions of Redhat (including 7.1) and
Solaris)
>
> D. Stimits, stimits@idcomm.com
>
> >
> > It sounds like there should be a
> > > /usr/local/include/xercesc/ after root does the install process, but it
> > > is missing. Is it possible that this broke some time back, but since the
> > > files were already in place for developers, nobody noticed it?
> > >
> > > >
> > > > forced include path. It can cause all kinds of
> > > > > namespace collisions, it should instead be representative of a specific
> > > > > vendor or package...a unique identifier. E.G.,
> > > > > <prefix>/include/xerces-c/ or <prefix>/include/apache-xml/,
> > > > > <prefix>/include/xerces-j/, so on.
> > > > >
> > > > > Next, I have not found any sane defaults for "prefix". If unspecified,
> > > > > usually /usr/local/ would be desirable.
> > > >
> > > > It does default to a prefix of /usr/local. Please give us specific
> > > > information if you have found a bug.
> > >
> > > Nothing is being installed to /usr/local/, aside from actual libraries
> > > in /usr/local/lib/. Nada. Since the other package I need most urgently
> > > came out when 1.4 was used, and it had to hack include paths with hand
> > > edited values, I assume the lack of headers existed then as well, but I
> > > can't confirm it. If I have done something incorrect that would cause
> > > install of libs but not headers, then there is a flaw in configuration
> > > instructions.
> > >
> > > >
> > > > An install without specifying
> > > > > alternate prefix would result in /usr/local/include/xerces-c/ (as one
> > > > > possible example). Non-programmers, maybe basic administrators, can be
> > > > > expected to install this software as a step in installation of other
> > > > > packages...using /usr/local/ as a default prefix, and having any
> > > > > installed headers that might collide with other projects separated by a
> > > > > good subdirectory name can save much grief, while simultaneously
> > > > > allowing non-programmers to survive the install with all their hair
> > > > > (assuming they started with hair). Simple things like this can cause
> > > > > packages to be abandoned by the non-savvy.
> > > > >
> > > > > On the UNIX-flavor systems, which looks like this covers everything
> > > > > runConfigure is used for, failure to specify C and C++ compilers should
> > > > > end up with default values of gcc and g++,
> > > >
> > > > I'm pretty sure that recent version do default to g++. I am increasingly
> > > > convinced that you're using an old version of Xerces-C++.
> > >
> > > This may be so, but runConfigure spits this out as an error. Perhaps it
> > > uses g++ if nothing was specified, but the script fails to properly
> > > detect this. If you have an environment variable set, this would mask
> > > the problem.
> > >
> > > D. Stimits, stimits@idcomm.com
> > >
> > > >
> > > > rather than simply
> > > > > dying...these compilers are just too common (and quite good) on a huge
> > > > > assortment of UNIX flavor systems. I imagine that Apache and Xerces are
> > > > > most tested under gcc and g++ as well...should those not be valid
> > > > > compilers, it will be obvious; alternately, it is possible (without
> > > > > special tools) to test for the existence of programs such as "cc",
> > > > > "gcc", "c++", or "g++", in a case where the person installing fails to
> > > > > specify values. Currently, without specification, I see this (1.5.1):
> > > > > I do not recognize the C++ compiler ''. Continuing anyway ...
> > > > > ./runConfigure: [: too many arguments
> > > > >
> > > > > These are all simple things would could go a long way towards allowing
> > > > > development of packages that work with Xerces-c, and allow average
> > > > > people to compile all packages without excessive efforts. Right now I'm
> > > > > finding that one package I'm trying to work with has gone through a few
> > > > > hacks in anticipation of normal users failing to figure out Xerces-c;
> > > > > even with those hacks, one has to manually edit the other package's
> > > > > Makefile to figure out how to get the two to cooperate. From a coding
> > > > > perspective, there are "little things" that could make a major
> > > > > difference in product success (where the product must be compiled, and
> > > > > is not distributed in binary format).
> > > > >
> > > > > D. Stimits, stimits@idcomm.com
> > > > >
> > > > > >
> > > > > > and anything depending
> > > > > > > on Xerces ends up hard coding include paths to a tarball unpack of
> > > > > > > Xerces. For example, and this could be relocateable, make install should
> > > > > > > also install headers at /usr/include/xerces/ or
> > > > > > > /usr/local/include/xerces/ on Linux (and variations for most UNIX
> > > > > > > flavors). Is it possible to communicate with official developers
> > > > > > > concerning configuration and packaging issues? Is there a more active
> > > > > > > mailing list for such things?
> > > > > > >
> > > > > > > D. Stimits, stimits@idcomm.com
> > > > > > >
> > > > > > > ---------------------------------------------------------------------
> > > > > > > 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
> > > > > > murrayc@usa.net
> > > > > > www.murrayc.com
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > 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
> > > > murrayc@usa.net
> > > > www.murrayc.com
> > >
> > > ---------------------------------------------------------------------
> > > 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
> > murrayc@usa.net
> > www.murrayc.com
>
> ---------------------------------------------------------------------
> 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
murrayc@usa.net
www.murrayc.com
Re: Interested in getting changes into main Xerces distribution
Posted by "D. Stimits" <st...@idcomm.com>.
Murray Cumming wrote:
>
> On Thu, 2001-10-11 at 01:01, D. Stimits wrote:
> > Murray Cumming wrote:
> > >
> > > On Thu, 2001-10-11 at 00:02, D. Stimits wrote:
> > > > Murray Cumming wrote:
> > > > >
> > > > > On Wed, 2001-10-10 at 19:02, D. Stimits wrote:
> > > > > > Where would I post, or ask for changes to the official Xerces
> > > > > > distribution?
> > > > >
> > > > > Erm, this list, of course.
> > > > >
> > > > > Right now, the immediate change (and I can provide
> > > > > > Makefile patches if desired) would be that make install fails to place
> > > > > > headers for devel in any conventional location,
> > > > >
> > > > > Since Xerces-C 1.5.1, the headers have gone into <prefix>/include.
> > > > > What's wrong with that?
> > > >
> > > > Well, in general, "include" is a _really bad_ (did I mention "really
> > > > really" bad also?)
> > >
> > > Sorry, I mean that since 1.5.1 the headers have gone into
> > > <prefix>/include/xercesc. There is no problem with where the headers are
> > > installed.
> >
> > This is good. I'm using 1.5.1 though, and headers are not being
> > installed at all during make install.
>
> First you say that they are installed to 'random' locations, then you
> say that they are not installed at all. I'm sure that it's working for
> me. I personally changed the headers install path from <prefix>/include
> to <prefix>/include/xercesc so I know that there stuff in there to
> install the headers.
"random" is not meant in the mathematical sense. What it means is that
wherever xerces is unpacked, there will be an include subdirectory to
that, and this is the final resting place. It's up to the whims of where
it is unpacked. This isn't a result of install. Install does not install
any headers, all headers remain within the tarball unpack. I've run the
install from two different unpackings in two different locations, it has
always added the lib file, but never headers outside of the unpack tree.
>
> It's not that complex, so I suggest that you try to find out what's
> wrong.
This is why I'm trying to see what is going wrong with headers not
installing. Again, unpacking the source appears to be the only location
the headers exist. make install does not provide headers outside of the
source tree. Before you do any testing, make sure you unset all
environment variables that have anything to do with Xerces, and see how
it does things completely fresh. Move your existing install headers and
libs elsewhere temporarily. One note here is that since the lib file
does in fact go to /usr/local/lib/, I have to conclude that "prefix" is
set to /usr/local, and thus if things are as you say, then headers must
exist in /usr/local/include/xercesc/ after install. The headers remain
missing. For reference, I'm doing this on Redhat 7.1 linux. I see that
documentation only shows it checked to Redhat 6.1, which is
extraordinarily out of date; perhaps changes in the environment mean it
no longer behaves as it did a couple years back under 6.1.
D. Stimits, stimits@idcomm.com
>
> It sounds like there should be a
> > /usr/local/include/xercesc/ after root does the install process, but it
> > is missing. Is it possible that this broke some time back, but since the
> > files were already in place for developers, nobody noticed it?
> >
> > >
> > > forced include path. It can cause all kinds of
> > > > namespace collisions, it should instead be representative of a specific
> > > > vendor or package...a unique identifier. E.G.,
> > > > <prefix>/include/xerces-c/ or <prefix>/include/apache-xml/,
> > > > <prefix>/include/xerces-j/, so on.
> > > >
> > > > Next, I have not found any sane defaults for "prefix". If unspecified,
> > > > usually /usr/local/ would be desirable.
> > >
> > > It does default to a prefix of /usr/local. Please give us specific
> > > information if you have found a bug.
> >
> > Nothing is being installed to /usr/local/, aside from actual libraries
> > in /usr/local/lib/. Nada. Since the other package I need most urgently
> > came out when 1.4 was used, and it had to hack include paths with hand
> > edited values, I assume the lack of headers existed then as well, but I
> > can't confirm it. If I have done something incorrect that would cause
> > install of libs but not headers, then there is a flaw in configuration
> > instructions.
> >
> > >
> > > An install without specifying
> > > > alternate prefix would result in /usr/local/include/xerces-c/ (as one
> > > > possible example). Non-programmers, maybe basic administrators, can be
> > > > expected to install this software as a step in installation of other
> > > > packages...using /usr/local/ as a default prefix, and having any
> > > > installed headers that might collide with other projects separated by a
> > > > good subdirectory name can save much grief, while simultaneously
> > > > allowing non-programmers to survive the install with all their hair
> > > > (assuming they started with hair). Simple things like this can cause
> > > > packages to be abandoned by the non-savvy.
> > > >
> > > > On the UNIX-flavor systems, which looks like this covers everything
> > > > runConfigure is used for, failure to specify C and C++ compilers should
> > > > end up with default values of gcc and g++,
> > >
> > > I'm pretty sure that recent version do default to g++. I am increasingly
> > > convinced that you're using an old version of Xerces-C++.
> >
> > This may be so, but runConfigure spits this out as an error. Perhaps it
> > uses g++ if nothing was specified, but the script fails to properly
> > detect this. If you have an environment variable set, this would mask
> > the problem.
> >
> > D. Stimits, stimits@idcomm.com
> >
> > >
> > > rather than simply
> > > > dying...these compilers are just too common (and quite good) on a huge
> > > > assortment of UNIX flavor systems. I imagine that Apache and Xerces are
> > > > most tested under gcc and g++ as well...should those not be valid
> > > > compilers, it will be obvious; alternately, it is possible (without
> > > > special tools) to test for the existence of programs such as "cc",
> > > > "gcc", "c++", or "g++", in a case where the person installing fails to
> > > > specify values. Currently, without specification, I see this (1.5.1):
> > > > I do not recognize the C++ compiler ''. Continuing anyway ...
> > > > ./runConfigure: [: too many arguments
> > > >
> > > > These are all simple things would could go a long way towards allowing
> > > > development of packages that work with Xerces-c, and allow average
> > > > people to compile all packages without excessive efforts. Right now I'm
> > > > finding that one package I'm trying to work with has gone through a few
> > > > hacks in anticipation of normal users failing to figure out Xerces-c;
> > > > even with those hacks, one has to manually edit the other package's
> > > > Makefile to figure out how to get the two to cooperate. From a coding
> > > > perspective, there are "little things" that could make a major
> > > > difference in product success (where the product must be compiled, and
> > > > is not distributed in binary format).
> > > >
> > > > D. Stimits, stimits@idcomm.com
> > > >
> > > > >
> > > > > and anything depending
> > > > > > on Xerces ends up hard coding include paths to a tarball unpack of
> > > > > > Xerces. For example, and this could be relocateable, make install should
> > > > > > also install headers at /usr/include/xerces/ or
> > > > > > /usr/local/include/xerces/ on Linux (and variations for most UNIX
> > > > > > flavors). Is it possible to communicate with official developers
> > > > > > concerning configuration and packaging issues? Is there a more active
> > > > > > mailing list for such things?
> > > > > >
> > > > > > D. Stimits, stimits@idcomm.com
> > > > > >
> > > > > > ---------------------------------------------------------------------
> > > > > > 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
> > > > > murrayc@usa.net
> > > > > www.murrayc.com
> > > >
> > > > ---------------------------------------------------------------------
> > > > 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
> > > murrayc@usa.net
> > > www.murrayc.com
> >
> > ---------------------------------------------------------------------
> > 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
> murrayc@usa.net
> www.murrayc.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Interested in getting changes into main Xerces distribution
Posted by Murray Cumming <mu...@t-online.de>.
On Thu, 2001-10-11 at 01:01, D. Stimits wrote:
> Murray Cumming wrote:
> >
> > On Thu, 2001-10-11 at 00:02, D. Stimits wrote:
> > > Murray Cumming wrote:
> > > >
> > > > On Wed, 2001-10-10 at 19:02, D. Stimits wrote:
> > > > > Where would I post, or ask for changes to the official Xerces
> > > > > distribution?
> > > >
> > > > Erm, this list, of course.
> > > >
> > > > Right now, the immediate change (and I can provide
> > > > > Makefile patches if desired) would be that make install fails to place
> > > > > headers for devel in any conventional location,
> > > >
> > > > Since Xerces-C 1.5.1, the headers have gone into <prefix>/include.
> > > > What's wrong with that?
> > >
> > > Well, in general, "include" is a _really bad_ (did I mention "really
> > > really" bad also?)
> >
> > Sorry, I mean that since 1.5.1 the headers have gone into
> > <prefix>/include/xercesc. There is no problem with where the headers are
> > installed.
>
> This is good. I'm using 1.5.1 though, and headers are not being
> installed at all during make install.
First you say that they are installed to 'random' locations, then you
say that they are not installed at all. I'm sure that it's working for
me. I personally changed the headers install path from <prefix>/include
to <prefix>/include/xercesc so I know that there stuff in there to
install the headers.
It's not that complex, so I suggest that you try to find out what's
wrong.
It sounds like there should be a
> /usr/local/include/xercesc/ after root does the install process, but it
> is missing. Is it possible that this broke some time back, but since the
> files were already in place for developers, nobody noticed it?
>
> >
> > forced include path. It can cause all kinds of
> > > namespace collisions, it should instead be representative of a specific
> > > vendor or package...a unique identifier. E.G.,
> > > <prefix>/include/xerces-c/ or <prefix>/include/apache-xml/,
> > > <prefix>/include/xerces-j/, so on.
> > >
> > > Next, I have not found any sane defaults for "prefix". If unspecified,
> > > usually /usr/local/ would be desirable.
> >
> > It does default to a prefix of /usr/local. Please give us specific
> > information if you have found a bug.
>
> Nothing is being installed to /usr/local/, aside from actual libraries
> in /usr/local/lib/. Nada. Since the other package I need most urgently
> came out when 1.4 was used, and it had to hack include paths with hand
> edited values, I assume the lack of headers existed then as well, but I
> can't confirm it. If I have done something incorrect that would cause
> install of libs but not headers, then there is a flaw in configuration
> instructions.
>
> >
> > An install without specifying
> > > alternate prefix would result in /usr/local/include/xerces-c/ (as one
> > > possible example). Non-programmers, maybe basic administrators, can be
> > > expected to install this software as a step in installation of other
> > > packages...using /usr/local/ as a default prefix, and having any
> > > installed headers that might collide with other projects separated by a
> > > good subdirectory name can save much grief, while simultaneously
> > > allowing non-programmers to survive the install with all their hair
> > > (assuming they started with hair). Simple things like this can cause
> > > packages to be abandoned by the non-savvy.
> > >
> > > On the UNIX-flavor systems, which looks like this covers everything
> > > runConfigure is used for, failure to specify C and C++ compilers should
> > > end up with default values of gcc and g++,
> >
> > I'm pretty sure that recent version do default to g++. I am increasingly
> > convinced that you're using an old version of Xerces-C++.
>
> This may be so, but runConfigure spits this out as an error. Perhaps it
> uses g++ if nothing was specified, but the script fails to properly
> detect this. If you have an environment variable set, this would mask
> the problem.
>
> D. Stimits, stimits@idcomm.com
>
> >
> > rather than simply
> > > dying...these compilers are just too common (and quite good) on a huge
> > > assortment of UNIX flavor systems. I imagine that Apache and Xerces are
> > > most tested under gcc and g++ as well...should those not be valid
> > > compilers, it will be obvious; alternately, it is possible (without
> > > special tools) to test for the existence of programs such as "cc",
> > > "gcc", "c++", or "g++", in a case where the person installing fails to
> > > specify values. Currently, without specification, I see this (1.5.1):
> > > I do not recognize the C++ compiler ''. Continuing anyway ...
> > > ./runConfigure: [: too many arguments
> > >
> > > These are all simple things would could go a long way towards allowing
> > > development of packages that work with Xerces-c, and allow average
> > > people to compile all packages without excessive efforts. Right now I'm
> > > finding that one package I'm trying to work with has gone through a few
> > > hacks in anticipation of normal users failing to figure out Xerces-c;
> > > even with those hacks, one has to manually edit the other package's
> > > Makefile to figure out how to get the two to cooperate. From a coding
> > > perspective, there are "little things" that could make a major
> > > difference in product success (where the product must be compiled, and
> > > is not distributed in binary format).
> > >
> > > D. Stimits, stimits@idcomm.com
> > >
> > > >
> > > > and anything depending
> > > > > on Xerces ends up hard coding include paths to a tarball unpack of
> > > > > Xerces. For example, and this could be relocateable, make install should
> > > > > also install headers at /usr/include/xerces/ or
> > > > > /usr/local/include/xerces/ on Linux (and variations for most UNIX
> > > > > flavors). Is it possible to communicate with official developers
> > > > > concerning configuration and packaging issues? Is there a more active
> > > > > mailing list for such things?
> > > > >
> > > > > D. Stimits, stimits@idcomm.com
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > 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
> > > > murrayc@usa.net
> > > > www.murrayc.com
> > >
> > > ---------------------------------------------------------------------
> > > 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
> > murrayc@usa.net
> > www.murrayc.com
>
> ---------------------------------------------------------------------
> 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
murrayc@usa.net
www.murrayc.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Interested in getting changes into main Xerces distribution
Posted by "D. Stimits" <st...@idcomm.com>.
Murray Cumming wrote:
>
> On Thu, 2001-10-11 at 00:02, D. Stimits wrote:
> > Murray Cumming wrote:
> > >
> > > On Wed, 2001-10-10 at 19:02, D. Stimits wrote:
> > > > Where would I post, or ask for changes to the official Xerces
> > > > distribution?
> > >
> > > Erm, this list, of course.
> > >
> > > Right now, the immediate change (and I can provide
> > > > Makefile patches if desired) would be that make install fails to place
> > > > headers for devel in any conventional location,
> > >
> > > Since Xerces-C 1.5.1, the headers have gone into <prefix>/include.
> > > What's wrong with that?
> >
> > Well, in general, "include" is a _really bad_ (did I mention "really
> > really" bad also?)
>
> Sorry, I mean that since 1.5.1 the headers have gone into
> <prefix>/include/xercesc. There is no problem with where the headers are
> installed.
This is good. I'm using 1.5.1 though, and headers are not being
installed at all during make install. It sounds like there should be a
/usr/local/include/xercesc/ after root does the install process, but it
is missing. Is it possible that this broke some time back, but since the
files were already in place for developers, nobody noticed it?
>
> forced include path. It can cause all kinds of
> > namespace collisions, it should instead be representative of a specific
> > vendor or package...a unique identifier. E.G.,
> > <prefix>/include/xerces-c/ or <prefix>/include/apache-xml/,
> > <prefix>/include/xerces-j/, so on.
> >
> > Next, I have not found any sane defaults for "prefix". If unspecified,
> > usually /usr/local/ would be desirable.
>
> It does default to a prefix of /usr/local. Please give us specific
> information if you have found a bug.
Nothing is being installed to /usr/local/, aside from actual libraries
in /usr/local/lib/. Nada. Since the other package I need most urgently
came out when 1.4 was used, and it had to hack include paths with hand
edited values, I assume the lack of headers existed then as well, but I
can't confirm it. If I have done something incorrect that would cause
install of libs but not headers, then there is a flaw in configuration
instructions.
>
> An install without specifying
> > alternate prefix would result in /usr/local/include/xerces-c/ (as one
> > possible example). Non-programmers, maybe basic administrators, can be
> > expected to install this software as a step in installation of other
> > packages...using /usr/local/ as a default prefix, and having any
> > installed headers that might collide with other projects separated by a
> > good subdirectory name can save much grief, while simultaneously
> > allowing non-programmers to survive the install with all their hair
> > (assuming they started with hair). Simple things like this can cause
> > packages to be abandoned by the non-savvy.
> >
> > On the UNIX-flavor systems, which looks like this covers everything
> > runConfigure is used for, failure to specify C and C++ compilers should
> > end up with default values of gcc and g++,
>
> I'm pretty sure that recent version do default to g++. I am increasingly
> convinced that you're using an old version of Xerces-C++.
This may be so, but runConfigure spits this out as an error. Perhaps it
uses g++ if nothing was specified, but the script fails to properly
detect this. If you have an environment variable set, this would mask
the problem.
D. Stimits, stimits@idcomm.com
>
> rather than simply
> > dying...these compilers are just too common (and quite good) on a huge
> > assortment of UNIX flavor systems. I imagine that Apache and Xerces are
> > most tested under gcc and g++ as well...should those not be valid
> > compilers, it will be obvious; alternately, it is possible (without
> > special tools) to test for the existence of programs such as "cc",
> > "gcc", "c++", or "g++", in a case where the person installing fails to
> > specify values. Currently, without specification, I see this (1.5.1):
> > I do not recognize the C++ compiler ''. Continuing anyway ...
> > ./runConfigure: [: too many arguments
> >
> > These are all simple things would could go a long way towards allowing
> > development of packages that work with Xerces-c, and allow average
> > people to compile all packages without excessive efforts. Right now I'm
> > finding that one package I'm trying to work with has gone through a few
> > hacks in anticipation of normal users failing to figure out Xerces-c;
> > even with those hacks, one has to manually edit the other package's
> > Makefile to figure out how to get the two to cooperate. From a coding
> > perspective, there are "little things" that could make a major
> > difference in product success (where the product must be compiled, and
> > is not distributed in binary format).
> >
> > D. Stimits, stimits@idcomm.com
> >
> > >
> > > and anything depending
> > > > on Xerces ends up hard coding include paths to a tarball unpack of
> > > > Xerces. For example, and this could be relocateable, make install should
> > > > also install headers at /usr/include/xerces/ or
> > > > /usr/local/include/xerces/ on Linux (and variations for most UNIX
> > > > flavors). Is it possible to communicate with official developers
> > > > concerning configuration and packaging issues? Is there a more active
> > > > mailing list for such things?
> > > >
> > > > D. Stimits, stimits@idcomm.com
> > > >
> > > > ---------------------------------------------------------------------
> > > > 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
> > > murrayc@usa.net
> > > www.murrayc.com
> >
> > ---------------------------------------------------------------------
> > 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
> murrayc@usa.net
> www.murrayc.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Interested in getting changes into main Xerces distribution
Posted by Murray Cumming <mu...@t-online.de>.
On Thu, 2001-10-11 at 00:02, D. Stimits wrote:
> Murray Cumming wrote:
> >
> > On Wed, 2001-10-10 at 19:02, D. Stimits wrote:
> > > Where would I post, or ask for changes to the official Xerces
> > > distribution?
> >
> > Erm, this list, of course.
> >
> > Right now, the immediate change (and I can provide
> > > Makefile patches if desired) would be that make install fails to place
> > > headers for devel in any conventional location,
> >
> > Since Xerces-C 1.5.1, the headers have gone into <prefix>/include.
> > What's wrong with that?
>
> Well, in general, "include" is a _really bad_ (did I mention "really
> really" bad also?)
Sorry, I mean that since 1.5.1 the headers have gone into
<prefix>/include/xercesc. There is no problem with where the headers are
installed.
forced include path. It can cause all kinds of
> namespace collisions, it should instead be representative of a specific
> vendor or package...a unique identifier. E.G.,
> <prefix>/include/xerces-c/ or <prefix>/include/apache-xml/,
> <prefix>/include/xerces-j/, so on.
>
> Next, I have not found any sane defaults for "prefix". If unspecified,
> usually /usr/local/ would be desirable.
It does default to a prefix of /usr/local. Please give us specific
information if you have found a bug.
An install without specifying
> alternate prefix would result in /usr/local/include/xerces-c/ (as one
> possible example). Non-programmers, maybe basic administrators, can be
> expected to install this software as a step in installation of other
> packages...using /usr/local/ as a default prefix, and having any
> installed headers that might collide with other projects separated by a
> good subdirectory name can save much grief, while simultaneously
> allowing non-programmers to survive the install with all their hair
> (assuming they started with hair). Simple things like this can cause
> packages to be abandoned by the non-savvy.
>
> On the UNIX-flavor systems, which looks like this covers everything
> runConfigure is used for, failure to specify C and C++ compilers should
> end up with default values of gcc and g++,
I'm pretty sure that recent version do default to g++. I am increasingly
convinced that you're using an old version of Xerces-C++.
rather than simply
> dying...these compilers are just too common (and quite good) on a huge
> assortment of UNIX flavor systems. I imagine that Apache and Xerces are
> most tested under gcc and g++ as well...should those not be valid
> compilers, it will be obvious; alternately, it is possible (without
> special tools) to test for the existence of programs such as "cc",
> "gcc", "c++", or "g++", in a case where the person installing fails to
> specify values. Currently, without specification, I see this (1.5.1):
> I do not recognize the C++ compiler ''. Continuing anyway ...
> ./runConfigure: [: too many arguments
>
> These are all simple things would could go a long way towards allowing
> development of packages that work with Xerces-c, and allow average
> people to compile all packages without excessive efforts. Right now I'm
> finding that one package I'm trying to work with has gone through a few
> hacks in anticipation of normal users failing to figure out Xerces-c;
> even with those hacks, one has to manually edit the other package's
> Makefile to figure out how to get the two to cooperate. From a coding
> perspective, there are "little things" that could make a major
> difference in product success (where the product must be compiled, and
> is not distributed in binary format).
>
> D. Stimits, stimits@idcomm.com
>
> >
> > and anything depending
> > > on Xerces ends up hard coding include paths to a tarball unpack of
> > > Xerces. For example, and this could be relocateable, make install should
> > > also install headers at /usr/include/xerces/ or
> > > /usr/local/include/xerces/ on Linux (and variations for most UNIX
> > > flavors). Is it possible to communicate with official developers
> > > concerning configuration and packaging issues? Is there a more active
> > > mailing list for such things?
> > >
> > > D. Stimits, stimits@idcomm.com
> > >
> > > ---------------------------------------------------------------------
> > > 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
> > murrayc@usa.net
> > www.murrayc.com
>
> ---------------------------------------------------------------------
> 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
murrayc@usa.net
www.murrayc.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Interested in getting changes into main Xerces distribution
Posted by "D. Stimits" <st...@idcomm.com>.
Murray Cumming wrote:
>
> On Wed, 2001-10-10 at 19:02, D. Stimits wrote:
> > Where would I post, or ask for changes to the official Xerces
> > distribution?
>
> Erm, this list, of course.
>
> Right now, the immediate change (and I can provide
> > Makefile patches if desired) would be that make install fails to place
> > headers for devel in any conventional location,
>
> Since Xerces-C 1.5.1, the headers have gone into <prefix>/include.
> What's wrong with that?
Well, in general, "include" is a _really bad_ (did I mention "really
really" bad also?) forced include path. It can cause all kinds of
namespace collisions, it should instead be representative of a specific
vendor or package...a unique identifier. E.G.,
<prefix>/include/xerces-c/ or <prefix>/include/apache-xml/,
<prefix>/include/xerces-j/, so on.
Next, I have not found any sane defaults for "prefix". If unspecified,
usually /usr/local/ would be desirable. An install without specifying
alternate prefix would result in /usr/local/include/xerces-c/ (as one
possible example). Non-programmers, maybe basic administrators, can be
expected to install this software as a step in installation of other
packages...using /usr/local/ as a default prefix, and having any
installed headers that might collide with other projects separated by a
good subdirectory name can save much grief, while simultaneously
allowing non-programmers to survive the install with all their hair
(assuming they started with hair). Simple things like this can cause
packages to be abandoned by the non-savvy.
On the UNIX-flavor systems, which looks like this covers everything
runConfigure is used for, failure to specify C and C++ compilers should
end up with default values of gcc and g++, rather than simply
dying...these compilers are just too common (and quite good) on a huge
assortment of UNIX flavor systems. I imagine that Apache and Xerces are
most tested under gcc and g++ as well...should those not be valid
compilers, it will be obvious; alternately, it is possible (without
special tools) to test for the existence of programs such as "cc",
"gcc", "c++", or "g++", in a case where the person installing fails to
specify values. Currently, without specification, I see this (1.5.1):
I do not recognize the C++ compiler ''. Continuing anyway ...
./runConfigure: [: too many arguments
These are all simple things would could go a long way towards allowing
development of packages that work with Xerces-c, and allow average
people to compile all packages without excessive efforts. Right now I'm
finding that one package I'm trying to work with has gone through a few
hacks in anticipation of normal users failing to figure out Xerces-c;
even with those hacks, one has to manually edit the other package's
Makefile to figure out how to get the two to cooperate. From a coding
perspective, there are "little things" that could make a major
difference in product success (where the product must be compiled, and
is not distributed in binary format).
D. Stimits, stimits@idcomm.com
>
> and anything depending
> > on Xerces ends up hard coding include paths to a tarball unpack of
> > Xerces. For example, and this could be relocateable, make install should
> > also install headers at /usr/include/xerces/ or
> > /usr/local/include/xerces/ on Linux (and variations for most UNIX
> > flavors). Is it possible to communicate with official developers
> > concerning configuration and packaging issues? Is there a more active
> > mailing list for such things?
> >
> > D. Stimits, stimits@idcomm.com
> >
> > ---------------------------------------------------------------------
> > 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
> murrayc@usa.net
> www.murrayc.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Interested in getting changes into main Xerces distribution
Posted by Murray Cumming <mu...@t-online.de>.
On Wed, 2001-10-10 at 19:02, D. Stimits wrote:
> Where would I post, or ask for changes to the official Xerces
> distribution?
Erm, this list, of course.
Right now, the immediate change (and I can provide
> Makefile patches if desired) would be that make install fails to place
> headers for devel in any conventional location,
Since Xerces-C 1.5.1, the headers have gone into <prefix>/include.
What's wrong with that?
and anything depending
> on Xerces ends up hard coding include paths to a tarball unpack of
> Xerces. For example, and this could be relocateable, make install should
> also install headers at /usr/include/xerces/ or
> /usr/local/include/xerces/ on Linux (and variations for most UNIX
> flavors). Is it possible to communicate with official developers
> concerning configuration and packaging issues? Is there a more active
> mailing list for such things?
>
> D. Stimits, stimits@idcomm.com
>
> ---------------------------------------------------------------------
> 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
murrayc@usa.net
www.murrayc.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Interested in getting changes into main Xerces distribution
Posted by "Scott A. Herod" <he...@interact-tv.com>.
I believe that Rob Savoye sent in standard GNU build files for 1.3 about
a year ago. Obviously they didn't become official. We could ask him
if he would be willing to make them available somewhere. Of course that
doesn't fix the way #include's are done.
Scott
Mark Weaver wrote:
>
> I would find this change extremely welcome. The current random header file
> location is annoying, to put it mildly, plus prone to potential collisions.
>
> This would seem to be the right place to post, but finding an active
> committer here willing to take on changes seems to be rather a challenge!
>
> Mark
>
> > -----Original Message-----
> > From: stimits@mailhost.idcomm.com [mailto:stimits@mailhost.idcomm.com]On
> > Behalf Of D. Stimits
> > Sent: 10 October 2001 18:02
> > To: Xerces-c-dev
> > Subject: Interested in getting changes into main Xerces distribution
> >
> >
> > Where would I post, or ask for changes to the official Xerces
> > distribution? Right now, the immediate change (and I can provide
> > Makefile patches if desired) would be that make install fails to place
> > headers for devel in any conventional location, and anything depending
> > on Xerces ends up hard coding include paths to a tarball unpack of
> > Xerces. For example, and this could be relocateable, make install should
> > also install headers at /usr/include/xerces/ or
> > /usr/local/include/xerces/ on Linux (and variations for most UNIX
> > flavors). Is it possible to communicate with official developers
> > concerning configuration and packaging issues? Is there a more active
> > mailing list for such things?
> >
> > D. Stimits, stimits@idcomm.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Interested in getting changes into main Xerces distribution
Posted by "D. Stimits" <st...@idcomm.com>.
Murray Cumming wrote:
>
> On Wed, 2001-10-10 at 22:44, D. Stimits wrote:
> > "Jason E. Stewart" wrote:
> > >
> > > "Mark Weaver" <ma...@npsl.co.uk> writes:
> > >
> > > > I would find this change extremely welcome. The current random header file
> > > > location is annoying, to put it mildly, plus prone to potential collisions.
> > > >
> > > > This would seem to be the right place to post, but finding an active
> > > > committer here willing to take on changes seems to be rather a challenge!
> > >
> > > You should first take a look at the work the Murray has done. This
> > > should address many of these issues.
> > >
> > > jas.
> > >
> > > ------------------------------------------------------------------------
> > > Part 1.2Type: message/rfc822
> >
> > Having include files installed as shown there is a major improvement,
> > e.g., to /usr/include/xercesc/. There are other issues I'm interested in
> > in addition to this, for simplification of config without setting
> > environment variables. But in either case, is it possible to get
> > something merged into the official distribution? Xerces is a major
> > barrier when it comes to projects that are to be distributed in source
> > form and then compiled by average Linux users (versus developers). Being
> > able to install Xerces headers would remove the XERCESCROOT setting
> > quite nicely, but there are other specifications that simplification
> > would also aid.
> >
> > I hear a lot of people shout about the use of automake/autoconf/libtool
> > for cross platform configuration, but when doing C++, autoconf and
> > friends are basically broken; mix C and C++, those tools are a disaster.
>
> You'll have to give more information to convince us of that point of
> view. The autotools are widely used, successfully.
I was on the autoconf/automake devel lists for a while, pointed out some
problems, they were being "addressed", but only partial solutions were
complete. I then got tired of all the email spam mining and had to leave
the list. The bugs were found while trying to convert a mixed C/C++
project. Some software configurations might not run into the bugs found,
but they were fatal to my projects, and until autoconf/automake improves
drastically with C++, I won't use it there.
On the other hand, if autoconf/automake were used on xerces-c
successfully, I wouldn't argue. I'd like it. But I'm skeptical that
complete conversion to autoconf/automake would be possible within the
near future, it would be a long project, with a lot of time for
debugging required. Despite the presence of some autoconf/automake files
within Xerces already, it is incomplete. runConfigure is required,
environment variables are required, much end user intervention is
required. Relative to the scale of Xerces, I'm not saying that a lot has
not been accomplished with configuration of a complex system, but it is
not sufficient for success with average people.
>
> > So I am not suggesting conversion to some big configuration tool, but
> > even the basic Makefiles involved tend to be a barrier when writing
> > packages that will depend upon Xerces.
>
> I have found it to be relatively simple to build packages that depend on
> Xerces-C. For instance,
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/bakery/bakery_example_xml/configure.in?rev=HEAD&content-type=text/vnd.viewcvs-markup
>
> The main problem is that it's not yet easy to package it, largely
> because the API is not stable.
I'm not sure how that applies to items like default values for prefix
and other installation values. In the case of having to set XERCESCROOT,
I would think the software should be able to figure out where its own
location is without manual intervention. Assuming this is somehow
connected to the prefix value of install paths, it isn't appropriate
naming or default behavior.
I really am not trying to be a pain in the butt, though I probably am.
But after feedback from users of a prior project, which is being
replaced with a "next generation" product, I know without hesitation
that this will become a serious issue to acceptance. We've already
decided to require Xerces, what we can't decide on is whether
non-technical types will be able to configure it without all kinds of
special steps on the development side which will end up making things
less modular.
D. Stimits, stimits@idcomm.com
>
> > Some simple things could be done,
> > such as offering sane default values for some unset variables. Xerces is
> > an amazing piece of work, I'm surprised that configuration and
> > installation is so far behind the actual code.
> > If users get frustrated
> > by it, and can't or won't use it, then it does no good for anyone.
> >
> > D. Stimits, stimits@idcomm.com
> >
> > ---------------------------------------------------------------------
> > 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
> murrayc@usa.net
> www.murrayc.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Interested in getting changes into main Xerces distribution
Posted by Murray Cumming <mu...@t-online.de>.
On Wed, 2001-10-10 at 22:44, D. Stimits wrote:
> "Jason E. Stewart" wrote:
> >
> > "Mark Weaver" <ma...@npsl.co.uk> writes:
> >
> > > I would find this change extremely welcome. The current random header file
> > > location is annoying, to put it mildly, plus prone to potential collisions.
> > >
> > > This would seem to be the right place to post, but finding an active
> > > committer here willing to take on changes seems to be rather a challenge!
> >
> > You should first take a look at the work the Murray has done. This
> > should address many of these issues.
> >
> > jas.
> >
> > ------------------------------------------------------------------------
> > Part 1.2Type: message/rfc822
>
> Having include files installed as shown there is a major improvement,
> e.g., to /usr/include/xercesc/. There are other issues I'm interested in
> in addition to this, for simplification of config without setting
> environment variables. But in either case, is it possible to get
> something merged into the official distribution? Xerces is a major
> barrier when it comes to projects that are to be distributed in source
> form and then compiled by average Linux users (versus developers). Being
> able to install Xerces headers would remove the XERCESCROOT setting
> quite nicely, but there are other specifications that simplification
> would also aid.
>
> I hear a lot of people shout about the use of automake/autoconf/libtool
> for cross platform configuration, but when doing C++, autoconf and
> friends are basically broken; mix C and C++, those tools are a disaster.
You'll have to give more information to convince us of that point of
view. The autotools are widely used, successfully.
> So I am not suggesting conversion to some big configuration tool, but
> even the basic Makefiles involved tend to be a barrier when writing
> packages that will depend upon Xerces.
I have found it to be relatively simple to build packages that depend on
Xerces-C. For instance,
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/bakery/bakery_example_xml/configure.in?rev=HEAD&content-type=text/vnd.viewcvs-markup
The main problem is that it's not yet easy to package it, largely
because the API is not stable.
> Some simple things could be done,
> such as offering sane default values for some unset variables. Xerces is
> an amazing piece of work, I'm surprised that configuration and
> installation is so far behind the actual code.
> If users get frustrated
> by it, and can't or won't use it, then it does no good for anyone.
>
> D. Stimits, stimits@idcomm.com
>
> ---------------------------------------------------------------------
> 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
murrayc@usa.net
www.murrayc.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Interested in getting changes into main Xerces distribution
Posted by Juergen Hermann <jh...@web.de>.
On Wed, 10 Oct 2001 14:44:53 -0600, D. Stimits wrote:
>I hear a lot of people shout about the use of automake/autoconf/libtool
>for cross platform configuration, but when doing C++, autoconf and
>friends are basically broken; mix C and C++, those tools are a disaster.
The problems of autotools lie elsewhere. And applying them to Xerces
wouldn't be too much of a problem.
Ciao, Jürgen
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Interested in getting changes into main Xerces distribution
Posted by "D. Stimits" <st...@idcomm.com>.
"Jason E. Stewart" wrote:
>
> "Mark Weaver" <ma...@npsl.co.uk> writes:
>
> > I would find this change extremely welcome. The current random header file
> > location is annoying, to put it mildly, plus prone to potential collisions.
> >
> > This would seem to be the right place to post, but finding an active
> > committer here willing to take on changes seems to be rather a challenge!
>
> You should first take a look at the work the Murray has done. This
> should address many of these issues.
>
> jas.
>
> ------------------------------------------------------------------------
> Part 1.2Type: message/rfc822
Having include files installed as shown there is a major improvement,
e.g., to /usr/include/xercesc/. There are other issues I'm interested in
in addition to this, for simplification of config without setting
environment variables. But in either case, is it possible to get
something merged into the official distribution? Xerces is a major
barrier when it comes to projects that are to be distributed in source
form and then compiled by average Linux users (versus developers). Being
able to install Xerces headers would remove the XERCESCROOT setting
quite nicely, but there are other specifications that simplification
would also aid.
I hear a lot of people shout about the use of automake/autoconf/libtool
for cross platform configuration, but when doing C++, autoconf and
friends are basically broken; mix C and C++, those tools are a disaster.
So I am not suggesting conversion to some big configuration tool, but
even the basic Makefiles involved tend to be a barrier when writing
packages that will depend upon Xerces. Some simple things could be done,
such as offering sane default values for some unset variables. Xerces is
an amazing piece of work, I'm surprised that configuration and
installation is so far behind the actual code. If users get frustrated
by it, and can't or won't use it, then it does no good for anyone.
D. Stimits, stimits@idcomm.com
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
Re: Interested in getting changes into main Xerces distribution
Posted by "Jason E. Stewart" <ja...@openinformatics.com>.
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: Interested in getting changes into main Xerces distribution
Posted by Mark Weaver <ma...@npsl.co.uk>.
I would find this change extremely welcome. The current random header file
location is annoying, to put it mildly, plus prone to potential collisions.
This would seem to be the right place to post, but finding an active
committer here willing to take on changes seems to be rather a challenge!
Mark
> -----Original Message-----
> From: stimits@mailhost.idcomm.com [mailto:stimits@mailhost.idcomm.com]On
> Behalf Of D. Stimits
> Sent: 10 October 2001 18:02
> To: Xerces-c-dev
> Subject: Interested in getting changes into main Xerces distribution
>
>
> Where would I post, or ask for changes to the official Xerces
> distribution? Right now, the immediate change (and I can provide
> Makefile patches if desired) would be that make install fails to place
> headers for devel in any conventional location, and anything depending
> on Xerces ends up hard coding include paths to a tarball unpack of
> Xerces. For example, and this could be relocateable, make install should
> also install headers at /usr/include/xerces/ or
> /usr/local/include/xerces/ on Linux (and variations for most UNIX
> flavors). Is it possible to communicate with official developers
> concerning configuration and packaging issues? Is there a more active
> mailing list for such things?
>
> D. Stimits, stimits@idcomm.com
>
> ---------------------------------------------------------------------
> 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