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 Boris Kolpackov <bo...@codesynthesis.com> on 2007/08/08 11:53:00 UTC

A few questions on the 3.0 build system

Hi,

I have a couple of questions/concerns about the new autotools-based
build system in the trunk (upcoming 3.0):

1. Why rename libxerces-c.so/.a to libxerces.so/.a? This makes the
   job of supporting both 3.0 and older releases more complicated
   (the interface differences are relatively easy to resolve with
   the preprocessor).

2. Why factor out messages to a separate library (libXercesMessages)
   that the application developer has to link to? This makes it more
   difficult to support both 3.0 and older releases. Also, AFAICS,
   this is not done for Windows builds. Can this at least be made
   optional via a configure option? BTW, this library is not
   installed (see below).

3. Why build all those libraries (libdom, libinternal, etc.)?
   They are not installed so it seems their only purpose is
   to take up space and slow down the build speed.


The last one is more of a bug report than a question: when
I try to install Xerces-C++, I get

No rule to make target `res-install', needed by `install'

in the src/xercesc/util/MsgLoaders/ICU/Makefile.in. It seems
the res-install target is left unimplemented there as well
as in src/xercesc/util/MsgLoaders/MsgCatalog/Makefile.in. Any
idea on what's going here?


Thanks,
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: A few questions on the 3.0 build system

Posted by Boris Kolpackov <bo...@codesynthesis.com>.
Hi Alberto,

Alberto Massari <am...@datadirect.com> writes:

> The library name is specified in the autoconf script (I think), so
> the name must have been a choice of James who wrote the script in the
> first place. We can change it to be xerces-c if this helps the users.

I think this is a good idea. I came up with a patch (below). I noticed
one more thing: after I applied this patch, I had to regenerate
Makefile.in's by running the reconf script. After that the examples
stopped building:

/bin/sh ../libtool --tag=CXX --mode=link g++  -g -O2 -pthread -o \
CreateDOMDocument  src/CreateDOMDocument/CreateDOMDocument.o \
../obj/libxerces-c.la -lnsl  -L/usr/lib -licuuc -licudata -L/usr/lib \
-licuuc -licudata

g++ -g -O2 -pthread -o .libs/CreateDOMDocument \
src/CreateDOMDocument/CreateDOMDocument.o  ../obj/.libs/libxerces-c.so \
-lnsl -L/usr/lib -licuuc -licudata

/usr/bin/ld: warning: libXercesMessages3_0_0.so, needed by
../obj/.libs/libxerces-c.so, not found (try using -rpath or -rpath-link)

../obj/.libs/libxerces-c.so: undefined reference to `XercesMessages3_0_0_dat'

The only difference that I can see in libxerces-c.la compared to the
one built before running reconf is the different version of libtool
being used (1.5.23a vs 1.5.25). I also remember the original version
of libtool linking to libXercesMessages3_0_0.so explicitly while the
later one does not do this. Seems like the behavior of libtool has
changed (I assume that because libxerces-c.so is linked to
libXercesMessages.so, libtool thinks that it does not need to link
to libXercesMessages.so explicitly, which makes sense). Not sure
what to do about all this.


> That library has always been there, when ICU is chosen as the message
> loader (the choice is automatic if ICU is available).

Ah, I see. I guess this shouldn't be a big problem as long as
libxerces-c.so links to libXercesMessages.so and the application
developer does not need to link to it explicitly (at least not in
case of shared library).


> That's a side effect of having the sources in multiple
> subdirectories; autoconf must create "convenience libraries" from
> each folder (BTW, the libraries should be more; in fact the
> combination Cygwin+MSVC doesn't work)

Got it. Do you know what needs to be done to make Cygwin work?


Thanks,
Boris


Index: tests/Makefile.am
===================================================================
--- tests/Makefile.am	(revision 563790)
+++ tests/Makefile.am	(working copy)
@@ -21,7 +21,7 @@

 check_PROGRAMS =					${testprogs}

-LDADD =								${top_builddir}/obj/libxerces.la
+LDADD =								${top_builddir}/obj/libxerces-c.la
 # the  -I${top_builddir}/src is needed to pick the xercesc/util/Xerces_autoconf_config.hpp
 # header file when doing out-of-tree builds
 AM_CPPFLAGS =						 -I${top_builddir}/src -I${top_srcdir}/src
Index: samples/Makefile.am
===================================================================
--- samples/Makefile.am	(revision 563790)
+++ samples/Makefile.am	(working copy)
@@ -21,7 +21,7 @@

 bin_PROGRAMS =						${sampleprogs}

-LDADD =							    ${top_builddir}/obj/libxerces.la
+LDADD =							    ${top_builddir}/obj/libxerces-c.la
 # the  -I${top_builddir}/src is needed to pick the xercesc/util/Xerces_autoconf_config.hpp
 # header file when doing out-of-tree builds
 AM_CPPFLAGS =						 -I${top_builddir}/src -I${top_srcdir}/src
Index: obj/Makefile.am
===================================================================
--- obj/Makefile.am	(revision 563790)
+++ obj/Makefile.am	(working copy)
@@ -21,14 +21,13 @@

 include ../version.incl

-lib_LTLIBRARIES	= 			libxerces.la
-libxerces_la_SOURCES =
-nodist_EXTRA_libxerces_la_SOURCES = dummyfile-to-force-cpp-linking.cpp
+lib_LTLIBRARIES	= 			libxerces-c.la
+libxerces_c_la_SOURCES =
+nodist_EXTRA_libxerces_c_la_SOURCES = dummyfile-to-force-cpp-linking.cpp

-libxerces_la_LIBADD = 		${top_builddir}/src/libsrc.la ${top_builddir}/lib/libcompat.la
-libxerces_la_LDFLAGS =		-release ${PACKAGE_VERSION}
+libxerces_c_la_LIBADD = 		${top_builddir}/src/libsrc.la ${top_builddir}/lib/libcompat.la
+libxerces_c_la_LDFLAGS =		-release ${PACKAGE_VERSION}

 if XERCES_USE_MSGLOADER_ICU
-libxerces_la_LDFLAGS +=		-L${top_builddir}/obj/.libs -lXercesMessages$(VER)
+libxerces_c_la_LDFLAGS +=		-L${top_builddir}/obj/.libs -lXercesMessages$(VER)
 endif
-
-- 
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: A few questions on the 3.0 build system

Posted by Alberto Massari <am...@datadirect.com>.
Hi Boris,

At 09.53 08/08/2007 +0000, Boris Kolpackov wrote:
>Hi,
>
>I have a couple of questions/concerns about the new autotools-based
>build system in the trunk (upcoming 3.0):
>
>1. Why rename libxerces-c.so/.a to libxerces.so/.a? This makes the
>    job of supporting both 3.0 and older releases more complicated
>    (the interface differences are relatively easy to resolve with
>    the preprocessor).

The library name is specified in the autoconf script (I think), so 
the name must have been a choice of James who wrote the script in the 
first place. We can change it to be xerces-c if this helps the users.


>2. Why factor out messages to a separate library (libXercesMessages)
>    that the application developer has to link to? This makes it more
>    difficult to support both 3.0 and older releases. Also, AFAICS,
>    this is not done for Windows builds. Can this at least be made
>    optional via a configure option? BTW, this library is not
>    installed (see below).

That library has always been there, when ICU is chosen as the message 
loader (the choice is automatic if ICU is available). If you don't 
need the extra features of ICU resource bundles, you should specify 
--enable-msgloader-inmemory to have the strings stored inside the 
Xerces library.


>3. Why build all those libraries (libdom, libinternal, etc.)?
>    They are not installed so it seems their only purpose is
>    to take up space and slow down the build speed.

That's a side effect of having the sources in multiple 
subdirectories; autoconf must create "convenience libraries" from 
each folder (BTW, the libraries should be more; in fact the 
combination Cygwin+MSVC doesn't work)



>The last one is more of a bug report than a question: when
>I try to install Xerces-C++, I get
>
>No rule to make target `res-install', needed by `install'
>
>in the src/xercesc/util/MsgLoaders/ICU/Makefile.in. It seems
>the res-install target is left unimplemented there as well
>as in src/xercesc/util/MsgLoaders/MsgCatalog/Makefile.in. Any
>idea on what's going here?

Those makefiles have been manually ported to autoconf, and are still 
missing a few cases; I'll see to fix the install part.

Thanks for testing the build,
Alberto


>Thanks,
>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