same for gb_Executable_BINDIR[_FOR_BUILD] and fold
gb_Library_WORKDIR_FOR_BUILD into gb_Library_DLLDIR_FOR_BUILD (the
latter also has a workdir variant)
Change-Id: If7e4cf9aab46728182c89344546065bc33b452b4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169201
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
...as the former is more convenient for release engineering (see the discussion
in the comments at
<https://gerrit.libreoffice.org/c/core/+/162157/1#message-8d7ebbcc64a87ee8e4a073ae1a05e3b74f5a3d6a>
"Also enable --with-package-format=archive for LibreOfficeWin64.conf").
Instead of ONLINEUPDATE_MAR_OLDARCHIVE and ONLINEUPDATE_MAR_OLDMETADATA make
variables, the create-partial-info target now only needs an
ONLINEUPDATE_MAR_OLDMSI make variable.
TODO: There are two issues when comparing the content of msi files (extracted
with msiexec /a), which the old code comparing the content of archives had tried
to somewhat (but not fully) address with the metadata files that I had invented
(and now reverted): For one, msiexec /a also extracts content that would
normally be installed somewhere else in the system (e.g., it extracts Fonts,
System, and System64 directories). Differences in those directories will cause
a MAR update to create those directories in the installation directory, rather
than to update the corresponding files in their actual locations. For another,
optional components are not recognized as such, but their content must be added
to the MAR file as add/patch-if, not as plain add/patch. To work around that,
for now *all* files are added as add/patch-if, conditional on the files
themselves. Thus, addition of files will cause a MAR update to miss them.
(As they now exclusively operate on msi files, the create-update-info and
create-partial-info targets are no longer meaningful for non-Windows platforms,
so drop the non-Windows bin/update/create_full_mar_for_languages.py part.)
Change-Id: Ifb55b5e7d1a201b4f50a27cb449a634b96c2e29b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162399
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
...along the lines of what had already been done for create-update-info, passing
files to the mar executable with an -f files.txt instead of on the command line
(which could grow too long for Windows), and taking the archive metadata into
account.
For the latter, `make create-partial-info` now expects a second make variable,
ONLINEUPDATE_MAR_OLDMETADATA, in addition to ONLINEUPDATE_MAR_OLDARCHIVE. And
there is a new TODO in update/create_partial_update.py that the old and new
metadata should be compared for problematic changes. (For now, any such changes
would just get lost by an update.)
Change-Id: Ide45adedb72958fc32c5b26aa7ebb01530ccf3d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161972
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
I got lost trying to figure out how the original
bin/update/create_partial_update.py code was meant to obtain old and new
installation trees to diff, so I simplified that down to the create-partial-info
make target now expecting an ONLINEUPDATE_MAR_OLDARCHIVE make variable that
points at the old archive install set. (And the
--with-online-update-mar-serverurl configure option is gone for good again.)
The remaining changes are similar to what was needed in
28bad382fa "Fix `make create-update-info` (for
Windows, at least)". (And the mbsdiff and mar tools expect Windows-style
pathnames, but mktemp returns a Unix-style pathname in cygwin shell scripts, so
this needed an additional Windows-only external/onlineupdate/cygpath.patch.)
Change-Id: I40690210d62e3f26fb2d574914a0dd4323e6cd62
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161924
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
* The shell scripts that had once been copied from Mozilla to bin/update/*.sh
are now included in
onlineupdate-c003be8b9727672e7d30972983b375f4c200233f-2.tar.xz (which is still
generated from the same
<https://github.com/mozilla/gecko-dev/commit/c003be8b9727672e7d30972983b375f4c200233f>
that was used for the original tarball in
3a445cb497 "Turn onlineupdate into
external/onlineupdate").
* The additional modifications in external/onlineupdate/lo.patch are:
** Allowing to pass the list of files into the mar tool via -f instead of on the
command line, to avoid "command line too long" errors on Windows, inspired by
the modifications once made directly in our old downstream sources with
4165dd4e46 "add a way to create mar file from
file", 8e4d49340b "use the new file based
approach for the mar creation", and fb13ed6955
"add the manifest file to the mar file". (To keep things simple for now, it
still uses a hard-coded maximum of 10000 lines in the file, marked with a
TODO.)
** Not failing when "precomplete file is missing!" (There is a comment
// Applications aren't required to have a precomplete manifest. The mar
// generation scripts enforce the presence of a precomplete manifest.
in
workdir/UnpackedTarball/onlineupdate/onlineupdate/source/update/updater/updater.cpp
and it appears to be OK that we don't have such a precomplete manifest file
and just skip that test.)
* In the Makefile.gbuild create-update-info, the create_full_mar.py script needs
to be called with a Unix pathname on Windows, or else the
#!/usr/bin/env python3
shebang in that script would get confused.
* The related Makefile.gbuild targets upload-update-info and create-partial-info
have not been addressed yet.
Change-Id: Iab4e083ddbe99e07d846e202f20c6031e2983e1b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161656
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
(An upcoming change will add an instset/update-settings.ini file containing that
value, but using a GeneratedPackage for a single file instead of a directory
seems unsupported, so it will use the hard-coded value and a plain Package
instead.)
Change-Id: I12ffef4db71ce36be9096df674588b39c660e4de
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161545
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
...and allow each of them to be left off, for debug purposes, even if that may
render the resulting --enable-online-update-mar feature non-functional.
This change tracked each item that was potentially read from the
--with-update-config ini file, and turned each of them into a new
--with-online-update-mar-... option. The only exception and remaining TODO is
bin/update/upload_build_config.py (called from Makefile.gbuild).
distro-configs/Jenkins/LibreOfficeLinuxUpdater.conf (which might well be dead)
set --with-update-config=~/updater.ini with an ini file of unknown content. So
that no items are silently missing if we ever resurrect that distro-config, I
set all of the new options to =TODO there for now.
Change-Id: I17a13e0d190a868436bac10c1b0a6675d8c704c0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160622
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
it's usually run bypassing all the dependencies & make parsing using
LD_LIBRARY_PATH=instdir/program make cmd cmd='ALL_LANGS="$(ALL_LANGS)" workdir/LinkTarget/Executable/pocheck'
but it doesn't hurt to also have it as a dedicated target
Change-Id: I742373eb0e4d87ea22c80da0dcaaba7116cd2937
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144250
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
This allows to build a complete static LibreOffice on Linux,
except for linked externals. Since LO's static build implies
disabled dynamic loading, one must select one VCL backend to
be compiled in.
See the (large) comment in solenv/gbuild/static.mk trying to
explain, why this implementation was chosen (spoiler: seems
there is no other way) and what is actually implemented.
This will collect all libraries, statics and externals of
executables. If the executable uses components, it will get
linked to all static components. While it works with any
Executable, it just makes sense for soffice.bin, because the
static component map sucks every dependency in, bloating most
other binaries.
In theory on could generate the dependencies based on the list
of used components (see gb_CppunitTest_use_components), then
generate a specific static constructor map, directly include it
in the exe's cxx code and then link the minimal dependencies.
The static LO should build on Linux with:
--enable-customtarget-components
--disable-dynamic-loading
Tested VCL plugin config is:
--disable-gtk3
--disable-gen
--enable-qt5
The partial build support is split into a 2nd patch.
Change-Id: Iafc95752fae9e88095f54a21f1e30a4f080815e2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126790
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
...instead of by listing the content somewhat redundantly in the Rdb_*.mk
files, to avoid duplication of logic for components that are only built
conditionally (and thus should only be included conditionally in the
corresponding Rdb). To achieve that, add an "rdb" parameter to
gb_ComponentTarget_ComponentTarget (and to the gb_*_set_componentfile macros
that internally call gb_ComponentTarget_ComponentTarget), which is used to make
the appropriate gb_Rdb_add_component call internally from within
gb_ComponentTarget_ComponentTarget. (As a special case,
gb_CppunitTest_set_componentfile shall not call gb_Rdb_add_component, as that
has already been done by the corresponding gb_Library_set_componentfile call, so
allow the gb_ComponentTarget_ComponentTarget "rdb" parameter to be empty to
support that special case.)
Most Rdb_*.mk files are thus mostly empty now. One exception is
i18npool/Rdb_saxparser.mk, which duplicates some of the Rdb_services content as
needed during the build in CustomTarget_i18npool/localedata.
1c9a40299d "gbuild: create services.rdb from built
components" had already tried to do something similar (in addition to other
things) under a new --enable-services-rdb-from-build option. However, that
approach had four drawbacks that this approach here addresses (and which thus
partly reverts 1c9a40299d):
1 Rdb_services shall not contain the component files of all libraries that are
built. While that commit filtered out the component files that go into
Rdb_ure/services (ure/Rdb_ure.mk), it failed to filter out the component files
that go into others like Rdb_postgresql-sdbc
(connectivity/Rdb_postgresql-sdbc.mk).
2 The code added by that commit to Makefile.gbuild codified the knowledge that
there is an Rdb_services, which is brittle.
3 The code added by that commit to solenv/gbuild/Rdb.mk codified the knowledge
(for gb_Rdb__URECOMPONENTS) that there is an Rdb_ure/services, which is brittle.
4 Introducing an --enable-services-rdb-from-build option needlessly provided
two different ways how the content of Rdb_services is assembled.
The changes done here would leave --enable-services-rdb-from-build as a
misnomer, as it no longer controls how Rdb_services is assembled. I thus
renamed it to --enable-customtarget-components, as that is apparently what it
still does now.
Change-Id: Ia5e8df4b640146c77421fcec6daa11a9cd260265
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126577
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
... and introduce the --enable-services-rdb-from-build option.
Currently the build handles global build options redundant
in a few places:
* in Repository*mk + modules - the "real" build dependencies
* the full services.rdb generation
* the static UNO constructor map generation
Also the component files don't reflect the really built components
and so the RDB services generation must handle the whole options
to select the correct components.
So this optionally replaces the latter two by generating the list
of components and it's constructors from the build itself. As a
consequence, component files must now be split, so they reflect
the real components in the libraries, otherwise the static
constructor list will have missing symbols. IMHO this is more
natural, as it happens in the same place already handling these
build options for the sourcecode.
This also adds a convenience helper to add multiple component
files: gb_Library_set_componentfiles
This is WIP and currently just works for the stripped WASM build,
which introduces many more split component files in later patches.
It also explicitly filters the gb_Rdb__URECOMPONENTS and the
CppunitTest related components from the services.rdb. Maybe there
is a good way to do this properly.
Change-Id: I1b38a6f2c1e5221f18d7e5e756c30263b555d962
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126185
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
This is a hack, because make has no way to serialize processing
of a target (just .NOTPARALLEL for the whole Makefile).
It uses the lockfile tool / liblockfile 1.17. Since that polls
the file, I adjusted the poll timeout to 5s max, because I found
the 60s wait much too long. Guess even 1s would be ok...
Since it's just a small build tool, I simply copied and patched
its source, instead of creating an external project. And there
is --with-system-lockfile=... to use an external binary instead.
Change-Id: I16bc4579a273dcf1aac811ae4723ca325a0b9eba
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126152
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
The revert commits change the build-tools target for a DESKTOP
build to build the complete LO. This restores the original,
minimal one and also adds a whitelist of allowd build types.
OpenCL needs a configure switch, as it's status is also stored
in a config header, so preventing the build is not enough.
This also reverts:
- commit 802161a505
- commit 02d931a59e
Change-Id: Ibfcb0c54e72da1b7c2e63c082ea6586520a787fa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102480
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
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>
Without the MAR env setting the python script only gets two command line
arguments, the script name and all the parameters as one string.
If someone knows a better fix I'm open to other suggestions.
Change-Id: I1acc4a74892d657c1c156b8953a5ab8a166aea92
Reviewed-on: https://gerrit.libreoffice.org/40778
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
It seems that the generated partial update files are now generated
correctly. We now need to handle languages and sign the partial files as
well as upload them.
Change-Id: I69fbdad42da2c8a2d9695bc852956b82ce773f4c
We still need some parts for the partial update files but we already
generate the build information and the complete mar file.
Change-Id: I2ae0de0b83518bc3093848b66b6f3054ebd388e1
It is constant and can just be replaced by $(SRCDIR)/solenv.
Use BUILD_TYPE where it was used to check if config_*.mk is sourced.
Change-Id: Ib9d480c57194b6340093aa47776f8768df69b7d1
Well, there is still another one: solenv/gbuild/partial_build.mk
This enables you to do in SRCDIR:
make gb_Side=build -r -f Makefile.gbuild <target>
which was not possible previously.
Change-Id: I6f8ce1c6503124526986e192b7d3552b909fc157
Christian Lohmaier