Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index



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.meeks@novell.com  <><, Pseudo Engineer, itinerant idiot


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.