Re: [lmi] Re: importing 3rd party libraries in the lmi cvs?

[Vadim Zeitlin]

On Thu, 29 Sep 2005 05:08:20 +0000 Greg Chicares <address@hidden> wrote:

GC> Here's the 'ustring' hack we discussed a couple months ago. Obviously
GC> you know it, but I had forgotten it, and quote it here just to get it
GC> into the mailing-list archive:
GC> 
GC> 
http://sourceforge.net/mailarchive/forum.php?thread_id=6179621&forum_id=12784
GC> 
GC>  #include <string>
GC>  namespace Glib
GC>  {
GC>     typedef std::string ustring;
GC>  }

 In fact I hadn't known it and found it independently before discovering
this message while searching for the reason why libxml++ required Glib::
ustring when it actually didn't use any of its specific methods.

 Also, this is not enough as libxml++ does use ustring::bytes() which has
to be replaced with std::string::size(). This replacement can't be done in
any "clean" way unfortunately. The only way to do it in the header file is
"#define bytes() size()" which is ugly to say the least. So either we have
to live with this ugly macro trick or change a few other source files.

 Finally, although I don't have much hope for it, I could try submitting a
clean patch to libxml++ maintainers adding some XMLPP_USE_STD_STRING symbol
which could be set/unset to use std::string/Glib::ustring.

GC> > 2. wx: I think upgrading to a newer version of wx would be simpler if you
GC> >    had a well-tested (by me) and known to work version of it in the lmi
GC> >    cvs.
GC> 
GC> I don't think FSF would like that.

 I don't know FSF well enough to comment on this... Personally, of course,
I find this completely unjustified but I realize that ways of FSF are often
impenetrable to common mortals.

GC> Perhaps another hosting facility should be considered for this purpose,
GC> a host that doesn't emphasize the FSF philosophy as strongly as FSF
GC> itself does; or even a branch on the main wx cvs. If you want to do
GC> something like that, I don't object as long as the changes get applied
GC> to the wx trunk in due course, because in the long term we want to be
GC> using official wx releases.

 A branch in main wx cvs doesn't make much sense as all these changes will
be in cvs HEAD anyhow. If you're find with using cvs HEAD then there is no
problem. But otherwise I'm afraid we have a logistic problem here. I.e.
take the (finished now) wxTreebook -- how can lmi use it _right_now_?

GC> Sorry it's taken me several days to reply due to a major release. Can
GC> you design the auto* files to assume that a suitably patched copy of
GC> libxml++ exists in the appropriate directory?

 There is even no need for this: autoconf makefiles would be simpler, of
course, if we can rely on libxml++ being installed in the system and not
have to worry about building a custom version of it ourselves.

 Regards,
VZ