Re: Standalone Glibmm::ustring



Murray Cumming wrote:
> I guess you mean gtkmm, not glibmm, right?

Ah, yes, how stupid. It does indeed mention 20 dlls you will need for
gtkmm, and says nothing about which dlls you need for just glibmm.

>>  By trial on
>> error I have reduced this to six libraries I actually need - totalling
>> 7 MB.
>
> Out of interest, what are those 6 libraries?

It seems I accidentally counted iconv.dll as well, as such there is
only five libraries and 6 MB:

libglib-2.0-0.dll
libglibmm-2.4-1.dll
libgmodule-2.0-0.dll
libgobject-2.0-0.dll
libsigc-2.0-0.dll

> I'm not in any rush to do that myself, but it is open source, so you can
> do that if you really want. You can also patch libxml++ itself, if you'd
> like to maintain that:
> https://bugzilla.gnome.org/show_bug.cgi?id=320197

That sounds like it is indeed a more sensible thing to do then make an
isolated Glib:ustring library. Additionally, it would also simplify
the string handling in my application, as conversions between wxString
and Glib::ustring aren't too cute.

However, the given approach does not sound like a good one to me. It
makes a lot more sense to me to choose a string implementation at
runtime (perhaps with compile-time options to enable/disable choices).
This would shift the choice from the one that compiles the library
(end user) to the one who uses the library (the developer).
It has its downsides as well (like not automatically removing the
glibmm dependency from any application that uses libxml++), but it
will not cause sudden unexpected behavior.

> Personally, I'd just use the files already available from that installer
> and not worry about it.

Perhaps you are right...

Jasper Horn


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