Whatever workflow it was used for back in the days does probably not
exist any longer.
Change-Id: I4e29e1acde2a630e461d43b3f4b2b7fa6abd5031
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/198538
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@iki.fi>
When not using a system Python, set PYTHON_FOR_BUILD to point to the
python script in the instdir_for_build/program folder. Make sure that
script gets installed by adding it to gb_BUILD_TOOLS_executables and
by adding pyuno to the cross_toolset modules. Make also the
SYSTEM_PYTHON boolean flag visible to the cross-build (in the normal
way, as SYSTEM_PYTHON_FOR_BUILD).
When cross-compiling Python to Linux, pass some ac_cv_* settings that
can't be determined at compile time.
Change-Id: I5224966698dca03df9545f5552671f0dce00b4ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197540
Reviewed-by: Tor Lillqvist <tml@iki.fi>
Tested-by: Jenkins
Instead of passing them in the environment. Works better for
cross-compilation at least from Linux to Linux.
Change-Id: I46345f270fdcccd0a37370b63c1363281efc5607
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197539
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
It won't even be attempted, make will complain:
.../solenv/gbuild/ComponentTarget.mk:81: *** No LIBFILENAME set at component target: .../workdir/ComponentTarget/connectivity/source/drivers/mysqlc/mysqlc.component. Stop.
Change-Id: I7be5953fb40bfc2034ed4ddf348e1c5e68a85b19
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197256
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@iki.fi>
The problem was caused by my remote font downloading changes. We need
to be more careful in lo_initialize() and libreofficekit_hook_2() to
distinguish whether the code is called from "normal" Online (with
"pre-initialisation" through lok_preinit_2()) or otherwise, for
instance the iOS app, where not pre-initialisation is done.
Sadly, this fix makes state handling in init.cxx even more complex
with one more static Boolean flag.
Change-Id: I2a8fa96740eb79725aa162cf7adc86d49a8ba603
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133175
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133196
Tested-by: Jenkins
Try to make the code more like in the co-2021 branch, where copy/paste
between Collabora Office and other iOS apps currently works again, in
both directions, both for text and images. Sadly something is broken
or missing either here in core or in online as it doesn't fully work
in a Collabora Office based on the master branch of core, even after
this commit, though.
We use only the system clipboard on iOS. (It is actually called the
"pasteboard" in Apple's operating systems.) The code to interface with
the system clipboard is in vcl. It has worked fine to copy and paste
between the Collabora Office iOS app and other iOS apps without any
LOKClipboard being involved. If LOKClipboard is used it doesn't work
at all.
Change-Id: I0d3b4e3eabe17b633390e071701225e1d356a75a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128037
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
If you want to keep the string to floating point conversion semantics
in BASIC as they were in LibreOffice 6, you can either set the
LIBREOFFICE6FLOATINGPOINTMODE environment variable to some non-empty
value, or set the org.openoffice.Office.Scripting/Basic/Compatibility/
UseLibreOffice6FloatingPointConversion flag in the Expert
Configuration. (Or use a registry modification file with that effect.)
Adapt the relevant unit test accordingly. Thanks to Mike Kaganski for
showing how to access the setting in the LibreOffice registry from
Basic.
Change-Id: I13d6d5d834e1bb81ef8df489db2b1da79f01dfc5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125756
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Use NSLog() and not just SAL_WARN(). There are so many irrelevant
SAL_WARN() warnings displayed that these ones that can be extremely
relevant are easily missed. I typically run the app in Xcode with
SAL_LOG=-WARN.
(Such warnings are typically caused by something missing from the
solenv/bin/native-code.py.)
Change-Id: I4ab16f4f652ac34319021c9427e2e9f911ee29e4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122721
Tested-by: Tor Lillqvist <tml@collabora.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122756
Tested-by: Jenkins
The system German dictionary accepts 'ß' which is not used in Swiss
Standard German but completely replaced with 'ss'. We assume that the
LibreOffice German dictionary is installed, too. It has correct
spelling for de_CH.
It would be good if we knew in the macosxspell code whether the
LibreOffice German dictionary installed, and act correspondingly. But
figuring that out seems more complicated than what I am willing to
spend on this for now.
Change-Id: I380d7734cea34a2408d9ed20a8c3d9efe6a8fea2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115690
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
There were a couple of weird things in this script. Firstly, the
script redirected stdout and stderr from each invocation of codesign
separately into a log file. (Several differently named log files.) But
those log files were never displayed.
Secondly, the script did "set -e" at the start. Thus, if a codesign
invocation returned non-zero (error) exit status, any code to check
the exit status and possibly display the log file would not be
executed anyway.
Simplify thusly:
Don't pass --verbose to codesign. Then if nothing goes wrong, it is
silent. That is The Unix Philosophy, right?
Don't redirect codesign stdout and stderr to a log file (that would be
removed if codesign didn't fail). Just let any error message of
warning from codesign go to the script's stderr or stdout.
If codesign fails, just exit. Error messages will have been written to
stderr already. No log files to display or remove.
Don't use set -e. Instead if a codesign invocation fails, just exit.
The intent is that in the normal case, this script will be totally
silent.
Change-Id: Ic6081c418e4c564be768e30bf52b8196ee59f061
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109696
Tested-by: Tor Lillqvist <tml@collabora.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
I think the attempt to set CPU_ARCH in
external/nss/ExternalProject_nss.mk does not actually work. And
anyway, it should be arm64 for macOS on arm64, not aarch64.
Now NSS configury correctly finds the APIs present in the system when
building for macOS on arm64. Previously, it attempted to compile the
test snippets for PowerPC... which caused for instance dladdr() not to
be found, which caused the softokn3 loading to fail.
(It's somewhat surprising that the NSS configury still has "support"
for MacOS on PowerPC... Do people really build latest and greatest NSS
on such machines? Or is it just a leftover and the NSS people never,
ever, remove anything?)
Change-Id: I0dc35df0460db7997efcfdf92594fd8ae352aa49
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107316
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Note that what osx/README says still holds. This Xcode project is for
making debugging easier only.
Change-Id: I8ebbad2a2de5366616ad7304125bdd05ae001489
There is no reason to not mention the NSOpenSavePanelDelegate protocol
that AquaFilePickerDelegate implements.
The way we used objc_msgSend() caused a crash or hang. (I saw both,
depending on whether the code was built for debugging or not). For
some reason we used to cast it to a function with variadic parameters
like:
reinterpret_cast<id (*)(id, SEL, ...)>(objc_msgSend)(
m_pDialog, @selector(setDelegate:), m_pDelegate);
This does not work in arm64 code on macOS. (See
https://developer.apple.com/documentation/apple_silicon/addressing_architectural_differences_in_your_macos_code?language=objc
, the "Don't Redeclare a Function to Have Variable Parameters"
section.)
We could have replaced the ellipsis with the actual type of the first
real parameter in this call, or just "id" would have worked fine. But
it is much simpler to just do what we mean directly:
[m_pDialog setDelegate:m_pDelegate];
I need to look through the code for other places where we have used
objc_msgSend() in a similar fashion.
Change-Id: Ia93b2007ed8f263eaf99d604a3c88e857efbb421
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107257
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Must set RAW_DEVICES_FLG=N for this architecture, too. Make the
prefix.darwin_arm64 match the x86_64 one. Don't bother defining ARM64,
just check for __aarch64__.
Change-Id: I9de67493cb159ce97a46cdd1974b04753518c703
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106716
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
There is no /usr/lib/libz.dylib any longer in macOS 11.
No idea whether it works (especially on arm64), but that is another
issue.
Change-Id: I92ac0c500388730eca0be4766f07b1af2d2808e0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105897
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Restore the old CFLAGS (etc) as soon as possible. Always use the same
variable names for the saved values.
Change-Id: I523bbf66ec5400d24993b7e11e444bb63d61751e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105130
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
INCLUDE is not exported from WSL to Win32 programs without including
it in the list of environment variable names in the WSLENV environment
variable, and I think we want to minimize the number that need to be
mentioned there.
Should not affect Cygwin builds.
Change-Id: I0af480873badac446305e396b69eec360eb8a270
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105098
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Trying to fine-tune that exactly what is needed but nothing else is
built is very painful.
For instance, on macOS, if you build gengal but not soffice, you end
up with this error when trying to run the built gengal, because there
is no Info.plist in the app bundle in instdir_for_build: "No
Info.plist file in application bundle or no NSPrincipalClass in the
Info.plist file, exiting"
Change-Id: I63d766f0e7e72f55454d16c72c32e153cf976443
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98177
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Sadly the existing arm64 assembler files in OpenSSL use a syntax that
Apple's clang doesn't accept.
And yeah, ideally we should not use either NSS or OpenSSL on macOS,
but native APIs for the functionality in question. Trying to make
everything look like Linux is a bone-headed approach.
Change-Id: Ib3f137ac73329b92e82c654d1277ee21f5f81b37
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98095
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Just for completeness. Did not check whether we actually could build
OpenSSL for iOS. As we have managed without so far there probably is
no need.
Change-Id: Icd41622e7336e723ccd5a3157e956c43f6f92a76
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98011
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
It's used not just for iOS but can be macOS too.
Also, nss wants to call it CPU_ARCH=aarch64.
Change-Id: I6398c3bf1409f2ccf16b0d154ad7c2b56f493b15
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97986
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
If cross-compiling to a DESKTOP platform, just use
RepositoryModule_host.mk on the build platform, too.
Change-Id: Icd3f3081e5af0c7cda95e9bce7572d37567d4f6e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97356
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Don't use $host_os="darwin" for both macOS and iOS depending on
$host_cpu. Soon macOS will run on either x86_64 or arm64. Instead, use "darwin"
(or "macos") for macOS and "ios" for iOS.
Some other early changes for arm64-apple-macos, too.
Change-Id: Id89987d854ceba2cd87c6222db2081ccdec0c73e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96976
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Experimental. Let's see whether it makes sense to not use Java when
building the LO core for the (newer, Online-based) Android app.
Change-Id: I119861704d02bbfaa0cfd9f72c7b437f1730e48e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95847
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
If you run gtktiledviewer so that it opens a spreadsheet and a text
document these assertions would fire.
In each case the assertion is followed by code that just returns if
the asserted condition doesn't hold, so it is unlikely that this
change will break anything.
There sure will be a lot of further changes needed to make such a use
case work. (For starters, editing either of the two documents does not
work.) But let's do it step by step.
Change-Id: I4063dbbcac7c77b57e1f4cb3f05bd5096c08c0fe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95037
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
We want it to be possible to compile an arbitrary subset of the source
files for debugging. DBG_UTIL, on the other hand, has to be consistent
across the whole build. We should not use OSL_DEBUG_LEVEL to switch
(internal) API on/off.
Change-Id: Ia5111a36326ad7ad4c72d9e8f7ad88c8dbe8e272
Reviewed-on: https://gerrit.libreoffice.org/72616
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Will handle it another way instead that isn't so visible and annoying.
This reverts commit 5f0dda8e9f.
This reverts commit 4f1a341bc3.
Change-Id: If456d2792a5f2793ee6337898aaa4a55637f8522
In a sandboxed environment we don't want to attempt to create
temporary files in the same directory where the user has selected an
output file to be stored. The sandboxed process has permission only to
create the specifically named output file that the user chose in the
system file dialog in that directory.
Change-Id: I65274b4c433bd66b436429bea4b287a0505b72c9
That makes it much easier to use the same Xcode project file when
building against different versions of LibreOffice, with different ICU
data files. The configure script in the "online" directory creates a
ICU.dat symlink to the ICU data file (with a name like icudt60l.dat in
a 6.0 branch, or icudt63l.dat in a current master) in the LibreOffice
build directory, and that is what gets copied into the app bundle.
Change-Id: Ibe2ca85f66e2d4973d6ba3c52fc4d60e113d8f9a
Also, I don't see why we would want to use -miphoneos-version-min=12.0
just because we build against the 12.0 SDK. Use 11.0 as the minimum
runtime iOS version for now.
Change-Id: I36b9696ce367249e7e8d0a51ee61791e32972390
It seems that on iOS, where we don't have any Java, Python, BASIC, or
other scripting, the only thing that would use the C++/UNO bridge
functionality that invokes codeSnippet() was cppu::throwException().
codeSnippet() is part of what corresponds to the code that uses
run-time-generated machine code on other platforms. We can't generate
code at run-time on iOS, that has been known forever. Instead we have
used some manually written assembler to handle it instead. We used to
have a Perl script to generate a set of code snippets for different
cases, different numbers of parameters of the called function and
whatnot, but that went away at some stage some year ago. (It is
unclear whether that broke the C++/UNO bridge on iOS, or whether the
stuff continued to work even after that.)
Anyway, this handwritten assembly, or the manual construction of
internal data structures for exceptions, or something else, seemed to
have bit-rotten. Exceptions thrown with cppu::throwException() were
not catchable properly any longer.
Instead of digging in and trying to understand what is wrong, I chose
another solution. It turns out that the number of types of exception
objects thrown by cppu::throwException() is fairly small. During
startup of the LibreOffice code, and loading of an .odt document, only
one kind of exception is thrown this way... (The lovely
css::ucb:InteractiveAugmentedIOException.)
So we can simply have code that checks what the type of object being
thrown is, and explicitgly throws such an object then with a normal
C++ throw statement. Seems to work.
Sadly the cppu::getCaughtException() API still needs some inline
assembly in the C++/UNO brige. That seems to work though, knock on
wood.
This commit also adds a small "unit test" for iOS, copied from
cppuhelperm to ImplSVMain(). Ideally we should not copy code around of
course, but have a separate unit test app for iOS that would somehow
include relevant unit tests from source files all over the place.
Later.
Change-Id: Ib6d9d5b6fb8cc684ec15c97a312ca2f720e87069
Reviewed-on: https://gerrit.libreoffice.org/60506
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
We used to have this code snippet in the TiledLibreOffice app back in
the days. Then in LibreOfficeLight it was lost and forgotten (?).
Clearly we need to tell ICU abouyt the data that we include as a
separate file in iOS apps, and presumably any iOS app will be a
LibreOffficeKit-based one, so let's do the initialistion here.
Change-Id: Ib08dc9d7386789d10e8c53114e79d0b5beab7232
(To be used from Xcode projects elsewhere building iOS apps that want
to link to iOS code built here.)
Change-Id: I39bf2a4ed059930fcfc30c4d2016dfbc698da353
No reason for SalGraphics::getSystemDependentDataManager() to be inside
the #if HAVE_FEATURE_OPENGL. Fixes build for iOS.
Change-Id: I3d8174a4841d793f8d7ea2c3ebf3be2888229a3e
This doesn't make the LibreOfficeLight app work much better, though.
But at least it doesn't hang its event loop completely, some 10 s
timer keeps firing. (But nothing sane shows up in the app UI, even if
some welcome.odt document apparently does get loaded. Clearly
something is waiting for something else that never happens...)
Change-Id: Ieba22a5e1418d48a7dd6cacda526aca69cced4c3
As such I am not convinced that this "dummy" replacement class
approach is the right thing; we don't do it like that elsewhere
either?
Change-Id: Ife912d9ed91bd26610ea40cf4b446beb2ed481ec
Tor Lillqvist