Re: Data on eglib vs glib, implications for embedded use of bluez

[Marcel Holtmann <marcel@holtmann.org>]

Hi Nick,

> With bluez 4.x, support for Embedded GLIB (EGLib) support was dropped,
> and GLib became a requirement for bluez.
> 
> This presents some challenges for embedded platforms. I want to
> present some data from my experience of using both glib and eglib with
> bluez 4.6, and suggest that eglib become a supported option for bluez.
> 
> -- Size of GLIB compared to EGLIB --
> 
> compiled size of glib static library (see file list later) VS eglib:
>             RAW   STRIPPED
> libglib.a   2147 k       695 k
> libeglib.a   137 k        37 k
> 
> compiled size of bluetoothd w/glib compared to bluetoothd w/eglib
>                     RAW   STRIPPED
> bluetoothd w/glib  1489 k       462 k
> bluetoothd w/eglib  530 k       117 k
> 
> ** bluetoothd _triples_ in size when using glib **

I assume that you are talking about GLib statically linked into
bluetoothd. Systems that already have GLib anyway benefit from it.

> I guess it comes down to whether Bluez wants to support an embedded
> configuration. If Bluez is happy to abandon embedded, then they can
> forget eglib. But it Bluez is serious about supporting embedded
> configurations, it should keep eglib as a supported option in my
> opinion.
> 
> I understand that one concern about eglib support is a lack of
> maintenance. I would be happy to help out with eglib support.

I can bring up a project that contains eglib and we maintain it outside
of bluez-4.x source code. You just have to install it first and if you
use pkg-config you would have a perfect drop-in replacement. If you
compile it by yourself you do whatever fits best.

> If supporting eglib is not an option, I am very much interested to
> hear the specific reasons as to why not. Is it due to eglib bugs? lack
> of eglib features (which ones)? or is embedded just not significant
> enough to be a concern?

As long as eglib has the same API as GLib it is not a problem of support
at all. We do that already. The main reason why we removed it from the
source code was that it just became a maintenance nightmare.

Do you have a problem to maintain it in a separate source tree and
release it as separate packages?

Regards

Marcel