Comment 15 for bug 1373928

(In reply to comment #10)
> Ah, in 8165fc23014c8044c131cb6e1fd0c5e06fd0da2d I've added dbtools to
> libmerged just to fix circular dependency without checking it's OK.

> Or, get dbtools out of libmerged and create some hack for whatever was the
> reason to link against dbtools in 86bdb13704d9d85a247339071a86d301ce86cd7f
> "fdo#67615 TextField in table should use same formatting as floating
> TextField"

The reason what that LibreOffice contains two implementations of the same "feature", namely in a database context to format a value. I ripped out the use of one (svxform::OTypeConversionClient, which was buggy in the way described in bug 67615) in the favour of the other (dbtools::FormattedColumnValue).

> I don't know what's in dbtools library.

Utilities and base classes that are useful in a database context.

> I would think it's not core functionality

What is "core functionality" and what is not "core functionality" in LibreOffice? Do we have a clear policy about that?

> to be really needed and used in libmerged (svxcore) but maybe
> it is?

Well, parts of svxcore *do* deal with database stuff, so *if* svxcore is to be considered as completely "core functionality", then dealing with database stuff is "core functionality". If this contradicts in some way the yet-unknown-to-me policy about "core functionality", and *parts* of svxcore need to be considered "core feature" then maybe we can/should rip out the non-core parts of svxcore out of svxcore and place them into another library?

More hackishly, there is some infrastructure in place (namely connectivity::ODataAccessStaticTools) to handle this kind of things as a "dlopen at runtime instead of build-time link". We could extend that, but I'd much rather we solved the root cause rather than extending a band-aid (which I'd rather see destroyed).