On Fri, 2011-06-24 at 10:45 +0100, Caolán McNamara wrote: > On Fri, 2011-06-24 at 11:36 +0200, Matúš Kukan wrote: > > Any thoughts welcomed. > > I'm a little confused as to what the goal/purpose of all the stoc > hackery and library merging is all about.
Hey - let me explain some more; (I had hoped Matus would be at the TSC to explain but ...), anyhow, for the wider benefit: * having fixed symbol names like component_doFoo means we cannot easily chop and change and move components from one library to another. => ergo adding a custom prefix="foo" and having foo_component_doFoo methods means we can move code around more easily. * this also (potentially) enables some more easy static linking of everything into one-big-lump * linking much more of our code together allows much more aggressive link-time / whole-program optimisation / inlineing etc. * hopefully with such work in-place, we can cross-compile to Windows without taking a big performance hit from gcc vs. MSVC * if we can link much more code into fewer objects, hopefully this reduces our seek cost on first-start pagein, and also starts to make code re-ordering much more useful / interesting * if we can link much more into one lump, perhaps we can kill a lot of the symbols we currently use to chain one large pile of cruft to the one next-door :-) So - Matus' work just starts that. Of course, we could do all of this by simply creating a single, big component_getFactory type method and renaming the children, and calling them as dependents from there and so on but ... that is perhaps less flexible. The question then is, which libraries should we be merging, which underlies Matus' (sadly without a .txt extension so the attachment cannot easily be viewed) 'libraries' list showing which of our libraries are loaded by all five components, and thus which could/should be merged into a single big firefox-style library [ at least that is the idea ]. Thoughts much appreciated. Clearly having them gnu-makeised as we go is rather a key win, from the perspective of being able to build the object files all in one throw in tail_build, and then link them as we see fit later (?). ATB, Michael. -- michael.me...@novell.com <><, Pseudo Engineer, itinerant idiot _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice