Introduced special token LIBO_DEV_INSTALL=TRUE to communicate what install set
to build from Makefile.top's dev-install target to
instsetoo_native/util/makefile.mk. Somewhat arbitrarily, always use a "release"
install set regardless of --enable-release-build (the dev-install set is used
for "make check," and it is safer to test "release" install sets in
--disable-release-build builds than the other way around, should those builds
ever start to deviate significantly).
The "always build a defaul-laguage openoffice product" logic had been obsoleted
a long time ago already.
Change-Id: I64ec87a0b8dc6fe81cab5531c43e29db3f5128af
Now that 5c47e5f63a "fdo#51252 Disable copying
share/prereg/bundled to avoid startup crashes" removed the use of share/prereg,
there is no longer need to generate it in the first place (by calling "unopkg
sync" at build or installation time), and so no need for the "unopkg sync" sub-
command, either. This also allows to simplify some of the jvmfwk code that was
only there so that "unopkg sync" (which can require a JVM) can work in "hostile"
environments (during build and installation).
Change-Id: I52657384f4561bf27948ba4f0f88f4498e90987f
FINDPRODUCT property was not available to this deferred custom action.
Not to mention that registry keys are also deleted at his stage of uninstallation.
The proper solution is to set the installation directory with a type 51 custom action,
and pass it to RemoveExtensions custom action via CustomActionData property.
Change-Id: I0ac18b3a0b19ff1a87bcf580fad9c7fdadb26f76
use 3.7.0.0.alpha0 where possible;
use the suffix "+" in the about dialog to signalize non-release builds
Change-Id: If09c78cd30b10e54c46f737a695e0194039c7efc
User name and Company asked here are useless, and misleading. Users
think that they are related to Tools - Options - LibreOffice -
User Data. Also per-user installation context makes little sense.
If anybody still wants to install LibreOffice only for the current
user, it is still possible with the ALLUSERS property.
Change-Id: I537b45ab77d6d227264e1dc0bcaf93a9cfa8ea71
In some circumstances installation of embedded VC++ runtime
fails with error code 1935. This usually occurs, when there are
many different versions of VC++ runtimes installed on the computer,
including beta versions. We can workaround this Microsoft bug, if we
don't install our VC++ runtime. A new property was introduced. It is
called VC_REDIST, and installation of VC++ runtime depends on its
value. (BTW the solution is general, ComponentCondition can be used
for any merge module, now we have only the VC++ runtime merge module.)
When the user experiences error code 1935, he should try to install
LibreOffice with the following command line:
msiexec /i <msi file name> VC_REDIST=0
The patch fixes another minor issue. 64-bit VC++ runtime will
not be installed on 32-bit systems any more.
Change-Id: I I6c5e066c6e60b011235e6019a8a35c9e953209bc
this removes dmake completely out of the build for migrated modules
build.pl now assumes modules to be gbuild, unless there is a
prj/dmake file
Change-Id: I674a036b182ee13c5ec093e83cb3d38133112d3b
