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

[Greg Chicares]

On 2005-9-29 8:55 UTC, Vadim Zeitlin wrote:
> 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.

Thanks, I wasn't aware of that.

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

I fully support that. Even though they've explained their rationale here:
  http://libxmlplusplus.sourceforge.net/docs/manual/html/index.html#id2472068
they must get complaints about this. If their library optionally supported
the standard string class, that would completely answer such complaints.

> 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
[but where? some discussion snipped...]

>  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_?

For today at least, I think it's OK if we'd have to use cvs HEAD. But
Wendy is closer to this than I am, and might point out problems that
I don't realize.

For the long-term future, official wx releases should work fine.

In the interim, we might run into the real logistic problem you describe.
If so, I suppose we could validate lmi with the wx cvs as of a particular
date and time, and anyone who needs to build it could check out wx as of
then; that would guard against any later destabilizing change to cvs.