"Jeroen N. Witmond" <[EMAIL PROTECTED]> writes:
>> I threw a switch last night that causes all the .o files to end up at
>> the root of the make (src, for instance) rather than alongside their
>> src files. After continually stumbing over the .o files in the source
>> directory, I decided this was
"Scott Cantor" <[EMAIL PROTECTED]> writes:
>> http://www.pcug.org.au/~millerp/rmch/recu-make-cons-harm.html
>>
>> Taken in by those arguments, I've gone for the monolithic make in
>> large part. There are separate makefiles for obj, src, tests.
>
> Some of those arguments don't really seem
Axel Weiß <[EMAIL PROTECTED]> writes:
> Besides the danger of accidentially having object files be overwritten,
> if they have identical names and their sources in different subdirs,
> it's just unaesthetic to have all the object files lying around in an
> unstructured way. Don't you agree, tha
On May 26, 2005, at 11:47 PM, Jason E. Stewart wrote:
Hi James,
Cool!!
Please commit the linux fixes and I'll test it out with Xerces-P.
Hi Jason,
The latest from Axel (thanks Axel!) is that it was running on Linux,
at least some linux. I'd love to hear what you think.
Test away, test
> I threw a switch last night that causes all the .o files to end up at
> the root of the make (src, for instance) rather than alongside their
> src files. After continually stumbing over the .o files in the source
> directory, I decided this was better behavior. There are no conflicts
> that I kno
[ http://issues.apache.org/jira/browse/XERCESC-1348?page=all ]
David Bertoni updated XERCESC-1348:
---
Attachment: patch.txt
OK, I hope I got the patch right this time!
> IGXMLScanner allocates from wrong memory manager
>
Hi Scott,
On May 27, 2005, at 8:23 AM, Scott Cantor wrote:
http://www.pcug.org.au/~millerp/rmch/recu-make-cons-harm.html
Taken in by those arguments, I've gone for the monolithic make in
large part. There are separate makefiles for obj, src, tests.
Some of those arguments don't really
[
http://issues.apache.org/jira/browse/XERCESC-1420?page=comments#action_66470 ]
David Bertoni commented on XERCESC-1420:
I can certainly generalize it, since we could probably use it for other things
-- good idea!
As far as castTo() returning
> http://www.pcug.org.au/~millerp/rmch/recu-make-cons-harm.html
>
> Taken in by those arguments, I've gone for the monolithic make in
> large part. There are separate makefiles for obj, src, tests.
Some of those arguments don't really seem to hold that much with an
autotools-driven build.
Hi Axel,
On May 27, 2005, at 7:36 AM, Axel Weiß wrote:
yes, I overlooked it: you do check it in configure.ac through the
symbol
AC_CHECK_HEADERS. But this means that we require wchar.h
unconditionally on every platform. Are you sure that this header
always
exists?
I re-read this and real
> I figured cygwin should work like any other autoconf
> platform. Why am I wrong?
No, it does (I assume, at least, I've never done any cygwin builds of my
project). I misunderstood.
The vast majority of people need a native build, so I assumed that's what
was meant here and was hoping I'd be w
I am guessing your problem is that your GCC was not compiled with the
sparc64 configure option.
Try adding "-m64" to your CFLAGS and see if this fixes the problem.
HTH!
Matt
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Sent: Thursday, May 26, 2005 10:03 PM
To: c-de
Hi Scott,
At 10.49 27/05/2005 -0400, Scott Cantor wrote:
> - Work on autoconf checks for some of the windows facilities
> (transcoder, netaccessor, msgloader)
While this would be great, I don't see it being too useful since the GNU
toolchain doesn't produce makefiles for Windows compilers
Hi Scott,
On May 27, 2005, at 7:49 AM, Scott Cantor wrote:
- Work on autoconf checks for some of the windows facilities
(transcoder, netaccessor, msgloader)
While this would be great, I don't see it being too useful since
the GNU
toolchain doesn't produce makefiles for Windows compile
On May 27, 2005, at 7:36 AM, Axel Weiß wrote:
James Berry wrote:
Am I missing something? I do check for wchar.h.
Hi James,
yes, I overlooked it: you do check it in configure.ac through the
symbol
AC_CHECK_HEADERS. But this means that we require wchar.h
unconditionally on every platform
> - Work on autoconf checks for some of the windows facilities
> (transcoder, netaccessor, msgloader)
While this would be great, I don't see it being too useful since the GNU
toolchain doesn't produce makefiles for Windows compilers apart from the
cygwin stuff, and also, I doubt it you real
On May 27, 2005, at 7:17 AM, Alberto Massari wrote:
Hi James,
I can check how things works with MinGW, and try Windows compilers
(Borland, Visual Studio 6, Visual Studio 2003).
Alberto
Thanks Alberto,
You'll note that much of the support you'll need on the Windows side
of this is consp
James Berry wrote:
> Am I missing something? I do check for wchar.h.
Hi James,
yes, I overlooked it: you do check it in configure.ac through the symbol
AC_CHECK_HEADERS. But this means that we require wchar.h
unconditionally on every platform. Are you sure that this header always
exists?
Anot
Hi James,
I can check how things works with MinGW, and try Windows compilers
(Borland, Visual Studio 6, Visual Studio 2003).
Alberto
At 22.33 26/05/2005 -0700, James Berry wrote:
I've been working on the branch https://svn.apache.org/repos/asf/
xerces/c/branches/jberry/3.0-unstable on a first
Hey,
Elisha Berns wrote:
Gareth,
Thanks for the additional comments, it's good to know what the actual
developers of a tool think about it!
Rather any implementation of the schema specs.
Your comments beg the question what other schema standard looks better
than XSD at this point, Relax?, S
Hi Axel,
On May 27, 2005, at 12:40 AM, Axel Weiß wrote:
Hi James,
after updating, ./configure and make work out of the box for linux :)
Even better!
Some questions remain:
o shouldn't we check for the presence of wchar.h, as this header is
needed by iconv?
Am I missing something? I do ch
[
http://issues.apache.org/jira/browse/XERCESC-1348?page=comments#action_66435 ]
Christian Will commented on XERCESC-1348:
-
Hi Dave,
your patch is for xalan and not for xerces.
> IGXMLScanner allocates from wrong memory manager
> -
Am Freitag, 27. Mai 2005 08:47 schrieb James Berry:
> On May 26, 2005, at 11:38 PM, Axel Weiß wrote:
> > I have started to add linux support for autoconf. And got it through
> > after two hours only :)
>
> Nice Work. If you've got patches, send them along.
>
> > However, here's an issue with the li
[
http://issues.apache.org/jira/browse/XERCESC-1420?page=comments#action_66428 ]
James Berry commented on XERCESC-1420:
--
David,
Wow. You have been working hard!
I think this looks reasonable. You've basically done three things:
- Pass memorymgr
24 matches
Mail list logo
