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

Project: dictionaries  a84489515d2207b1c34646be7d6f532b84a37439

Change-Id: I14e851a74955ff4053026e7fb664759cbf24c86a

Change-Id: If855e5fafb8f1291d69d5e50fdaa9ef165071293

Change-Id: Ide96d7f052ee4c8f56b33629ae48c6425a8ca19f

This reverts commit 119483d9b0af6b4830733161fcf56cea10ed01d7.

Change-Id: I715975dfa93d736cb537076feab4afe6b75c162a

No idea how to reproduce it; pSwView is checked before use except here.
(possibly regression from 2f9f480b)

Change-Id: Ia7667e879a6944e084a45c06133efc1ac2d8b3c0

Change-Id: Ic563204c1a1a64d315e3e73dff30b6a6d05cfd87