regression from 76091d81

Change-Id: I70c27cd3f72c453a1b4c2fb65b6172c8c251a741

Change-Id: Iddf82427c17a1caf72897e7af7592052c8e4fa71
Reviewed-on: https://gerrit.libreoffice.org/1541Reviewed-by: Miklos Vajna <vmiklos@suse.cz>
Tested-by: Miklos Vajna <vmiklos@suse.cz>

Change-Id: I4bcf53239f001ed2d6ea08a743257ed0d6428752

Change-Id: I89944f0a242174cc4b3c1fcf4f3f2fe744287ee3

Change-Id: I5c64d8311439430e3b21a90381ef51a1061bb0b9

Change-Id: I557cf89642ff618aaddb2f036652d126b25555c9

Change-Id: If7ab2dade60f5de62cfbea6d1d021a30e8a60f57

Change-Id: I262d479e0db7197e9afc7d8e9002862ae4f82a01

Change-Id: I7c7d0772a3d10601c6d1a9ea22c697abe762036d

Change-Id: Id0f13351108cbcd748f3c403fe7a6716145f1892

Change-Id: I59febb87f3da3098e1644087b498d9821b5d7047

Change-Id: I2bb4f00ece212fe3c4741deea0bcad50e1fd60e1

Change-Id: I1e3b9a55561f941346cb9f553f960dc2bafbb1b6

Change-Id: I3ba7009f6c44312afda6e3aaa78ca82dd6ece545

Change-Id: I17c7a42d6e401f21f04440ee14616b07bfa0068e

Change-Id: I200713987eb1c19f7d795190e7acef02af569cc8

Change-Id: I23c9d218792cd3debf30ea59c81e6687a656af31

Change-Id: Ic449e706f4a8c3c2ed06d8602c6e83755441e0da

If the clang binary comes from a package which had been built before
any of our clang related sources were changed the last time, the timestamp
would be older and so there would be no rebuild. So do the stamp handling
the usual way, clang upgrades will work fine, downgrades will not, but
that's the same problem like with downgrading a library and its headers.

To somewhat mitigate the problem (Clang plugin doesn't get cleaned by
'make clean'), include the full Clang version (which includes SVN revision)
in config_clang.h and make all Clang plugin code include that, so
at least configure re-run will trigger a rebuild if necessary.

Change-Id: I993197f79e92e36105092c92c33b2e1db343e975

Project: translations  e5f69f7b241f21f0b85f7a62ccff9de841875828

These three texts appear in Undo dropdown list, so they don't need accelerators

Change-Id: Icec8e199c7cc3990b6316937e49aacb7eb1015fb
Reviewed-on: https://gerrit.libreoffice.org/1473Reviewed-by: Ivan Timofeev <timofeev.i.s@gmail.com>
Tested-by: Ivan Timofeev <timofeev.i.s@gmail.com>

Change-Id: I5619e26e5afbe8e6532204feb60b87f6a7875ee0

Change-Id: I8233f6409d75bff23738e121efcdbd340035da9d

Get the app bundle directory from Xcode's SCRIPT_OUTPUT_FILE_0.

Copy .rdb, registry, .res files, set up the various rc files.

Don't list a bunch of .component files on the command line, surely
that is not sane.

Change-Id: I6fb8bd4bea8d5afd30900daa1b916defb894e78c

That they do is a leftover hack from before we started using the
DISABLE_DYNLOADING thing on Android, it isn't actually necessary any
more. Earlier when the UNO components were actually dynamic libraries
on Android (too, as on desktop OSes), they *had* to have names
starting with "lib" or they would be silently skipped when
packaging.

Change-Id: I11a4689f316e1ffb640a5c3110c63296d2833a84

Change-Id: Ib59f9cf7c60796fd091de64fabdd6c10a3fec5e5

Change-Id: I7259358c917ef9e7cc93d8f6886c9a935887183b

There was quite come confusion as to where Xcode wants the Run Script
phase (= our gbuild mechanism) to put the executable. I think I got it
right now. Xcode can be quite scary as soon as you do anything out of
the ordinary. (But then, what isn't.)

Change-Id: I22bbdfaef88174815bff66d6c7241f4ba2360246

Change-Id: I34e06bdb24ece278c928c6cbba8b01a38c86ff85

Change-Id: I5a29ca056af443643bfef823d0a064c5d834d24f

Change-Id: I94cea45c0e9d2890160a97d1ef198ae3f4f140d4

Change-Id: I6b1d524a7771678758c5cd8d0ef46cb03aba7655

Change-Id: I4c8edfc0ee0390d595c43e384bf6e5f595a7b84f

Change-Id: I8dc055336d1577475282198528a57efc60508cef

It used to call getenv("SAL_LOG") just once and assume it never changed.

Sure, I don't expect that LO code will start changing SAL_LOG back and forth
all the time. But it is definitely useful in our Android (and iOS) apps to be
able to call for instance putenv("SAL_LOG=+WARN+INFO") as early as possible,
before explicitly using any LO code.

That used to work earlier, but not any more with the getEnvironmentVariable()
thing, as the new logging mechanism gets called while initialising some static
globals (i.e. before out app code had even started), and that then caused the
one and only call to getenv("SAL_LOG").

This meant that we didn't get any debugging logging from SAL_INFO and friends
in the Android app(s) any more.

Change-Id: I932facff4118e5f016c95a4c1461e871184d3fc6