[PUSHED] x11 / cairo-less build try #3

[Michael Meeks]

Hi Riccardo,

On Wed, 2012-02-15 at 17:55 +0100, Riccardo Magliocchetti wrote:
> this is another update on building libreoffice without need to link
> against X11 or toolkits in general. The aim is to ease the deploy
> server side where less dependencies needed the better.

	Great :-) so - I got tired of seeing such a big patch, and pushed most
of it to master - I hope that's allright. I removed the unit test
disabling stuff.

> As you can see the vcl/headless/headlessinst.cxx has been shamelessly
> copied from Android, you can see still some #if 0-ed code because i'd
> like to have soffice.bin run without crashing to assure myself that the
> code is not needed :)

	Fair enough. I suspect that for the native-dialog implementation in
headlessinst.cxx we want to go for an fprintf with some parse-able
syntax to the console, and then return.

> The salplug changes probably are not needed anymore, the #if 0 in
> tests are asserts that does not look regressions i've introduced.

	Ah yes - quite right; it'd be nice if you can revert them in your next
patch.

> Michael i've not forgot about cleaning up Library_vcl.mk :)

	I got annoyed by that and fixed it myself on master ;-) it seems to
work, though ideally we'd share more from Library_vcl.mk with the other
backends eg. the gtk3 one.

> Now that everything builds at runtime it fails at runtime, looking
> around cli_ure/source/climaker/climaker_app.cxx:476 does not show something obvious, any hint?

	Um; cli_ure shouldn't fail - it is some random mono / .net stuff that
shouldn't be on the startup path.

> $ ./soffice.bin 
> terminate called after throwing an instance of 'com::sun::star::loader::CannotActivateFactoryException'
> Aborted (core dumped)
...

	Nice - IMHO this is all a bit silly - the 'main' has no wrapper 'catch'
around it, so if we get an un-caught exception we bomb out in a very
unpleasant way for no particularly good reason.

	If you poke at desktop/source/app/sofficemain.cxx you'll see some
#ifdef ANDROID-ness that adds a try / catch around 'main'. In theory
there is an unoexceptionwrapper that can be put around this stuff with
some magic, but ...

	Stephan - is there a reason why we would not catch and print something
helpful (a native dialog?) on unhandled exceptions around master ? 

	Hopefully that'll show you which shared library or random other
component registration that you're missing [ though you really don't
want the setIniFilename piece there ].

	Does that help ?

	Thanks !

		Michael.

-- 
michael.meeks at suse.com  <><, Pseudo Engineer, itinerant idiot