office-gobmx/distro-configs/LibreOfficeFlatpak.conf

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

68 lines
1.7 KiB
Text
Raw Normal View History

--disable-odk
--enable-release-build
--with-ant-home=/run/build/libreoffice/ant
--with-extra-buildid=Flatpak
Enable --help=html for flatpak To not increase the size of the main org.libreoffice.LibreOffice app further, the plan was to realize this as an org.libreoffice.LibreOffice.Help extension. Ideally, this would be a localized extension, so that, by default, only a relevant subset of the extension would be downloaded and installed. (But see below.) There are multiple technical problems, as discussed at <https://github.com/ flathub/org.libreoffice.LibreOffice/issues/35#issuecomment-447295308> "Add integrated LibreOffice Help offline": * LO can't pass a file URL with query part to xdg-open, so uses a temporary wrapper .html file that redirects to the target URL. But for the flatpak case this wrapper can't be in /tmp (which isn't visible from outside the flatpak sandbox), but is instead stored in a new temp dir under $XDG_CACHE_HOME (which is always set for flatpaks and /is/ visible form the outside) that is removed on LO exit. * The file URL stored in the temp file must be rewritten from the internal path (/app/libreoffice/help/...) to the path as seen outside the flatpak sandbox. While the path for the org.libreoffice.LibreOffice /app is stored in /.flatpak-info, the external path for the org.libreoffice.LibreOffice.Help extension is different and not stored there. So use a hack trying to construct that path from what information is available in /.flatpak-info. * But the help content consists of locale-specific and shared files, and those reference each other with relative links. But a localized flatpak extension cannot contain shared files, it can only contain per-language sub-dirs. And if the shared help files were kept out of the extension, as part of the app itself, the relative paths among these files inside the flatpak sandbox would differ from those outside of it, so would be broken when viewing the content in the external browser. A solution would either (a) need to somehow rewrite the content of all the help files being served from LO to the external browser, or (b) replicate the shared help files in all the extension's per- language sub-dirs (and if some localization uses en-US content as a fallback for only part of its translated content, e.g., in the case of media files, would need to also replicate that en-US content), or (c) use a non-localized extension that always contains the content for all localizations. For now, I chose the third approach. This makes the org.libreoffice.LibreOffice.Help extension relatively large (the current /app/libreoffice/help tree has a size of ca. 100MB), so that I decided to not have it downloaded and installed automatically ("no-autodownload": true in solenv/flatpak-manifest.in). (I checked with Flatpak 1.0.6 that if the extension should be changed to a localized one with the same name in the future, updating from an older version would work. If the old extension was not installed, just the relevant localizations of the new version will be downloaded and installed. If the old extension was installed, the full set of localizations of the new version will be downloaded and installed.) (As also mentioned at <https://github.com/flathub/org.libreoffice.LibreOffice/ issues/35#issuecomment-447295308>: "A second, minor, nuisance is that, for security reasons, an `xdg-open file:///...html` call from a flatpak leads to an intermediate popup dialog letting the user chose which application to use to open the URI, while e.g. an `xdg-open http:///...html` is allowed to go directly to the user's preferred browser. So accessing help content from LO flatpak would present that popup dialog first, forcing the user to select a browser to proceed.") Change-Id: I35f5a23947dd551dc1b9bff1dd2abd6710073b5f Reviewed-on: https://gerrit.libreoffice.org/65451 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-12-12 10:13:03 -06:00
--with-help=html
--with-jdk-home=/usr/lib/sdk/openjdk21/jvm/openjdk-21
--with-lang=ALL
--with-system-libs
--with-vendor=The Document Foundation
--without-export-validation
--without-junit
--without-lxml
--without-system-abseil
--without-system-argon2
--without-system-beanshell
--without-system-bluez
--without-system-boost
--without-system-box2d
--without-system-clucene
--without-system-coinmp
--without-system-cppunit
--without-system-dragonbox
--without-system-firebird
--without-system-frozen
--without-system-glm
--without-system-gpgmepp
--without-system-jfreereport
--without-system-libabw
--without-system-libatomic_ops
--without-system-libcdr
--without-system-libcmis
--without-system-libebook
--without-system-libepubgen
--without-system-libetonyek
--without-system-libexttextcat
--without-system-libfixmath
--without-system-libfreehand
--without-system-liblangtag
--without-system-libmspub
--without-system-libmwaw
--without-system-libnumbertext
--without-system-libodfgen
--without-system-libpagemaker
2024-01-15 09:00:53 -06:00
--without-system-libpng
--without-system-libqxp
--without-system-librevenge
--without-system-libstaroffice
--without-system-libtommath
--without-system-libvisio
--without-system-libwpd
--without-system-libwpg
--without-system-libwps
--without-system-libzmf
--without-system-lpsolve
--without-system-mariadb
--without-system-mdds
--without-system-odbc
--without-system-openldap
--without-system-orcus
--without-system-poppler
--without-system-postgresql
--without-system-redland
--without-system-rhino
--without-system-sane
--without-system-xmlsec
--without-system-zxcvbn
--without-system-zxing