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 Justin Dearing <zi...@gmail.com> on 2007/10/17 02:11:59 UTC
Offer to update the build documentation at http://xerces.apache.org/xerces-c/build-winunix.html
Hello,
I recently built your library via MSYS. I did this to help Gerald Schmidt
remove the msxml dependency from his application XML Copy Editor
(http://xml-copy-editor.sourceforge.net/).Gerald
<http://xml-copy-editor.sourceforge.net/%29.Gerald> has attempted to compile
xerces via the Dev-C++ IDE and failed, no doubt to the complexity of your
build process that requires a wrapper around configure. I decided to try
building it with MSYS and expected that if I was successful I'd be
submitting a patch to this mailing list.
To my surprise it worked just fine. However, nowhere in your docs does it
say you can use the unix build directions to build with msys or cygwin.
There is a large section discussing cygwin so that is implied clearly.
However, the mentions on mingw-msys are lost in the fine print. I think the
following changes to your build documentation available at
http://xerces.apache.org/xerces-c/build-winunix.html would alleviate this.
1) Add a Build using mingw section. In this section, explain that msys is
required, and that msys is a windows port of rxvt, bash and some other tools
that allows you to run configure scripts on windows to build mingw targeted
applications on windows without cygwin. Also a link to download msys should
be provided. Provide an example invocation of ./runConfigure and direct them
to the unix directions as you do in the cygwin directions. Some developers
that use mingw on windows use it through Dev-C++ or other IDEs. They might
necceserally be familar with msys, even those that also develop in linux and
toy with cygwin.
2) Update the OS/Compiler table to include mingw, cygwin, borland and
whatever else you support. That table should also be updated on
(http://xerces.apache.org/xerces-c/
).
3) Their should be a building on windows header with sub headers for
buildign wis Visua Studio, Borland, Mingw-gcc and cygwin-gcc
If the powers that be would like me to make these changes and submit a
patch. Point me to the "souce code" for the html documentation and I will do
so. If one of you prefers to make the changes I describe I can provide
verbiage for the mingw section.
You have a fine xml library, but some small oversites in your build
documents might be hindering your user base.
Regards,
Re: Offer to update the build documentation at http://xerces.apache.org/xerces-c/build-winunix.html
Posted by Justin Dearing <zi...@gmail.com>.
On 10/18/07, Boris Kolpackov <bo...@codesynthesis.com> wrote:
> Some thought on what would be good to have covered:
>
> - Building using both cygwin (-mno-cygwin) and msys toolchains.
Hello Boris,
I'm having trouble getting the mingw version to build from cygwin. I
asked a question on the users list. Until I can figure out the proper
incovation of ./runConfigure to make that happen I can not document
that part.
Below is the patch of what I have so far. I have to venture into
building the static lib and document the other bug you mentioned.
Regards,
Justin Dearing
Index: build-winunix.xml
===================================================================
--- build-winunix.xml (revision 591873)
+++ build-winunix.xml (working copy)
@@ -24,6 +24,7 @@
<li><link anchor="WinNT">Building on Windows using Microsoft
Visual C++</link></li>
<li><link anchor="UNIX">Building on UNIX/Linux/Mac OS X
platforms</link></li>
<li><link anchor="CygWin">Building on Windows using Cygwin</link></li>
+ <li><link anchor="MinGW">Building on Windows using MinGW</link></li>
<li><link anchor="WinBorlandCC">Building on Windows using
Borland C++</link></li>
<li><link anchor="WinBorlandBuilder">Building on Windows using
Borland C++ Builder</link></li>
<li><link anchor="WinIntel">Building 64 bit libraries on
Windows using Intel C++</link></li>
@@ -155,7 +156,12 @@
<p>Next set your &XercesCName; root path as follows:</p>
<source>export XERCESCROOT=<full-path-to-&XercesCSrcInstallDir;></source>
- <p>This should be the full path of the directory where
you extracted &XercesCName;.</p>
+ <p>This should be the full path of the directory where
you extracted &XercesCName;.
+ Note that this path should not have any spaces in it or
the build process will fail. The
+ only unix envirorments where this is likely to occur in are
+ <link anchor="CygWin">MinGW</link> and <link
anchor="MinGW">Cygwin</link> as the home
+ directories are by default '/home/User Name' and on
windows user names can, and often
+ do, contain spaces.</p>
</s3>
<s3 title="Building &XercesCName; library">
@@ -492,6 +498,34 @@
is recommended that you use gcc 3.1 or higher.</p>
</s2>
+ <anchor name="MinGW"/>
+ <s2 title="Building on Windows using MinGW">
+ <p><em>Do not jump into the build directly before reading
this.</em></p>
+
+ <p>&XercesCName; may be built in the
+ <jump href="http://www.mingw.org/msys.shtml">MSYS-MinGW</jump>
environment for use
+ by Windows applications. As with the <jump href="#UNIX">UNIX</jump>
+ platforms, &XercesCName; on MinGW uses
+ <jump href="http://www.gnu.org">GNU</jump> tools. Therefore, with a
+ couple of notable exceptions, &XercesCName; on MinGW is built using
+ the same instructions as the UNIX platforms. The build environment
+ variable XERCESCROOT must be set to the proper path containing the
+ &XercesCName; sources and <em>runConfigure</em> must be run with the
+ "-pmingw-msys -cgcc -xg++" arguments.</p>
+
+ <p>Note that MinGW is different from the UNIX platforms in the way
+ that it finds libraries at run time. While UNIX platforms may use the
+ environment variable LD_LIBRARY_PATH, Cygwin uses the PATH environment
+ variable.</p>
+
+ <p>There is an issue with the
+ <jump href="http://www.gnu.org/software/gcc/gcc.html">gcc/g++</jump>
+ compiler version 2.95, where C++ exceptions thrown from a dll will
+ cause the application to crash, regardless of whether there is a "catch"
+ statement. This bug doesn't occur in tests using gcc 3.1 or 3.2, so it
+ is recommended that you use gcc 3.1 or higher.</p>
+ </s2>
+
<anchor name="WinBorlandBuilder"/>
<s2 title="Building on Windows using Borland C++ Builder">
<p>&XercesCName; source distribution comes with Borland C++
Builder 6 projects to help you
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Getting 3.0 out (was RE: Offer to update the build documentation)
Posted by Scott Cantor <ca...@osu.edu>.
> I'll chime in with support for Scott's view here. (And yes, I
> apologize that this is off-topic to the issue of build documentation).
Sorry, topic renamed.
> As one of those responsible for getting Xerces 3.0 to the point it is
> now, (and it's been at that point for several years now), I can say
> that it works well for me. But we need community leadership to get it
> out the door, and I don't have the time for that. There seems to be
> auto* issues on a few platforms for 3.0, but those aren't platforms I
> have access to nor know anything about: it really is up to committers
> who can support those platforms to get things working there, or to
> suggest changes that will allow them to work, or (if needed) to come
> up with an alternate non auto* build system for those systems.
Anything that's not Windows should stay with autoconf, anything else is
nuts. As far as fixing the scripts is concerned, the thing to keep in mind
is that it's not a stable target. Supporting a platform usually means
keeping up with it and patching the scripts as time goes on, so that each
roll up release eventually pulls in all the known patching that has gone on
to keep the scripts working.
I can tell you that for Fedora, for example, gcc is churning at an
astounding rate. It *will* break a lot, there just isn't a lot you can do
about it unless you drop support for Fedora (that's just an example, I don't
know if Fedora is a supported OS here).
So I would suggest that specific people are tasked (on the basis of them
volunteering) to deal with the ongoing maintenance of specific
platform/compiler combos, and if nobody steps up, you cut it. For those
dropped platforms, packagers will likely step up outside the mainline
project tree and patch things, and if they care to donate back, that's fine.
Otherwise it just doesn't happen.
> Boris, you offered earlier to take the lead in pushing 3.0 out the
> door. Are you still able to do that? (perhaps on a new thread...)
I'm still willing to help on platforms I have access to (and need), but the
last time a set of the open issues was posted, somebody indicated that it
was out of date, so I didn't take it very seriously as an accurate snapshot.
-- Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
RE: Getting 3.0 out (was RE: Offer to update the build documentation)
Posted by Scott Cantor <ca...@osu.edu>.
> On 11/5/07, Scott Cantor <ca...@osu.edu> wrote:
> > Anything that's not Windows should stay with autoconf, anything else is
> > nuts.
>
> I don't think supporting cygwin and mingw-msys is nuts.
I think you're misinterpreting me. Last I checked, cygwin supports
autotools. I don't know about mingw-msys. What I was trying to say was that
the ./runConfigure mess was an absolute nightmare for me as an upstream
consumer, and I would not want to see a repeat of that after so much work to
undo it.
The native Windows build has to be handled separately, and it has been, but
unless there's another platform in demand that doesn't support autotools, I
really, really believe that any additional platform work needs to be kept in
the autotools framework. That's what I was trying to say. If something else
is critical to support but doesn't support autotools, then we need a
maintainer for that, seems to me.
My point at the beginning of this thread was that we should not hold up the
3.0 release if there are minority platforms without project contribution
where the autotools build happens to be failing *at the moment*. If that's
controversial, so be it; I still feel that way.
> Perhaps you should get fedora to have its own rpm and send patched
> upstream?
Fedora probably works at this moment in time, but that's in fact my
position; if people don't step up to support specific platforms that are
breaking, leave it to upstream packagers to get it working and then
incorporate their feedback for a future release. All I'm saying is that
perfection is not achievable when it comes to Unix.
> > So I would suggest that specific people are tasked (on the basis of them
> > volunteering) to deal with the ongoing maintenance of specific
> > platform/compiler combos, and if nobody steps up, you cut it.
>
> I'll test mingw and cygwin. I can't guarantee I can fix all issues
> that pop up, but I can run ./configure and when it breaks try and fix
> it and report my findings and fixes.
That's the minimum that I was suggesting; if a platform is breaking and
somebody says "Hey, I'll give it a try", then you wait and see what they can
fix. But if something in the matrix is breaking and nobody has access to it
or is willing to test it, I don't see what we can do. Apparently that's
controversial, but to me it's common sense.
-- Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Getting 3.0 out (was RE: Offer to update the build documentation)
Posted by Justin Dearing <zi...@gmail.com>.
On 11/5/07, Scott Cantor <ca...@osu.edu> wrote:
> Anything that's not Windows should stay with autoconf, anything else is
> nuts.
I don't think supporting cygwin and mingw-msys is nuts. I say this of
course as an upstream developer whose main concern is simplifying the
build process for an xml editor that targets windows and linux so I am
biased. However, considering windows moves a lot slower than Fedora
core, I think its worth the effort.
> I can tell you that for Fedora, for example, gcc is churning at an
> astounding rate. It *will* break a lot, there just isn't a lot you can do
> about it unless you drop support for Fedora (that's just an example, I don't
> know if Fedora is a supported OS here).
Perhaps you should get fedora to have its own rpm and send patched upstream?
> So I would suggest that specific people are tasked (on the basis of them
> volunteering) to deal with the ongoing maintenance of specific
> platform/compiler combos, and if nobody steps up, you cut it.
I'll test mingw and cygwin. I can't guarantee I can fix all issues
that pop up, but I can run ./configure and when it breaks try and fix
it and report my findings and fixes.
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Offer to update the build documentation at http://xerces.apache.org/xerces-c/build-winunix.html
Posted by James Berry <jb...@apache.org>.
On Nov 5, 2007, at 8:25 AM, Scott Cantor wrote:
>> I would also like to suggest that we have all the infrastructure
>> issues worked out before we commit to migrating to Forrest. This
>> way we won't end up in a situation that Xerces-C++ 3.0.0 is right
>> now with autoconf where the person/people with the necessary
>> expertise is/are unable to commit time to finish the built system.
>
> What's left to do? I know some platforms don't work, but honestly
> either the
> project supports those platforms or it doesn't. If yes, somebody on
> the core
> team has to be responsible for testing and maintaining them, and if
> not, you
> don't support them and they shouldn't hold up a release.
>
> It's not reasonable to me to hold up development for a platform or
> compiler
> for which nobody is donating time, a box to test on, or both. Put up
> or shut
> up basically.
I'll chime in with support for Scott's view here. (And yes, I
apologize that this is off-topic to the issue of build documentation).
As one of those responsible for getting Xerces 3.0 to the point it is
now, (and it's been at that point for several years now), I can say
that it works well for me. But we need community leadership to get it
out the door, and I don't have the time for that. There seems to be
auto* issues on a few platforms for 3.0, but those aren't platforms I
have access to nor know anything about: it really is up to committers
who can support those platforms to get things working there, or to
suggest changes that will allow them to work, or (if needed) to come
up with an alternate non auto* build system for those systems.
Boris, you offered earlier to take the lead in pushing 3.0 out the
door. Are you still able to do that? (perhaps on a new thread...)
James
>
>
> -- Scott
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
> For additional commands, e-mail: c-dev-help@xerces.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
RE: Offer to update the build documentation at http://xerces.apache.org/xerces-c/build-winunix.html
Posted by Scott Cantor <ca...@osu.edu>.
> I would also like to suggest that we have all the infrastructure
> issues worked out before we commit to migrating to Forrest. This
> way we won't end up in a situation that Xerces-C++ 3.0.0 is right
> now with autoconf where the person/people with the necessary
> expertise is/are unable to commit time to finish the built system.
What's left to do? I know some platforms don't work, but honestly either the
project supports those platforms or it doesn't. If yes, somebody on the core
team has to be responsible for testing and maintaining them, and if not, you
don't support them and they shouldn't hold up a release.
It's not reasonable to me to hold up development for a platform or compiler
for which nobody is donating time, a box to test on, or both. Put up or shut
up basically.
-- Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Offer to update the build documentation at http://xerces.apache.org/xerces-c/build-winunix.html
Posted by Jason Stewart <ja...@gmail.com>.
Hey Boris,
On Nov 14, 2007 11:13 AM, Boris Kolpackov <bo...@codesynthesis.com> wrote:
> Hi Jason,
>
> Sorry for the delay. Please see my comments below.
> Hm, I am now wondering why are we migrating to Forrset then? I thought
> the idea was to replace the document system with something better and
> more structured, and possibly redesign the appearance of the site to
> look more modern?
the only point was that stylebook is an unsupported, never-released
internal project of apache. Forrest is a released, supported system.
stylebook has bugs, and they will never be fixed.
> > OK. So you want the new forrest site to be 3.0 specific?
>
> I am not sure what you mean by "3.0 specific" but I don't think
> that's what I meant ;-). My point is we shouldn't make any of
> the source releases dependent on the Forrest migration until
> it is clear it can support our needs and the migration plan
> is worked out.
So you're needing to know that whatever solution we choose it will
meet the needs of the web site, and that we don't tie any release of
Xerces with a website redesign, and that we work out a good migration
plan for the site?
I think what I can do is migrate the existing information to forrest,
and let everyone look it over. Then you all can give feedback. I'm not
capable of creating more of a plan than that.
Cheers, jas.
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Offer to update the build documentation at http://xerces.apache.org/xerces-c/build-winunix.html
Posted by Boris Kolpackov <bo...@codesynthesis.com>.
Hi Jason,
Sorry for the delay. Please see my comments below.
Jason Stewart <ja...@gmail.com> writes:
> Just for clarification. The Forrest system is mostly a superset of
> what stylebook provides. The irritating part is the index file
> organization has changed - otherwise it would simply be a perl script
> to change the sb tag names to forrest tag names.
Hm, I am now wondering why are we migrating to Forrset then? I thought
the idea was to replace the document system with something better and
more structured, and possibly redesign the appearance of the site to
look more modern?
> > Sure. What I meant is we shouldn't make any hard dependencies between
> > code releases and porting to Forrest until all the infrastructure-
> > related work is done and the migration path is clear and worked out.
> > This way, if the person with the expertise is suddenly unable to
> > finish the work, we won't be stuck with something half-done and
> > unable to move forward with the code base.
>
> Hmm...
>
> OK. So you want the new forrest site to be 3.0 specific?
I am not sure what you mean by "3.0 specific" but I don't think
that's what I meant ;-). My point is we shouldn't make any of
the source releases dependent on the Forrest migration until
it is clear it can support our needs and the migration plan
is worked out.
Boris
--
Boris Kolpackov
Code Synthesis Tools CC
http://www.codesynthesis.com
Open-Source, Cross-Platform C++ XML Data Binding
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Offer to update the build documentation at http://xerces.apache.org/xerces-c/build-winunix.html
Posted by Jason Stewart <ja...@gmail.com>.
Hi Boris,
Just for clarification. The Forrest system is mostly a superset of
what stylebook provides. The irritating part is the index file
organization has changed - otherwise it would simply be a perl script
to change the sb tag names to forrest tag names.
On Nov 6, 2007 12:00 PM, Boris Kolpackov <bo...@codesynthesis.com> wrote:
> Sure. What I meant is we shouldn't make any hard dependencies between
> code releases and porting to Forrest until all the infrastructure-
> related work is done and the migration path is clear and worked out.
> This way, if the person with the expertise is suddenly unable to
> finish the work, we won't be stuck with something half-done and
> unable to move forward with the code base.
Hmm...
OK. So you want the new forrest site to be 3.0 specific?
> I propose we do it like this: do the initial port on the side and
> then, when it is clear that the new setup can support all our use
> cases go ahead with migrating the rest of documentation. While
> this effort is underway, we can continue making new releases with
> the old documentation system. If the initial effort fails for some
> reason, then we have the old way of doing things to fall back on.
>
> I've been updating Xerces-C++ documentation not long ago and have
> a good idea of the tricky parts. I can create a list of files that
> would be good to port to Forrest as an initial port.
all sounds reasonable to me. jas.
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Offer to update the build documentation at http://xerces.apache.org/xerces-c/build-winunix.html
Posted by Boris Kolpackov <bo...@codesynthesis.com>.
Hi Jason,
Jason Stewart <ja...@gmail.com> writes:
> If Forrest is not the site-creation tool that we want to use, that is
> fine. But to suggest that someone shouldn't work on updating the site
> because 3.0 isn't ready seems strange. Perhaps i'm missing something.
> Would someone be willing to clarify?
Sure. What I meant is we shouldn't make any hard dependencies between
code releases and porting to Forrest until all the infrastructure-
related work is done and the migration path is clear and worked out.
This way, if the person with the expertise is suddenly unable to
finish the work, we won't be stuck with something half-done and
unable to move forward with the code base.
I propose we do it like this: do the initial port on the side and
then, when it is clear that the new setup can support all our use
cases go ahead with migrating the rest of documentation. While
this effort is underway, we can continue making new releases with
the old documentation system. If the initial effort fails for some
reason, then we have the old way of doing things to fall back on.
I've been updating Xerces-C++ documentation not long ago and have
a good idea of the tricky parts. I can create a list of files that
would be good to port to Forrest as an initial port.
Boris
--
Boris Kolpackov
Code Synthesis Tools CC
http://www.codesynthesis.com
Open-Source, Cross-Platform C++ XML Data Binding
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Offer to update the build documentation at http://xerces.apache.org/xerces-c/build-winunix.html
Posted by Jason Stewart <ja...@gmail.com>.
Hey,
On Nov 5, 2007 10:07 PM, Michael Glavassevich <mr...@ca.ibm.com> wrote:
> Boris Kolpackov <bo...@codesynthesis.com> wrote on 11/05/2007 10:58:33 AM:
> > Michael Glavassevich <mr...@ca.ibm.com> writes:
> > I would also like to suggest that we have all the infrastructure
> > issues worked out before we commit to migrating to Forrest.
>
> +1 to that.
Hmm.... Sorry, but I'm not clear why this is good. The current website
needs unification, and I have offers from at least one individual
willing to spend time working on the site.
I don't have offers from anyone to help with the auto* issues that are
keeping 3.0 from coming out the door.
If Forrest is not the site-creation tool that we want to use, that is
fine. But to suggest that someone shouldn't work on updating the site
because 3.0 isn't ready seems strange. Perhaps i'm missing something.
Would someone be willing to clarify?
Cheers, jas.
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Offer to update the build documentation at http://xerces.apache.org/xerces-c/build-winunix.html
Posted by Michael Glavassevich <mr...@ca.ibm.com>.
Boris Kolpackov <bo...@codesynthesis.com> wrote on 11/05/2007 10:58:33 AM:
> Hi Michael,
>
> Michael Glavassevich <mr...@ca.ibm.com> writes:
>
> > If someone who knows how to do that were to setup the infrastructure
> > I'd be happy to fill in the details.
>
> I would also like to suggest that we have all the infrastructure
> issues worked out before we commit to migrating to Forrest.
+1 to that.
> This way we won't end up in a situation that Xerces-C++ 3.0.0 is right
> now with autoconf where the person/people with the necessary
> expertise is/are unable to commit time to finish the built system.
>
> Boris
>
> --
> Boris Kolpackov
> Code Synthesis Tools CC
> http://www.codesynthesis.com
> Open-Source, Cross-Platform C++ XML Data Binding
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
> For additional commands, e-mail: c-dev-help@xerces.apache.org
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Offer to update the build documentation at http://xerces.apache.org/xerces-c/build-winunix.html
Posted by Boris Kolpackov <bo...@codesynthesis.com>.
Hi Michael,
Michael Glavassevich <mr...@ca.ibm.com> writes:
> If someone who knows how to do that were to setup the infrastructure
> I'd be happy to fill in the details.
I would also like to suggest that we have all the infrastructure
issues worked out before we commit to migrating to Forrest. This
way we won't end up in a situation that Xerces-C++ 3.0.0 is right
now with autoconf where the person/people with the necessary
expertise is/are unable to commit time to finish the built system.
Boris
--
Boris Kolpackov
Code Synthesis Tools CC
http://www.codesynthesis.com
Open-Source, Cross-Platform C++ XML Data Binding
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Offer to update the build documentation at http://xerces.apache.org/xerces-c/build-winunix.html
Posted by Michael Glavassevich <mr...@ca.ibm.com>.
Hi Jason,
"Jason Stewart" <ja...@gmail.com> wrote on 11/03/2007 06:54:02
AM:
> Yes that is a stylebook URI.
>
> That whole documentation system is no longer supported by apache (AFAIK).
>
> We had decided some time ago to switch over to the Forrest system, but
> only the Xerces-P project had migrated. It would be nice for all the
> xerces projects to use the same system.
>
> Forrest and stylebook are both XML based systems, but the DTD's are
> slightly different so the documents would have to be modified. I was
> talking to one of my students here and she said she would be willing
> to learn the Forrest system and migrate things over.
>
> Do people still think forrest is the way to go? Or is there another
> system which seems best?
I vaguely remember that we agreed to start with the top-level site
(http://xerces.apache.org/) to develop a look and feel for the
sub-projects. I started writing content once but have just never found the
time to learn how to create/build a site using Forrest. If someone who
knows how to do that were to setup the infrastructure I'd be happy to fill
in the details.
> Cheers, jas.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
> For additional commands, e-mail: c-dev-help@xerces.apache.org
Thanks.
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrglavas@ca.ibm.com
E-mail: mrglavas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Offer to update the build documentation at http://xerces.apache.org/xerces-c/build-winunix.html
Posted by Jason Stewart <ja...@gmail.com>.
Hi Justin,
On 10/23/07, Justin Dearing <zi...@gmail.com> wrote:
> I've begun playing with the source and have a few questions.
>
> 1) The XML Editor I am using
> http://xml-copy-editor.sourceforge.net/, does not allot the
> documents to validata against the DTD properly unless I change the following
> element from:
> <!DOCTYPE s1 SYSTEM "sbk:/style/dtd/document.dtd">
> to:
> <!DOCTYPE s1 SYSTEM "/style/dtd/document.dtd">
>
> Being XML Copy Editor uses xerces for its xml parsing I'm a bit surprised
> that it fails validation, but I can work on that with gerald. So is sbk: the
> uri indicator for stylebook? Where can I find more information about it, or
> apache project documentation in general.
Yes that is a stylebook URI.
That whole documentation system is no longer supported by apache (AFAIK).
We had decided some time ago to switch over to the Forrest system, but
only the Xerces-P project had migrated. It would be nice for all the
xerces projects to use the same system.
Forrest and stylebook are both XML based systems, but the DTD's are
slightly different so the documents would have to be modified. I was
talking to one of my students here and she said she would be willing
to learn the Forrest system and migrate things over.
Do people still think forrest is the way to go? Or is there another
system which seems best?
Cheers, jas.
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Offer to update the build documentation at http://xerces.apache.org/xerces-c/build-winunix.html
Posted by Justin Dearing <zi...@gmail.com>.
I've begun playing with the source and have a few questions.
1) The XML Editor I am using http://xml-copy-editor.sourceforge.net/, does
not allot the documents to validata against the DTD properly unless I change
the following element from:
<!DOCTYPE s1 SYSTEM "sbk:/style/dtd/document.dtd">
to:
<!DOCTYPE s1 SYSTEM "/style/dtd/document.dtd">
Being XML Copy Editor uses xerces for its xml parsing I'm a bit surprised
that it fails validation, but I can work on that with gerald. So is sbk: the
uri indicator for stylebook? Where can I find more information about it, or
apache project documentation in general.
Regards,
Justin Dearing
On 10/18/07, Boris Kolpackov <bo...@codesynthesis.com> wrote:
>
> Hi Justin,
>
> Justin Dearing <zi...@gmail.com> writes:
>
> > Personally I don't mind making changes that will last a couple of
> months.
> > Secondly, I think that even if the cygwin and mingw directions were
> > shortened to "see unix directions" in version 3.0, making that
> explicitly
> > clear, and organizing the documentation as per my suggestions would make
> > everything clear for parties not completely familiar with build systems.
>
> Ok, let's do this. You will need to check out the xerces-2 branch. This
> is a development branch for the 2-series code base:
>
> svn co https://svn.apache.org/repos/asf/xerces/c/branches/xerces-2
>
> The documentation is in the xerces-2/doc/ directory in .xml files.
> To generate actual .html files from these you will need to use the
> generatedocs{.sh,.bat} script in xerces-2/. Note that it needs
> java runtime. The resulting html is placed in xerces-2/doc/html/.
>
> I suggest that you add a section to build-winunix.xml for Mingw. You
> will also need to add a link in build.xml.
>
> Some thought on what would be good to have covered:
>
> - Building using both cygwin (-mno-cygwin) and msys toolchains.
>
> - Note about compiling application code with -DXML_LIBRARY when linking
> to the static Xerces-C++ library.
>
> - Note about this bug:
> http://marc.info/?l=xerces-c-users&m=118891009725180&w=2
>
> Once you are done, create a Jira issue and attach the patch to it. Make
> sure to grant the rights to ASF when uploading the patch (this way we
> will have a patch sign-off trail). After that I will review & commit
> it and regenerate the web site.
>
>
> > I would like to look over the 3.0 documentation before release and
> > see if there is anything unclear about it.
>
> Thanks, that would be great. We still haven't decided what to do with
> the docs for 3.0.0 and I am sure there will be a discussion on this
> matter here some time soon, so feel free to join in.
>
> Boris
>
> --
> Boris Kolpackov
> Code Synthesis Tools CC
> http://www.codesynthesis.com
> Open-Source, Cross-Platform C++ XML Data Binding
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
> For additional commands, e-mail: c-dev-help@xerces.apache.org
>
>
Re: Offer to update the build documentation at http://xerces.apache.org/xerces-c/build-winunix.html
Posted by Boris Kolpackov <bo...@codesynthesis.com>.
Hi Justin,
Justin Dearing <zi...@gmail.com> writes:
> I see no good deed goes unpunished.
Indeed ;-).
> Well what would it take to get binaries distributed? Is it simply a matter
> of me providing zipped compiled binaries? Or would this require
> modifications to an official build server? If its simply a matter of
> me attaching binaries to a jira ticker, and requires no build changes
> I'll do that.
It is quite a bit more involved. We will need to build, package (headers,
documentation, tests, etc.), test, and sign them as well as update
the download page and all other pages where we mention these things.
While none of this is undoable, I am wondering is these, arguably
marginal, platforms are worth the effort. Plus, AFAIK, Cygwin provides
pre-compiled binaries of Xerces-C++ as part of their distribution.
I am wondering of Mingw does or is willing to do the same thing.
> If its more complicated than that I would like to be involved in
> making thos platforms official for Xerces-3.
Yes, it will be much more natural to do this for 3.0.0.
> For the other platforms bullet list, I think its a good idea to make
> it a table listing both compiler and platform like the supported
> platforms. For gcc 3.2, we can simply list "Most platforms that have
> gcc 3.4 support." Does Forrest support macros via entities.dtd? If so
> I will move that table there. It will be useful for xerces 3.
I am not sure whether Forrest supports DTD or not, but I don't think
we should make porting to Forrest a requirement for release of 3.0.0.
Anyway, for now, let's minimize the amount of changes necessary to
get the Cygwin/Mingw instructions online.
Boris
--
Boris Kolpackov
Code Synthesis Tools CC
http://www.codesynthesis.com
Open-Source, Cross-Platform C++ XML Data Binding
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Offer to update the build documentation at http://xerces.apache.org/xerces-c/build-winunix.html
Posted by Justin Dearing <zi...@gmail.com>.
Boris,
On 11/5/07, Boris Kolpackov <bo...@codesynthesis.com> wrote:
> The notation is good. There is another problem however. If we add
> these platforms to the "Platforms and Binaries" table then we will
> have to build precompiled binaries for them (since the page says
> that they are available). This is getting quite a bit more
> complicated than simply adding the build instructions. Perhaps we
> should add these into the "Other Platforms and Compilers" section
> in readme.xml?
I see no good deed goes unpunished. Well what would it take to get
binaries distributed? Is it simply a matter of me providing zipped
compiled binaries? Or would this require modifications to an official
build server? If its simply a matter of me attaching binaries to a
jira ticker, and requires no build changes I'll do that. If its more
complicated than that I would like to be involved in making thos
platforms official for Xerces-3.
For the other platforms bullet list, I think its a good idea to make
it a table listing both compiler and platform like the supported
platforms. For gcc 3.2, we can simply list "Most platforms that have
gcc 3.4 support." Does Forrest support macros via entities.dtd? If so
I will move that table there. It will be useful for xerces 3.
Best regards,
Justin Dearing
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Offer to update the build documentation at http://xerces.apache.org/xerces-c/build-winunix.html
Posted by Boris Kolpackov <bo...@codesynthesis.com>.
Hi Justin,
Justin Dearing <zi...@gmail.com> writes:
> I currently added teo 32 bit windows targets:
> MinGW-GCC 3.4.x or later
> Cygwin-GCC 3.4.x or later
The notation is good. There is another problem however. If we add
these platforms to the "Platforms and Binaries" table then we will
have to build precompiled binaries for them (since the page says
that they are available). This is getting quite a bit more
complicated than simply adding the build instructions. Perhaps we
should add these into the "Other Platforms and Compilers" section
in readme.xml?
Boris
--
Boris Kolpackov
Code Synthesis Tools CC
http://www.codesynthesis.com
Open-Source, Cross-Platform C++ XML Data Binding
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Offer to update the build documentation at http://xerces.apache.org/xerces-c/build-winunix.html
Posted by Justin Dearing <zi...@gmail.com>.
Folks,
Question about the build platforms table.
I currently added teo 32 bit windows targets:
MinGW-GCC 3.4.x or later
Cygwin-GCC 3.4.x or later
Is that notation good?
Can someone testify to building with those envirorments using 64 bit
windows? Does the project claim to support those platforms on 64 bit
windows?
Regards,
Justin Dearing
On 10/18/07, Boris Kolpackov <bo...@codesynthesis.com> wrote:
> Hi Justin,
>
> Justin Dearing <zi...@gmail.com> writes:
>
> > Personally I don't mind making changes that will last a couple of months.
> > Secondly, I think that even if the cygwin and mingw directions were
> > shortened to "see unix directions" in version 3.0, making that explicitly
> > clear, and organizing the documentation as per my suggestions would make
> > everything clear for parties not completely familiar with build systems.
>
> Ok, let's do this. You will need to check out the xerces-2 branch. This
> is a development branch for the 2-series code base:
>
> svn co https://svn.apache.org/repos/asf/xerces/c/branches/xerces-2
>
> The documentation is in the xerces-2/doc/ directory in .xml files.
> To generate actual .html files from these you will need to use the
> generatedocs{.sh,.bat} script in xerces-2/. Note that it needs
> java runtime. The resulting html is placed in xerces-2/doc/html/.
>
> I suggest that you add a section to build-winunix.xml for Mingw. You
> will also need to add a link in build.xml.
>
> Some thought on what would be good to have covered:
>
> - Building using both cygwin (-mno-cygwin) and msys toolchains.
>
> - Note about compiling application code with -DXML_LIBRARY when linking
> to the static Xerces-C++ library.
>
> - Note about this bug:
> http://marc.info/?l=xerces-c-users&m=118891009725180&w=2
>
> Once you are done, create a Jira issue and attach the patch to it. Make
> sure to grant the rights to ASF when uploading the patch (this way we
> will have a patch sign-off trail). After that I will review & commit
> it and regenerate the web site.
>
>
> > I would like to look over the 3.0 documentation before release and
> > see if there is anything unclear about it.
>
> Thanks, that would be great. We still haven't decided what to do with
> the docs for 3.0.0 and I am sure there will be a discussion on this
> matter here some time soon, so feel free to join in.
>
> Boris
>
> --
> Boris Kolpackov
> Code Synthesis Tools CC
> http://www.codesynthesis.com
> Open-Source, Cross-Platform C++ XML Data Binding
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
> For additional commands, e-mail: c-dev-help@xerces.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Offer to update the build documentation at http://xerces.apache.org/xerces-c/build-winunix.html
Posted by Boris Kolpackov <bo...@codesynthesis.com>.
Hi Justin,
Justin Dearing <zi...@gmail.com> writes:
> Personally I don't mind making changes that will last a couple of months.
> Secondly, I think that even if the cygwin and mingw directions were
> shortened to "see unix directions" in version 3.0, making that explicitly
> clear, and organizing the documentation as per my suggestions would make
> everything clear for parties not completely familiar with build systems.
Ok, let's do this. You will need to check out the xerces-2 branch. This
is a development branch for the 2-series code base:
svn co https://svn.apache.org/repos/asf/xerces/c/branches/xerces-2
The documentation is in the xerces-2/doc/ directory in .xml files.
To generate actual .html files from these you will need to use the
generatedocs{.sh,.bat} script in xerces-2/. Note that it needs
java runtime. The resulting html is placed in xerces-2/doc/html/.
I suggest that you add a section to build-winunix.xml for Mingw. You
will also need to add a link in build.xml.
Some thought on what would be good to have covered:
- Building using both cygwin (-mno-cygwin) and msys toolchains.
- Note about compiling application code with -DXML_LIBRARY when linking
to the static Xerces-C++ library.
- Note about this bug:
http://marc.info/?l=xerces-c-users&m=118891009725180&w=2
Once you are done, create a Jira issue and attach the patch to it. Make
sure to grant the rights to ASF when uploading the patch (this way we
will have a patch sign-off trail). After that I will review & commit
it and regenerate the web site.
> I would like to look over the 3.0 documentation before release and
> see if there is anything unclear about it.
Thanks, that would be great. We still haven't decided what to do with
the docs for 3.0.0 and I am sure there will be a discussion on this
matter here some time soon, so feel free to join in.
Boris
--
Boris Kolpackov
Code Synthesis Tools CC
http://www.codesynthesis.com
Open-Source, Cross-Platform C++ XML Data Binding
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Offer to update the build documentation at http://xerces.apache.org/xerces-c/build-winunix.html
Posted by Justin Dearing <zi...@gmail.com>.
Boris,
I understand your concern about an irregular release. I also understand its
not just my time but the time of those that have to approve the changes and
commit them. So in the end it is up to you.
Personally I don't mind making changes that will last a couple of months.
Secondly, I think that even if the cygwin and mingw directions were
shortened to "see unix directions" in version 3.0, making that explicitly
clear, and organizing the documentation as per my suggestions would make
everything clear for parties not completely familiar with build systems. As
developers of a general purpose library used by multiple projects, the
xerces team is much more familiar with build systems and the like than
developers of more focused applications that use your code.
So If the docs are in the source I can grab the matest from source control,
find the docs and submit a patch if you think its worth it. If not I would
like to look over the 3.0 documentation before release and see if there is
anything unclear about it.
Thank you for your response.
Regards,
Justin Dearing
On 10/17/07, Boris Kolpackov <bo...@codesynthesis.com> wrote:
>
> Hi Justin,
>
> Justin Dearing <zi...@gmail.com> writes:
>
> > If the powers that be would like me to make these changes and submit a
> > patch.
>
> Thanks for the offer. When I was updating the documentation for 2.8.0,
> I considered adding a separate section for MinGW, but decided against
> it because (1) the MinGW-Msys toolchain is very similar to UNIX and
> (2) I didn't think there are many people using it. Perhaps I should
> have added it anyway.
>
> Now, after 2.8.0 is out, updating the documentation will require
> some considerations. The major problem is that the documentation
> is normally updated with the release (the source distribution
> contains a complete copy of documentation, the same as on the
> web). The second thing to consider is that the upcoming 3.0.0
> release will have a completely different, configure-based build
> system so the documentation section, at least for UNIX/Cygwin/Mingw,
> will need to be re-written pretty much from scratch. It is not
> clear to me that it is a good idea to spend time on writing
> documentation for MinGW while in a few months most people who
> are starting to use Xerces-C++ will be using 3.0.0.
>
> What do you think?
>
> Boris
>
> --
> Boris Kolpackov
> Code Synthesis Tools CC
> http://www.codesynthesis.com
> Open-Source, Cross-Platform C++ XML Data Binding
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
> For additional commands, e-mail: c-dev-help@xerces.apache.org
>
>
Re: Offer to update the build documentation at http://xerces.apache.org/xerces-c/build-winunix.html
Posted by Boris Kolpackov <bo...@codesynthesis.com>.
Hi Justin,
Justin Dearing <zi...@gmail.com> writes:
> If the powers that be would like me to make these changes and submit a
> patch.
Thanks for the offer. When I was updating the documentation for 2.8.0,
I considered adding a separate section for MinGW, but decided against
it because (1) the MinGW-Msys toolchain is very similar to UNIX and
(2) I didn't think there are many people using it. Perhaps I should
have added it anyway.
Now, after 2.8.0 is out, updating the documentation will require
some considerations. The major problem is that the documentation
is normally updated with the release (the source distribution
contains a complete copy of documentation, the same as on the
web). The second thing to consider is that the upcoming 3.0.0
release will have a completely different, configure-based build
system so the documentation section, at least for UNIX/Cygwin/Mingw,
will need to be re-written pretty much from scratch. It is not
clear to me that it is a good idea to spend time on writing
documentation for MinGW while in a few months most people who
are starting to use Xerces-C++ will be using 3.0.0.
What do you think?
Boris
--
Boris Kolpackov
Code Synthesis Tools CC
http://www.codesynthesis.com
Open-Source, Cross-Platform C++ XML Data Binding
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org