lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] upgrade to xmlwrapp-0.6.0


From: Vaclav Slavik
Subject: Re: [lmi] upgrade to xmlwrapp-0.6.0
Date: Mon, 20 Apr 2009 21:20:05 +0200

On Fri, 2009-04-17 at 17:37 +0000, Greg Chicares wrote:
> When lmi itself is built using autotools, it should use libraries
> built separately with autotools, so I'll commit your 'configure.ac'
> and 'Makefile.am' patches without modification. But Comeau can't be
> supported that way.

That's not what I had in mind. I was suggesting to write a simple
makefile to build & install xmlwrapp when used with Comeau, analogically
to the existing install_libxml2_libxslt2.make.

> For the hand-written makefiles, I'm testing my old accustomed method:
> treating xmlwrapp's source files just like lmi's (except that they're
> in a different directory). That ought to work for any other compiler,
> too (e.g., Borland). And it's only about 100K in a dozen files, so it
> wouldn't matter if it got built more often than a library would.

Building more files isn't a problem. Having to maintain all this
makefiles code for xmlwrapp-as-part-of-lmi build concerns me much more.
Indeed, even though better build system for xmlwrapp was needed
independently of LMI, big part of my motivation was having a build
system sufficiently sane to replace LMI-specific build hacks on MSW.

> One obstacle I foresee is that xmlwrapp and xsltwrapp both contain an
> 'init.cxx'. Probably I'll rename them locally:
>   src/libxslt/init.cxx --> src/libxslt/xslt_init.cxx
>    src/libxml/init.cxx -->  src/libxml/xml_init.cxx
> to make the '.o' names unique.

This is a perfect example of why relying on xmlwrapp's native build
system would be better than maintaining a parallel one as part of LMI. 

Addition of new files is another example.

The fact that you should define HAVE_BOOST_POOL_SINGLETON_POOL_HPP when
building xmlwrapp for best performance (starting with 0.6.0) is yet
another: you can only know this if you review native build system
changes between xmlwrapp releases and it adds extra work.

In general, upgrading xmlwrapp is not a trivial task when its built as
part of LMI. Compare that to libxml2 or libxslt that are trivially
upgradeable -- so would xmlwrapp if autotools-based build system was
used for xmlwrapp too).

Regards,
Vaclav





reply via email to

[Prev in Thread] Current Thread [Next in Thread]