Annoyingly the packinfo_*.txt don't support conditionals but we can
work-around that with a little duplication.
Change-Id: Id00a6831effcc63a917fc21d2cd201474fdb559d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109569
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
In OOo times, there'd originally been efforts to allow building on Windows with
MinGW. Later, in LO times, this has been shifted to an attempt of cross-
compiling for Windows on Linux. That attempt can be considered abandoned, and
the relevant code rotting.
Due to this heritage, there are now three kinds of MinGW-specific code in LO:
* Code from the original OOo native Windows effort that is no longer relevant
for the LO cross-compilation effort, but has never been removed properly.
* Code from the original OOo native Windows effort that is re-purposed for the
LO cross-compilation effort.
* Code that has been added specifially for the LO cross-compilation effort.
All three kinds of code are removed.
(An unrelated, remaining use of MinGW is for --enable-build-unowinreg, utilizing
--with-mingw-cross-compiler, MINGWCXX, and MINGWSTRIP.)
Change-Id: I49daad8669b4cbe49fa923050c4a4a6ff7dda568
Reviewed-on: https://gerrit.libreoffice.org/34127
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...that were erroneously removed with 6492c8576e
"Make the 'Mac-like' or 'canonical' app bundle structure always used on OS X":
* gengal script (ultimately calling gengal.bin); this script still needs
adaption to the new LibreOffice.app layout, though!
* python script (ultimately calling Python.app)
* unoinfo script
* unopkg symlink to unopkg.bin (which could be dropped for Mac by renaming
unopkg.bin to just unopkg, similarly to soffice/soffice.bin)
Change-Id: Ic3eb340a183388939b1c812faf7fb509c9f53a8a
In other words, only executable files go in the MacOS folder. Dynamic
libraries and bundled frameworks (i.e., LibreOfficePython), and
nothing else, go in the Frameworks folder, and all other files go in
the Resources folder.
Especially, note that Java class files and rc (.ini) files also go in
Resources.
Such an app bundle structure is what Apple strongly suggests one
should use, and it has been hinted that future versions of code
signing and/or Gatekeeper will require such a structure.
There is still some ugliness thanks to traces of the historical
separation of URE from "the office". Like there are two separate
"unorc" files, one for URE, one for the LibreOffice application. IMHO,
this should be cleaned up, but is probably controversial.
(Eek! I now see there are actually *three* unorc files in the app
bundle. Not intentional. Need to fix that later.)
Change-Id: Idcf235038deb5b8e1d061734993e9f31869b7606
The new code signing is more strict and enforces bundle structure
harder, it seems.
When ENABLE_MACOSX_MACLIKE_APP_STRUCTURE bypass the unoinfo and python
shell scripts. If they actually are needed, will have to put them
somewhere under Resources.
Change-Id: I14a34936b78195746d2b88d25603952ce5309380
INSTDIR has everything that will be installed anyway, so ideally the
file search patch should only be INSTDIR + whatever is needed to get the
Package file lists; especially WORKDIR seems inappropriate there.
The exception is extension .oxt files which apparently are not in
INSTDIR; not sure what to do about those.
Change-Id: I2477c25ab9fcf953fae9c219e76c467e14729cda
Lots of stuff still either ended up in the wrong place, or was looked up from
the wrong place, or both. Fix most cases.
Change-Id: I06ebbce207c219f3cd82b4387dd9b3fdb83420d4
Change all instances of hardcoded "program", "share" etc subfolder names to
use those from <config_folders.h> instead. In normal builds, the end result
will not change.
Change-Id: I91c95cd8e482818be67307e889ae6df887763f53
...this e.g. changes the error message when trying to register an extension that
contains an (actively registered) Python component but no pyuno is installed
from "Binary URP bridge disposed during call" to a less frightening "The service
com.sun.star.loader.Python cannot be instantiated."
Change-Id: I10f2b36b11395559ee95ce659878222b5ea99c11
- python3: deliver files to INSTDIR, with same layout as instset
and do not deliver .lib files
- pyuno: remove obsolete python.bin targets
- pyuno: remove usage of CustomTarget_zip for WNT and non-Mac UNX
platforms (sadly it is apparently still needed for "system" python on
MinGW)
- scp2: use the python3 filelist
There is still a problem here because the installer does not currently
allow to preserve the executable bit on files in a filelist
- RepositoryExternal: run python executable from INSTDIR
and link against libraries in UnpackedTarball dir
Change-Id: I931ca0a8be6ff40051b1ca50da1f0770e6057832
Reviewed-on: https://gerrit.libreoffice.org/3525
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Add patches and/or tweaks to the following modules:
curl, cppunit, icu, lcms2, libxml2, libxslt, libxmlsec,
lpsolve, nss, openssl, python3
lcms2 has an inconsistency where the .lib and the .dll don't agree on
the .dll name.
openssl gets a honorable mention because apparently it's undocumented
custom build system can build with /MDd if one picks the right
configuration but i couldn't figure out how to do that in an hour of
trying, and just patched the release config instead.
Change-Id: I7854a0fc85247e398d561b4f513d09fe2d1ebb3c
Removes:
* instsetoo_native/util/update.xml
- gen_update_info.pl can be removed ?
On Windows the binary artifacts are created now in:
workdir/*/installation/LibreOffice_Dev/native/install/en-US/*.msi
Change-Id: I1c82ea9cb9d297cdd0e4f4b9b44606259eeeed49
Reviewed-on: https://gerrit.libreoffice.org/2242
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: David Ostrovsky <David.Ostrovsky@gmx.de>
Tested-by: David Ostrovsky <David.Ostrovsky@gmx.de>
Michael Stahl