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

[Greg Chicares]

On 2005-9-24 15:07 UTC, Vadim Zeitlin wrote:
> 
>  I'm not sure if this is appropriate for the lmi list so I send it directly
> to you but please feel free to reply to the list if you think this should
> be discused there.
> 
>  The question I want to ask is whether we should import the sources of at
> least some libraries used by lmi into the lmi cvs. The reason I'd like to
> do it is that it would make it simpler to maintain our modifications to
> them (we'd keep the original sources on a vendor branch and merge new
> releases as necessary). The 2 libraries I mostly have in mind are:
> 
> 1. libxml++: as you may remember, it uses Glib::ustring class and so
>    depends on libglibmm which, in turn, depends on entire GTK+ (half a
>    dozen of big libraries at least). I'd like to use std::string instead
>    of Glib::ustring which can be done rather easily, but it does require
>    modifying libxml++ sources (the least modification is to just add a
>    glibmm/ustring.h file to it, a slightly better one would be to also
>    tweak its source in a couple of places) and I'd like to have this patch
>    in the cvs. Alternatives don't look so good... Do notice that we'd still
>    be able to use system installed libxml++ (and glibmm) if they're
>    available, of course. The included library would be used only as a
>    fallback.

Here's the 'ustring' hack we discussed a couple months ago. Obviously
you know it, but I had forgotten it, and quote it here just to get it
into the mailing-list archive:

http://sourceforge.net/mailarchive/forum.php?thread_id=6179621&forum_id=12784

 #include <string>
 namespace Glib
 {
        typedef std::string ustring;
 }

It sounds like you have only small changes in mind. Could you just commit
a patch file to lmi's cvs? Wendy has been working steadily, as time permits,
on 'setup.make', which will automate things like this. That technique seems
to be working very well so far. If you supply the patches, she can maintain
the makefile that uses them.

> 2. wx: I think upgrading to a newer version of wx would be simpler if you
>    had a well-tested (by me) and known to work version of it in the lmi
>    cvs. It would also allow us to start using wxTreebook as soon as it's
>    ready (tomorrow normally) instead of waiting until it can be backported
>    to 2.6 branch. And the N-dimensional editor control would be easier to
>    write if I could do some refactoring in wx which would be impossible to
>    be ever ported to 2.6 at all, and so would be a problem unless we had
>    our own wx version. The only alternative I see here is to start
>    maintaining my own wx tree (which is something I did think about in the
>    past) and use it and not the official version in the lmi, but having
>    lmi-specific version would give you even more control and would be
>    simpler for me as well.

I don't think FSF would like that. I know of another project, which is
mainly hosted on sf.net, that wanted to keep a backup of its cvs on
savannah, and that request was disapproved. They'd certainly object
to anything that's not GPL compatible, especially '*.gif' files; those
could be removed, but we'd have to take great care with other libraries
that wx builds as well. If they see something they really dislike, they
might shut down the whole lmi project.

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

>  I don't think we need to import libxml2 and boost in the cvs but we could
> do it for consistency too. For the former it would probably solve the build
> issues under Win32 once and for all.

I believe there are official versions of those libraries that we don't
even need to patch. Let's see how well Wendy's work goes before we look
for a different way. I think she'll solve the msw problems once and for
all.

>  Please let me know what do you think and whether I can import at least
> libxml++ (I think to put it in 3rdparty/libxml++ directory). I'd like to
> take a decision about it relatively quickly because this also affects the
> new autoconf-based makefiles.

Sorry it's taken me several days to reply due to a major release. Can
you design the auto* files to assume that a suitably patched copy of
libxml++ exists in the appropriate directory? Wendy and I will take
responsibility for installing it if autotools can't handle that. Let
us know if we need to make that a high priority to support your work.