On Fri, 2013-12-13 at 11:36 +0100, Stephan Bergmann wrote:
> To be clear, this is about source files, not installation-/run-time ones.
Sure - but even so - there are a lot of components ;-)
xmllint --format services.rdb | grep '<implementation' | wc -l
1019
git ls-files | grep '\.component' | wc -l
270
I'd prefer not to add (and maintain) another 700 tiny files to git that
are mostly headers; or did I miss the suggestion ?
I guess until we have mergedlibs on Windows, we can't easily dispense
with the .component files for internal components and just build an
internal data-structure. Even if we did, I imagine compiling /
generating that from .component files might be more interesting &
elegant anyway.
> >> Or, as you detail below, go further and add more efficient support for
> >> the "single-object-implementation" factory case. (Do you have any idea
> >> whether this is worth it, given we have to continue supporting the other
> >> case for extension-compatibility anyway?)
> >
> > Sure it's worth it given we're primarily looking for size savings for
> > mobile; for the Linux case we get only marginal wins here I think.
>
> I'd assume the major size savings would come from leaving out unused
> areas of code, and that would already be possible without the "go
> further" part.
True - but while we're here - AFAICS we should go further to clean that
up & make it more efficient =) it's a golden opportunity I think.
> The duplication is an unfortunate consequence of the move from active to
> passive component registration. And as the code was already there, I
> never bothered too much to change that to instead re-use the .rdb data.
> (Which wouldn't have been easy or elegant, but that might be different
> if we represent the .rdb data not in an additional file read at start-up
> but in some compiled-in data structures).
Yes - it's a great idea. I love it as an iteration - not least because
it should/could kill all that horrible native-code.cxx duplication =)
Then again it's quite nice to be able to build multiple binaries with
different component sets included from the tree - so I guess having some
form of run-time registration of some nice const static component
descriptions would be cool.
Anyhow - looking forward to what Matus comes up with =)
Regards,
Michael.
--
[email protected] <><, Pseudo Engineer, itinerant idiot
_______________________________________________
LibreOffice mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
