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 James Berry <jb...@apache.org> on 2005/05/27 07:33:40 UTC
Xerces 3.0 autoconf/reorg progress update
I've been working on the branch https://svn.apache.org/repos/asf/
xerces/c/branches/jberry/3.0-unstable on a first cut at autoconf
support and cross-platform reorganization for Xerces 3.0.
It's now at a point where I've love to get a couple of other eyes on
it before I commit to (hah, hah) committing it to the main Xerces 3.0
trunk.
Highlights at present:
- It now builds on Mac OS X and Freebsd (on one box, anyway).
- Support for icu, iconv, and Mac OS transcoders.
- Support for sockets and macos netacessors.
- Support for inmemory message loader.
- Configure/build is through ./configure && make
- PlatformUtils refactored into finer chunks. Addition of new:
- AtomicOpManagers (Mac OS, Mutex-protected, NoThread)
- MutexManagers (Posix pthreads, NoThread)
- FileMangagers (Posix only at present)
Could one or several of you look it over and give feedback on this
before I merge to the main trunk? I want to make sure I haven't gone
completely astray.
Some things to watch out for:
- There are a few todo's, and areas where I cut some corners to
make things work. For instance, the timing section of PlatformUtils
will need some persuasion to be more cross platform.
- No Windows/VS support. I left a hole for an include with
custom settings in xerces_hdr_config.h, but didn't try to fill
anything in.
Feedback encouraged.
James.
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Xerces 3.0 autoconf/reorg progress update
Posted by "Jason E. Stewart" <ja...@openinformatics.com>.
Axel Weiß <aw...@informatik.hu-berlin.de> 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, that it would be much nicer to have
> recursive make again and one Makefile.am in each subdir?
One advantage to using automake is that if done properly, the user can
specify the build directory - this is so that the same source code
can be used for for building under multiple compilers (with different
target directories).
If we are shifting to automake we must really do this I feel.
Cheers,
jas.
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Xerces 3.0 autoconf/reorg progress update
Posted by James Berry <jb...@apache.org>.
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 realize maybe you misunderstand what
AC_CHECK_HEADERS does. It doesn't make the headers required, it
simply defines variables to indicate whether the headers exist. What
you do in response to that is up to you. In the case of Iconf and
wchar.h, we don't enable Iconv if wchar.h is missing. But that
doesn't mean wchar.h is required on all platforms...just that Iconv
can't be used if wchar.h isn't there.
James.
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Xerces 3.0 autoconf/reorg progress update
Posted by "Jason E. Stewart" <ja...@openinformatics.com>.
"Jeroen N. Witmond" <jn...@xs4all.nl> 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 better behavior. There are no conflicts
>> that I know of yet, and the nice part is that there's not a lot of
>> other code in src.
>>
>> Feedback on these decisions is welcome.
>>
>
> To prevent stumbling over .o files (or any generated file, for that
> matter) in the source directory, you can use a feature from the
> automake/configure tools that allows you to build outside the source
> directory. (The source distribution of gcc uses this, for instance.)
> Simply `cd builddir && /path/to/sourcedir/configure --whatever`.
Ah, yes. This is what I meant. Xerces-C should *not* enforce any
specific build dir, but instead should enable the user to set it.
Cheers,
jas.
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Xerces 3.0 autoconf/reorg progress update
Posted by "Jeroen N. Witmond" <jn...@xs4all.nl>.
> 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 know of yet, and the nice part is that there's not a lot of
> other code in src.
>
> Feedback on these decisions is welcome.
>
To prevent stumbling over .o files (or any generated file, for that
matter) in the source directory, you can use a feature from the
automake/configure tools that allows you to build outside the source
directory. (The source distribution of gcc uses this, for instance.)
Simply `cd builddir && /path/to/sourcedir/configure --whatever`.
Personally I favor a monolithic Makefile.am file, containing
'AUTOMAKE_OPTIONS = subdir-objects' to prevent the possibility of name
clashes in the build directory.
Jeroen.
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Xerces 3.0 autoconf/reorg progress update
Posted by "Jason E. Stewart" <ja...@openinformatics.com>.
"Scott Cantor" <ca...@osu.edu> 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 to hold that much with an
> autotools-driven build. There's certainly not a significant problem with
> over-recompilation that I've ever noticed, and that would be the worst of
> the problems that paper highlights to me.
If over-recompilation is the issue, than I would not worry at all. If
people area truly concerned about this they should look into using a
caching compiler like ccache as a front-end to their normal compiler.
I use ccache for all my projects. It enables me to do a complete make
clean before doing any build, and it only re-compiles the files whose
cpp output has changed. It's a great speed-up over complete
recompilation, and only a minor slowdown compared to fully dependancy
aware re-compilation.
Cheers,
jas.
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Xerces 3.0 autoconf/reorg progress update
Posted by James Berry <jb...@apache.org>.
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 seem to hold that much with an
> autotools-driven build. There's certainly not a significant problem
> with
> over-recompilation that I've ever noticed, and that would be the
> worst of
> the problems that paper highlights to me.
>
> I think the benefits of a modular set of understandable makefiles far
> outweigh any speed concerns (note that machines are a lot faster
> now...),
> but YMMV.
automake by itself leads to much simpler makefile source (though far
more complex generated makefiles, but that's the nature of the
beast). I've been very impressed by the speed with which the single
Makefile runs; I rather like it. I think if the single Makefile.am
gets too unwieldy we could break it down with automake includes of
each section from it's own directory.
Just my 2c.
-jdb
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
RE: Xerces 3.0 autoconf/reorg progress update
Posted by Scott Cantor <ca...@osu.edu>.
> 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. There's certainly not a significant problem with
over-recompilation that I've ever noticed, and that would be the worst of
the problems that paper highlights to me.
I think the benefits of a modular set of understandable makefiles far
outweigh any speed concerns (note that machines are a lot faster now...),
but YMMV.
-- Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Xerces 3.0 autoconf/reorg progress update
Posted by James Berry <jb...@apache.org>.
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. Are you sure that this header
> always
> exists?
No, I'm not sure that it always exists. We don't currently enable the
iconv transcoder, however, if it does not. The iconv transcoder
doesn't seem to be able to live without what it provides.
So: if we find a platform for which an alternative implementation
would work without wchar.h we can relax that check and provide
another workaround. Until then, iconv requires wchar.h.
> Another (minor) issue: now make is called in the src directory,
> once and
> for all subdirectories. This causes all object files be produced in
> the
> src directoy (because automake knows it not better;). This behaviour
> was originally not intended by the authors of automake, who instead
> want to have one Makefile.am in each subdir, and make be called
> recursively.
>
> 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, that it would be much nicer to have
> recursive make again and one Makefile.am in each subdir?
>
I've gone back and forth on this. There are very good arguments,
however, for using a single monolithic make rather than recursive make:
http://www.gnu.org/software/automake/manual/html_mono/
automake.html#Alternative
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.
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 know of yet, and the nice part is that there's not a lot of
other code in src.
Feedback on these decisions is welcome.
> Cheers,
> Axel
>
> --
> Humboldt-Universität zu Berlin
> Institut für Informatik
> Signalverarbeitung und Mustererkennung
> Dipl.-Inf. Axel Weiß
> Rudower Chaussee 25
> 12489 Berlin-Adlershof
> +49-30-2093-3050
> ** www.freesp.de **
>
> ---------------------------------------------------------------------
> 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: Xerces 3.0 autoconf/reorg progress update
Posted by Axel Weiß <aw...@informatik.hu-berlin.de>.
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?
Another (minor) issue: now make is called in the src directory, once and
for all subdirectories. This causes all object files be produced in the
src directoy (because automake knows it not better;). This behaviour
was originally not intended by the authors of automake, who instead
want to have one Makefile.am in each subdir, and make be called
recursively.
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, that it would be much nicer to have
recursive make again and one Makefile.am in each subdir?
Cheers,
Axel
--
Humboldt-Universität zu Berlin
Institut für Informatik
Signalverarbeitung und Mustererkennung
Dipl.-Inf. Axel Weiß
Rudower Chaussee 25
12489 Berlin-Adlershof
+49-30-2093-3050
** www.freesp.de **
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Xerces 3.0 autoconf/reorg progress update
Posted by James Berry <jb...@apache.org>.
On May 28, 2005, at 11:16 AM, Axel Weiß wrote:
> Am Samstag, 28. Mai 2005 19:03 schrieb James Berry:
>
>> Actually, there is a switch to libtool (--quiet) that does do this.
>>
>
> Oops, where did you find it?
> http://www.gnu.org/software/libtool/manual.html#Invoking-libtool
> doesn't
> tell anything about it.
I just cheated and looked at the script.
>> The one part of this that I'm not completely happy about so far is
>> that I had to use the .SILENT target, which turns off make output for
>> everything. I don't think this is completely desired, so I'm still
>> thinking about that one. I think there may be several solutions to
>> this, however.
>>
>
> Well, silent means that standard output is suppressed - stderr is
> still
> working. But isn't it exactly the behaviour we want to have?
Well, I think for some things you sort of want to know what it's
doing, like doing a make clean for instance. I'll check in a fix
pretty soon that cleans this up a bit, at the expense of some added
ugliness.
-jdb
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Xerces 3.0 autoconf/reorg progress update
Posted by Axel Weiß <aw...@informatik.hu-berlin.de>.
Am Samstag, 28. Mai 2005 19:03 schrieb James Berry:
> Actually, there is a switch to libtool (--quiet) that does do this.
Oops, where did you find it?
http://www.gnu.org/software/libtool/manual.html#Invoking-libtool doesn't
tell anything about it.
> Thank you very much for your patch. I wasn't real happy with the
> ugliness involved in having to override some of the auto-generated
> rules, so I came up with a slightly different approach that uses a
> helper-script. I'd love your feedback on how well this works.
James, this is a much more preferable solution! It was my first idea,
too, to redefine CXXCOMPILE and LTCXXCOMPILE, but in the first try it
didn't work.
> The one part of this that I'm not completely happy about so far is
> that I had to use the .SILENT target, which turns off make output for
> everything. I don't think this is completely desired, so I'm still
> thinking about that one. I think there may be several solutions to
> this, however.
Well, silent means that standard output is suppressed - stderr is still
working. But isn't it exactly the behaviour we want to have?
Axel
--
Humboldt-Universität zu Berlin
Institut für Informatik
Signalverarbeitung und Mustererkennung
Dipl.-Inf. Axel Weiß
Rudower Chaussee 25
12489 Berlin-Adlershof
+49-30-2093-3050
** www.freesp.de **
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Xerces 3.0 autoconf/reorg progress update
Posted by James Berry <ja...@jberry.us>.
Hi Axel,
On May 28, 2005, at 6:32 AM, Axel Weiß wrote:
> James Berry wrote:
>>> o would you like me to make the output of make look pretty? I can
>>> do it
>>> in a way that verbose make output is still an option.
>> How do you do this? Though automake somehow? Since the Makefile
>> itself is autogenerated, we certainly don't want to edit that ;) But
>> yeah, if it's easy and clean, that would be neat.
> it's mainly a matter of pulling some otherwise automatically generated
> rules into Makefile.am.
>
> There is no other way to tell libtool not to print out all executed
> commands than to redirect it's output to /dev/null. Instead, a smart
> message about the current state of compilation is written to the
> console.
Actually, there is a switch to libtool (--quiet) that does do this.
Thank you very much for your patch. I wasn't real happy with the
ugliness involved in having to override some of the auto-generated
rules, so I came up with a slightly different approach that uses a
helper-script. I'd love your feedback on how well this works.
The one part of this that I'm not completely happy about so far is
that I had to use the .SILENT target, which turns off make output for
everything. I don't think this is completely desired, so I'm still
thinking about that one. I think there may be several solutions to
this, however.
James.
> As I promised, this behaviour should be configurable, for debugging
> purposes. I chose, to define a configure argument --enable-verbose-
> make
> (which is disabled by default) to control the console output of make.
> This is done in a M4 macro (m4/verbose-make.m4). Depending on wheather
> this feature is enabled or not, three new symbols are defined: Q, V
> and
> AM_MAKEFLAGS. Q and V can have the value '#' or be empty, so the
> executed lines in each rule is controlled. AM_MAKEFLAGS can either be
> empty or have the vale '-s', in which case make itself becomes silent.
>
> I have implemented this feature for the src subdir only. If you
> like it -
> it's easy to extend it for other subdirs, too.
>
> I think, this is a rather consistent and straight forward method to
> influence the console output of autogenerated makefiles, as it uses
> only
> concepts offered by autoconf. Patchfile is attached (fitting to rev.
> 178817).
>
> Cheers,
> Axel
>
> --
> Humboldt-Universität zu Berlin
> Institut für Informatik
> Signalverarbeitung und Mustererkennung
> Dipl.-Inf. Axel Weiß
> Rudower Chaussee 25
> 12489 Berlin-Adlershof
> +49-30-2093-3050
> ** www.freesp.de **
>
> <pretty-make.diff>
> ---------------------------------------------------------------------
> 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: Xerces 3.0 autoconf/reorg progress update
Posted by Axel Weiß <aw...@informatik.hu-berlin.de>.
James Berry wrote:
> > o would you like me to make the output of make look pretty? I can
> > do it
> > in a way that verbose make output is still an option.
>
> How do you do this? Though automake somehow? Since the Makefile
> itself is autogenerated, we certainly don't want to edit that ;) But
> yeah, if it's easy and clean, that would be neat.
Hi James,
it's mainly a matter of pulling some otherwise automatically generated
rules into Makefile.am.
There is no other way to tell libtool not to print out all executed
commands than to redirect it's output to /dev/null. Instead, a smart
message about the current state of compilation is written to the
console.
As I promised, this behaviour should be configurable, for debugging
purposes. I chose, to define a configure argument --enable-verbose-make
(which is disabled by default) to control the console output of make.
This is done in a M4 macro (m4/verbose-make.m4). Depending on wheather
this feature is enabled or not, three new symbols are defined: Q, V and
AM_MAKEFLAGS. Q and V can have the value '#' or be empty, so the
executed lines in each rule is controlled. AM_MAKEFLAGS can either be
empty or have the vale '-s', in which case make itself becomes silent.
I have implemented this feature for the src subdir only. If you like it -
it's easy to extend it for other subdirs, too.
I think, this is a rather consistent and straight forward method to
influence the console output of autogenerated makefiles, as it uses only
concepts offered by autoconf. Patchfile is attached (fitting to rev.
178817).
Cheers,
Axel
--
Humboldt-Universität zu Berlin
Institut für Informatik
Signalverarbeitung und Mustererkennung
Dipl.-Inf. Axel Weiß
Rudower Chaussee 25
12489 Berlin-Adlershof
+49-30-2093-3050
** www.freesp.de **
Re: Xerces 3.0 autoconf/reorg progress update
Posted by James Berry <jb...@apache.org>.
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 check for wchar.h.
> o would you like me to make the output of make look pretty? I can
> do it
> in a way that verbose make output is still an option.
How do you do this? Though automake somehow? Since the Makefile
itself is autogenerated, we certainly don't want to edit that ;) But
yeah, if it's easy and clean, that would be neat.
James.
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Xerces 3.0 autoconf/reorg progress update
Posted by Axel Weiß <aw...@informatik.hu-berlin.de>.
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 links in the config directory -
> > on my
> > system, the destination files are found at /usr/share/libtool,
> > rather than at /opt/local/share/libtool. I have no idea about how to
> > fix this in a platform- and distribution-independend way. My simple
> > workaround, deleting the links and creating new ones to the right
> > destination, surely would break e.g. your setup - so how could we
> > fix this?
>
> The symbolic links were there in error. If you update you'll see that
> I've checked in real files instead of symbolic links.
Hi James,
after updating, ./configure and make work out of the box for linux :)
So my previous changes seem to be obsolete. Mainly, I have checked to
support the iconv transcoder, if host_os matched linux*, and activated
it. As you now check for iconv before the host_os checks, it is
activated anyway as the default transcoder, and my additional checks
don't need to take place any more.
Some questions remain:
o shouldn't we check for the presence of wchar.h, as this header is
needed by iconv?
o would you like me to make the output of make look pretty? I can do it
in a way that verbose make output is still an option.
Cheers,
Axel
--
Humboldt-Universität zu Berlin
Institut für Informatik
Signalverarbeitung und Mustererkennung
Dipl.-Inf. Axel Weiß
Rudower Chaussee 25
12489 Berlin-Adlershof
+49-30-2093-3050
** www.freesp.de **
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Xerces 3.0 autoconf/reorg progress update
Posted by James Berry <ja...@jberry.us>.
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 away.
James.
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Xerces 3.0 autoconf/reorg progress update
Posted by "Jason E. Stewart" <ja...@openinformatics.com>.
James Berry <ja...@jberry.us> writes:
> 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.
Hi James,
Cool!!
Please commit the linux fixes and I'll test it out with Xerces-P.
Cheers,
jas.
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Xerces 3.0 autoconf/reorg progress update
Posted by James Berry <ja...@jberry.us>.
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 links in the config directory -
> on my
> system, the destination files are found at /usr/share/libtool, rather
> than at /opt/local/share/libtool. I have no idea about how to fix this
> in a platform- and distribution-independend way. My simple workaround,
> deleting the links and creating new ones to the right destination,
> surely would break e.g. your setup - so how could we fix this?
The symbolic links were there in error. If you update you'll see that
I've checked in real files instead of symbolic links.
James.
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Xerces 3.0 autoconf/reorg progress update
Posted by Axel Weiß <aw...@informatik.hu-berlin.de>.
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 cut at autoconf
> support and cross-platform reorganization for Xerces 3.0.
>
> It's now at a point where I've love to get a couple of other eyes on
> it before I commit to (hah, hah) committing it to the main Xerces 3.0
> trunk.
>
> Highlights at present:
>
> - It now builds on Mac OS X and Freebsd (on one box, anyway).
> - Support for icu, iconv, and Mac OS transcoders.
> - Support for sockets and macos netacessors.
> - Support for inmemory message loader.
> - Configure/build is through ./configure && make
>
> - PlatformUtils refactored into finer chunks. Addition of new:
> - AtomicOpManagers (Mac OS, Mutex-protected, NoThread)
> - MutexManagers (Posix pthreads, NoThread)
> - FileMangagers (Posix only at present)
>
> Could one or several of you look it over and give feedback on this
> before I merge to the main trunk? I want to make sure I haven't gone
> completely astray.
Hi James,
great work! For me it seems like a reasonable framework, and it should be
rather easy to plug support for other platforms.
I have started to add linux support for autoconf. And got it through
after two hours only :)
However, here's an issue with the links in the config directory - on my
system, the destination files are found at /usr/share/libtool, rather
than at /opt/local/share/libtool. I have no idea about how to fix this
in a platform- and distribution-independend way. My simple workaround,
deleting the links and creating new ones to the right destination,
surely would break e.g. your setup - so how could we fix this?
Cheers,
Axel
--
Humboldt-Universität zu Berlin
Institut für Informatik
Signalverarbeitung und Mustererkennung
Dipl.-Inf. Axel Weiß
Rudower Chaussee 25
12489 Berlin-Adlershof
+49-30-2093-3050
** www.freesp.de **
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
RE: Xerces 3.0 autoconf/reorg progress update
Posted by Alberto Massari <am...@datadirect.com>.
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 apart from the
>cygwin stuff, and also, I doubt it you really want to require the cygwin
>autotools to build Xerces from source on Windows.
There will be support for the official proprietary compilers running on
Windows, through their own makefile/project architecture; but some people
wants to use cygwin or MinGW on Windows (or even Microsoft Services for
Unix), so it's better our autoconf code can pick the Windows code in that case.
Alberto
>Myself, I maintain config_win32.h files that predefine the autoconf test
>results so that the code doesn't know the difference.
>
>I'd be happy to learn there's actually a clean way to use autotools on
>Windows though...
>
>-- 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: Xerces 3.0 autoconf/reorg progress update
Posted by Scott Cantor <ca...@osu.edu>.
> 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 wrong about it not working, that's why
I asked.
In truth, it would be nice if somebody just wrote the patches needed to get
autotools to generate the Microsoft compiler switches, but nobody's ever
found the time I guess.
-- Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Xerces 3.0 autoconf/reorg progress update
Posted by James Berry <jb...@apache.org>.
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 compilers apart
> from the
> cygwin stuff, and also, I doubt it you really want to require the
> cygwin
> autotools to build Xerces from source on Windows.
I figured cygwin should work like any other autoconf platform. Why am
I wrong?
> Myself, I maintain config_win32.h files that predefine the autoconf
> test
> results so that the code doesn't know the difference.
>
> I'd be happy to learn there's actually a clean way to use autotools on
> Windows though...
I'm hope we can all come up with a good answer together. I left some
hooks in xerces_hdr_config.h for platform specific inclusion of non-
autoconf headers as necessary. These may or may not prove to be
sufficient for the task.
Your ideas welcome here! ;)
James.
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
RE: Xerces 3.0 autoconf/reorg progress update
Posted by Scott Cantor <ca...@osu.edu>.
> - 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 really want to require the cygwin
autotools to build Xerces from source on Windows.
Myself, I maintain config_win32.h files that predefine the autoconf test
results so that the code doesn't know the difference.
I'd be happy to learn there's actually a clean way to use autotools on
Windows though...
-- Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Xerces 3.0 autoconf/reorg progress update
Posted by James Berry <jb...@apache.org>.
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 conspicuously absent, as I don't have any facility to work
on it.
You'll probably need to:
- Work on autoconf checks for some of the windows facilities
(transcoder, netaccessor, msgloader)
- Create new facilities for windows (mutexmanager,
atomicopmanager, filemanager), and appropriate autoconf checks for t
hem. Most of these can be modeled after the existing other facilities
of like name, and with code cribbed from the old WindowsPlatformUtils.
- Other things, which I'm sure you'll tell me about ;)
James.
>
> 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 cut at autoconf
>> support and cross-platform reorganization for Xerces 3.0.
>>
>> It's now at a point where I've love to get a couple of other eyes on
>> it before I commit to (hah, hah) committing it to the main Xerces 3.0
>> trunk.
>>
>> Highlights at present:
>>
>> - It now builds on Mac OS X and Freebsd (on one box, anyway).
>> - Support for icu, iconv, and Mac OS transcoders.
>> - Support for sockets and macos netacessors.
>> - Support for inmemory message loader.
>> - Configure/build is through ./configure && make
>>
>> - PlatformUtils refactored into finer chunks. Addition of new:
>> - AtomicOpManagers (Mac OS, Mutex-protected, NoThread)
>> - MutexManagers (Posix pthreads, NoThread)
>> - FileMangagers (Posix only at present)
>>
>> Could one or several of you look it over and give feedback on this
>> before I merge to the main trunk? I want to make sure I haven't gone
>> completely astray.
>>
>> Some things to watch out for:
>>
>> - There are a few todo's, and areas where I cut some corners to
>> make things work. For instance, the timing section of PlatformUtils
>> will need some persuasion to be more cross platform.
>>
>> - No Windows/VS support. I left a hole for an include with
>> custom settings in xerces_hdr_config.h, but didn't try to fill
>> anything in.
>>
>> Feedback encouraged.
>>
>> James.
>>
>> ---------------------------------------------------------------------
>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Xerces 3.0 autoconf/reorg progress update
Posted by Alberto Massari <am...@datadirect.com>.
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 cut at autoconf
>support and cross-platform reorganization for Xerces 3.0.
>
>It's now at a point where I've love to get a couple of other eyes on
>it before I commit to (hah, hah) committing it to the main Xerces 3.0
>trunk.
>
>Highlights at present:
>
> - It now builds on Mac OS X and Freebsd (on one box, anyway).
> - Support for icu, iconv, and Mac OS transcoders.
> - Support for sockets and macos netacessors.
> - Support for inmemory message loader.
> - Configure/build is through ./configure && make
>
> - PlatformUtils refactored into finer chunks. Addition of new:
> - AtomicOpManagers (Mac OS, Mutex-protected, NoThread)
> - MutexManagers (Posix pthreads, NoThread)
> - FileMangagers (Posix only at present)
>
>Could one or several of you look it over and give feedback on this
>before I merge to the main trunk? I want to make sure I haven't gone
>completely astray.
>
>Some things to watch out for:
>
> - There are a few todo's, and areas where I cut some corners to
>make things work. For instance, the timing section of PlatformUtils
>will need some persuasion to be more cross platform.
>
> - No Windows/VS support. I left a hole for an include with
>custom settings in xerces_hdr_config.h, but didn't try to fill
>anything in.
>
>Feedback encouraged.
>
>James.
>
>---------------------------------------------------------------------
>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