[Libreoffice] [GSoC] library merging

[Michael Meeks]

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