There is no simple "Windows is 10 or newer" check in MSI, with the
Microsoft policy of "you don't need to know real Windows version".
See also https://developercommunity.visualstudio.com/t/detect-a-windows-version-from-msi/412198
The values that MSI sees (e.g. on my Win11) are:
Property(C): VersionNT = 603
Property(C): VersionNT64 = 603
Property(C): WindowsBuild = 9600
So those can't be used for the check. I use the WINMAJORVER that is
read from registry (Software\Microsoft\Windows NT\CurrentVersion).
There is no more need to check and install UCRT; it was dropped.
Change-Id: Ic02d6aeb965e9684bafd4357f969980f77000e73
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/178049
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
...and just unused dummies since 3.1.58, so don't install them for >= 3.1.58,
even if the dummies would still be available for < 3.1.68
Change-Id: Ida55be2fa3b75982bfd764b7b2676e63c092fe79
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175822
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
...as for the by-default --enable-qt5 case we generate an additional
qt_soffice.html anyway (and for a --disable-gui --disable-qt5 build, client code
probably wants to embed the results into its own HTML document and wouldn't rely
on an soffice.html); this simplifies the build infrastructure a little
Change-Id: Ib50799b5dd2fcfeb680f257f46ff65775dcddd71
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174725
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
This commit adds Package targets for the net_basetypes, net_uretypes
and net_oootypes libraries to install them into instdir/program/dotnet.
Also adds a LIBO_SHARE_DOTNET_FOLDER variable mirroring the
LIBO_SHARE_JAVA_FOLDER variable.
Change-Id: I28cdb2dac799bd72d11c3e550bba1a946db8b49c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170098
Tested-by: Jenkins
Reviewed-by: Hossein <hossein@libreoffice.org>
For one, a dependency on gb_Postprocess_get_target,AllModulesButInstsetNative
was missing, so copying from instdir might have kicked in too early, before the
instdir files had been updated (e.g., in an incremental build). For another, in
a from-scratch build, files like instdir/program/qt_soffice.html might not yet
have been around, but I'm too dumb to get gbuild to do what I want here (i.e.,
copy files from instdir to workdir once the files are available in instdir and
only if the files in instdir are newer than those in workdir). So just make
this .PHONY and always copy all the files (in line with how other PKGFORMATs
also always rebuild their artifacts, IIUC).
Change-Id: I8b84677cdf867a2b66027ec4a4d781cd1fe623b7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171077
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
...to have $(WORKDIR)/installation/LibreOffice/emscripten populated with just
the relevant files from $(INSTDIR). (This doesn't reuse the complicated
CustomTarget_instsetoo_native/install used for other PKGFORMATs; as a special
case, it uses a much simpler CustomTarget_instsetoo_native/emscripten-install.)
Change-Id: I9c7509aadbc0e6e49ec95bf51c748c2ff9f778b9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171066
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
ICE06 WARNING Column: ExtendedType of Table: CustomAction is not defined in database.
https: //learn.microsoft.com/en-us/windows/win32/msi/ice06
https: //learn.microsoft.com/en-us/windows/win32/msi/customaction-table
Change-Id: I5f9368fedf421b23a397f5dcd77f383cb9f42ac5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166951
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
…by a simple/static $(gb_CustomTarget_workdir)/foo
The build system has a lot of overly complicated leftovers from when it
was introduced and had not only deal with split repositories but also
had to coexist with another buildsystem. Along with lots of copy'n'paste
along the years the makefiles became hard to grasp for newcomers with
all our calls and evals.
As a first step to streamline that, the macros from TargetLocations that
simply prefix a static path to the argument (and similar of the same
kind) are a natural pick before simplifying the rules themselves/getting
rid of a bunch of eval statements.
Change-Id: Ia06dbbcd5d1994755a2ff05b84f72ccbc4e3cab5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167005
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
changing it to git-bash perl can probably be done, but would require
more changes to the path handling in the packaging code
Change-Id: I9a31ee6e9f122a2c167e11f5b4f73b18c5c0fa81
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166343
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
ICE31 ERROR Control AdminNetworkLocation.DlgTitle uses undefined TextStyle MSSansBold8.
In the Control table in the Text column there is:
{&MSSansBold8}Network Location
and the Text Style from the TextStyle table should be used and look like this:
{&DialogDefaultBold}Network Location
https: //learn.microsoft.com/en-us/windows/win32/msi/ice31
Change-Id: I4fa1048cc28d042fc8a78b4dba1495ad75fc017a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166568
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
(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 used the wrong variable name in AC_SUBST and also had no place where
it would be set for the rest of the build to use.
Also the script hardcodes the location of the WiX Toolkit, so check for
the same path in configure.
Also it was needlessly tied to LIBO_TEST_INSTALL - since it has its own
conditional, "double-guarding" it is not necessary.
Change-Id: I6dd4a41e63d2a43a3e2f1aac5b6799a6601eb656
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159510
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
since it is a build-tool it needs to match the arch of the platform the
build is performed, already had used ILIB_FOR_BUILD, but CXX was missed
and broke the build for the aarch64 daily tinderbox
Change-Id: I79edf7d3f7813b43bb447d580d071914a5053b95
with high parallelism there's a high risk of running into random
failures when calling WiLangId.vbs via cscript.
The limiter doesn't use make's jobserver since it is too easy to
deadlock the build since all jobs are started at once, consuming all
slots, but in addition all wait for an additional slot that never is
made available because all jobs are blocked waiting....
All jobs being started at once and all jobs getting started from that
point on getting put under the limiter's control makes this simple
approach with separate grab/release calls possible. If they were spread
out the semaphore wouldn't be available (gets closed/removed as soon as
nothing waits for it anymore)
Change-Id: I345f2904a1d7e8989720722415fb51282ab3b05b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158886
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Right now, CI builders have no WiX toolset installed, breaking all
daily builds (since commit 9aee0383c3)
Change-Id: I92ba2590c5afa711d3079edc070fd904b01de6f3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150823
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
As discussed in the mailing list thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2023-January/089808.html>
"Plan to remove dead C++ UNO bridge implementations (bridges/source/cpp_uno/*)",
the bridge implementation at bridges/source/cpp_uno/gcc3_aix_powerpc is
apparently dead and should thus be removed. However, that was the only bridge
implementation for AIX, which implies that support for the AIX platform as a
whole is dead and should thus be removed.
Change-Id: I96de3f7f97d4fd770ff78256f0ea435383688be9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146057
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This already was a requirement for Windows for a few years now, and make
4.0 was released nearly 9 years ago, and it has been used in LO's build
system since it has been added 11 years ago while it was only available
in prerelease versions of make, providing an alternative workaround for
systems that didn't have make built from cvs… I guess it is finally time
to get rid of those workarounds and just require make 4.0 for everyone.
NOTE: reading files with the $(file …) function was only added with
version 4.2 of GNU make, and just using it without contents was added in
4.1, so those usages aren't supported
Change-Id: Ia1c2c86cfdbbd81f349bb9f7188299e16bdd155f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143910
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
(it makes the output so much nicer to look at :)
Change-Id: Ib4844e264fd950082b19994156661f460331a2d5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143784
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
6204336cc7 added support for building installsets
in parrallel using the GNU parallel tool, this patch changes that to use make's
own parallelism, dropping the need for the external tool.
By not creating huge commandline for all packages at once/sequentially, the
workarounds to modify the PATH variable can also be dropped.
Since : is a special character in makefiles separating a target from
prerequisites delimiter in the installer-tuples has been changed to the
hyphenation point.
The dependencies on the install.phony target have been moved to the actual
installset targets (and those are .PHONY targets as well since the target file
isn't actually generatead).
Also unify the tuples for the different platforms, even if the first element is
only used for Windows.
Move the msi templates to a separate directory for the different types, so that
packaging can also be done in parallel on Windows. Move the setup back to the
makefile so it can be setup prior to running the script.
Previoulsy the script used grep to remove comments from the msi template files,
and had to use "|| true" since grep would also return error when not finding a
match/on empty files. Switch that to awk so it can run without that workaround.
Change-Id: I2f8b73e04d0f601cb0b4e2d8352a38ef9957bc17
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143679
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Seems on Windows, we're hitting the 8k character max cmd line length,
on setups with slightly deeper src tree path locations. Shorten length
of expanded call_installer calls by putting shell script into PATH
locally.
Change-Id: If1cddab9e4e07a7c5ebfae7a4e88e43b1bc8b907
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134938
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
If available, use GNU parallel to run N make_installer.pl scripts in
parallel, to scale packaging LibreOffice up with the rest of gbuild.
* fallback if no GNU parallel found - run make_installer sequentially
as before
* push most of the make_installer.pl input param tweaks from gbuild
down into a shared call_installer.sh script
* call gnu parallel with generated number of
"templ:lang:prodname:ext:pkgfmt:strip-flag" tuples, one for each
package to build (empty templ for non-windows, to save on cmd line
length)
* such that we can run all those in parallel (taking into account
the build's PARALLELISM parameter)
* there's still the main package build running epm sequentially for
umpteen sub-packages from within _one_ make_installer.pl instance, but
that's much harder to parallelize from inside Perl (so we punt on
that here)
Change-Id: Ie7d3084ed60d003d587c5e64dc9fb1809b23e409
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133957
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
As Christian Lohmaier pointed out in [1]:
> When building packages using the epm method, the dependency gets added
> by instsetoo_native/inc_openoffice/unix/find-requires-x11.sh - and it
> looks like it should also add the ()(64bit) marker to the dependency
> when PLATFORMID is linux_aarch64 and not only for linux_x86_64
>
> check with rpm -q --provides libXinerama-1.1.3-2.1.el7.aarch64 whether
> it provides "libXinerama.so.1()(64bit)"
The reply of 2022-03-25T10:41 (public mailing list version
probably still pending in some moderator queue)
shows it does:
> [root@1 rpm2]# `rpm -q --provides
> > ^CbXinerama-1.1.3-2.1.el7.aarch64
> [root@1 rpm2]# rpm -q --provides libXinerama-1.1.3-2.1.el7.aarch64
> libXinerama = 1.1.3-2.1.el7
> libXinerama(aarch-64) = 1.1.3-2.1.el7
> libXinerama.so.1()(64bit)
[1] https://lists.freedesktop.org/archives/libreoffice/2022-March/088637.html
Change-Id: I1b9a4025399d82ac5f5e51ea5523417e3e6cf395
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132094
Tested-by: Michael Weghorn <m.weghorn@posteo.de>
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
