Instead of introducing a global variable, use the already existing
saved android_app pointer in lo-bootstrap.c, and just add a function
to rettrieve that.
Reanme osl/detail/android.h back to android_native_app_glue.h, which
is the file from NDK/sources that it is. "android.h" sounded to me too
grand, as if it was some universal Android header. But if we do start
to modify the android_native_app_glue stuff heavily, then it indeed
makes sense to call it something else. Until then, revert also some
whitespace changes to android_native_app_glue.c for it to be as close
as possible to the "upstream" one in the NDK, for clarity.
The script needs %TEMP% to be set in order to work properly.
Cygwin unsets TEMP which causes WiLangId.vbs to fail. Set the
TEMP variable to $TMPDIR before we call the cscript.exe.
Unfortunately msiinfo.exe has a limitation, it truncates Language
property in Summary Information at char position 254.
The replacement, WiLangId.vbs does not have this limitation.
Fixes the problem in offapi, where a rebuild after changing an IDL file
would produce an offapi.rdb that contained the stale content of the
old version of the IDL file. This was because in offapi 2 rdb files are
built, offapi.rdb and types.rdb, and types.rdb is a merge of udkapi.rdb
and offapi.rdb, hence it depends on offapi.rdb. Unfortunately this means
that the UNOAPI_MERGE variable for types.rdb is inherited to
offapi.rdb, with the result that after the workdir offapi.rdb is built
from .urd files, it is overwritten by a merge of udkapi.rdb and a stale
offapi.rdb from the solver.
Motivation behind this is to fix processing of idl files.
When LibO directory is toplevel disk directory, there are
two // in the path which could be the reason idlc fails.
This should fix the bug, probably introduced with the per-directory
performance enhancements, that after a change to an IDL file 2 builds
are required to rebuild everything.
Reverted
80f60ef540528ec5304b9fb9624a7ff1b077f108
cf1f87948bcf9b8edf8487fa7938a928cfed8f2f
as also MinGW bails out. Don't add yet more quirks, keep in mind the faulty
behavior and hope for the best until solved.
At least with gcc 4.6.2 the situation was that if /usr/include was missing
from the -I... includes, header files were pulled from /usr/include/
instead of solver/$INPATH/inc/external/
This clearly makes a difference for not --with-system-... libs where the
internal version is to be used.
