Re: [lmi] upgrade to xmlwrapp-0.6.0

[Greg Chicares]

On 2009-04-20 19:20Z, Vaclav Slavik wrote:
> 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.

If we did that in xmlwrapp itself, then I suppose we'd need to duplicate
much of lmi's 'como_4_3_3.make'.

Or, if we did that in lmi, then wouldn't we be perpetuating the issues
you describe below?

>> 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.

Lines 210-221 here:
  
http://cvs.savannah.gnu.org/viewvc/lmi/lmi/install_miscellanea.make?annotate=1.18
install '*.h *.cxx' in a directory, and validate the installation
using 'xmlwrapp-0.6.0.md5sums'. One could question whether the
benefits of that validation outweigh the costs of maintaining the
file of md5sums (yet lines 144-145 of the makefile explain how it
updates the md5sums).

And lines 91-105 here:
  http://cvs.savannah.gnu.org/viewvc/lmi/lmi/objects.make?annotate=1.150
list the object files.

It's not automatic, but it's not *extremely* difficult to maintain.

> 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. 

It demonstrates a disadvantage; but see below.

> 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.

I noticed that, but couldn't measure any improvement with
  CPPFLAGS='-DHAVE_BOOST_POOL_SINGLETON_POOL_HPP'
in the 'input_test' unit test's timings. Otherwise, I would have
added it. But that would still take 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).

OTOH, with today's lmi HEAD I can do this, trivially:
  make build_type=safestdlib unit_tests unit_test_targets=input_test.exe
  make build_type=mpatrol    unit_tests unit_test_targets=input_test.exe
The first uses '-D_GLIBCXX_DEBUG' etc., and the second uses a malloc
debugger. Those facilities are immensely valuable to me because they
may save days of effort fixing some urgent defect, perhaps before
it's noticed, or even before it's ever committed. Building with the
Comeau compiler is another inexpensive way of finding defects that
otherwise might cost a lot to fix. Such advantages are priceless:
I'm loath to surrender them for the sake of any alternative build
system, no matter what its other advantages may be.

That is not to say that I've yet found the least objectionable
method that secures those advantages--probably I haven't. AFAICT,
there's no tidy and convenient way to do this with autotools: they
don't accommodate Comeau at all; and, for memory debugging as above,
would seem to require so much overhead (to build each C++ library in
multiple ways, and to select the right one in each case) that we may
wind up in a worse position than today.

However, what do you think of this idea:
  
http://www.boost.org/doc/libs/1_38_0/libs/test/doc/html/utf/compilation/direct-include.html
which is used by several other boost libraries, and echoed in this
message:
  http://groups.google.com/group/boost-list/msg/7f925ca50d69384b?dmode=source
? In the case of xmlwrapp and xsltwrapp, we could do this:

  // xml_xslt_wrapper.cpp
  #include "src/xmlwrapp/ait_impl.cxx"
  ...
  #include "src/xmlwrapp/init.cxx"
  ...
  #include "src/xsltwrapp/init.cxx"
  ...

There's no 'init.cxx' name clash. There's no separate list of a
dozen object files to maintain in a makefile.

Such a file (or two separate files for xmlwrapp and xsltwrapp)
could reside in lmi. But then we'd still need to install the '.cxx'
files somewhere, and we'd have to be aware of external dependencies
(even if optional) like boost::singleton_pool.

Or such a file could be provided as part of the library, whose
configure script and makefile could handle all those issues. Then
again, you might not want that in the library.