| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Change-Id: I6c145e984c885c7e06caa1c27bfb354ea49ad9ce
|
|
|
|
| |
Change-Id: Ice06e639213aeb6f7f23cbf4634947dd25613db1
|
|
|
|
| |
Change-Id: Idef032c08c097e04fcf0cae3d184ceb660b65949
|
|
|
|
| |
Change-Id: I4b9fda0f81d43cab80a015a2eb7374a94f3da7de
|
|
|
|
|
|
|
|
| |
PRODUCTVERSION is associated with SHORT_PRODUCTEXTENSION.
ABOUTBOXPRODUCTVERSION is associated with ABOUTBOXPRODUCTVERSIONSUFFIX.
We should not mix these another way.
Change-Id: I991f74e058d19ec3ae0d98e8efe8458d648ae74c
|
|
|
|
| |
Change-Id: Iafa671028ce73c2ec3a2706dda60f58aaeda7fda
|
|
|
|
| |
Change-Id: I5368770926aee871e20b2d87fa51b28212c8be4f
|
|
|
|
|
|
|
|
|
|
| |
64-bit registry entries were entered via a custom action, which
did not always work. By default the custom action ran with user
privileges, which were not sufficient to write the registry.
It is not necessary to use custom actions for this task. Windows
installer supports it well.
Change-Id: Id65458c363c2b90b3e7d166b4c836bfb1ff19bf4
|
|
|
|
| |
Change-Id: Ibc6addfe5eacf4a9e23f6f26830f5a1f9bf77594
|
|
|
|
| |
Change-Id: I8811ce96cb70429ae458e31cafb8979bb6bb9644
|
|
|
|
| |
Change-Id: Id42e7b14d98f072ea17b203af7ffdc8fe7a7a74f
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are several modules in tail_build now that are depended on by
other modules from postprocess (e.g., pyuno depends on 18npool). That
means that build.pl actually schedules i18npool (and its parents) for
build. This is fine for build.pl -P1, but it could be a problem for
build.pl -P2. It is also wasteful, because we are not actually using
tail_build to the full extent.
This gross hack schedules all modules that depend on any tail_build
module _after_ tail_build, so all modules that are in tail_build are
only build in tail_build.
Change-Id: I39840c1cbbfc5024f0009296416c628be028657a
|
|
|
|
| |
Change-Id: Iae3e78e2abe59714d5eb9fa0609861a00e85c944
|
|
|
|
| |
Change-Id: Ib1d9cd1dc1e9c24a5a72c51060797f2214a95c89
|
| |
|
|
|
|
|
|
|
| |
So it is easier to check differences between install scripts generated
by dmake and gbuild.
Change-Id: I12bbdf481c84c896b67a94eaca6460ffb52d96ec
|
|
|
|
| |
Change-Id: I7d409fbe813f07dc87301b6c6f01a40f531d368c
|
|
|
|
| |
Change-Id: I49986d6feac5e46c7b2f3017cf97b07dce4db42f
|
|
|
|
| |
Change-Id: Ia2b63502dbd8b5e4e0ca7faa34e06df73f094a78
|
| |
|
|
|
|
|
|
| |
Unfortunately this --enable-dbg-util only problem (caused by
_GLIBCXX_DEUBG) resurfaced, perhaps because of new std::string based
logging in sal; adapt all map files to export the unique symbol.
|
|
|
|
|
|
|
|
| |
When install location is writable to user (typical on Windows XP),
Python generates .pyc files. We can remove them using the RemoveFile table
in MSI. We generate an entry for each .py file in the install set.
Change-Id: I314582d52162c6f3ae3acc72de9d620680fb23e0
|
|
|
|
| |
Change-Id: Id88f38fb806c6178240eb69da69c2e633c2033da
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
Change-Id: I I I0bfc367a3b2c551509b383fc4f6dcaa3cb8661f8
|
|
|
|
|
|
|
|
| |
make 3.82 understands mixed paths, so use them.
This allows us to get rid of evil in BuildDirs.mk.
Hopefully, life will be simpler now.
Change-Id: I I I641f28c6af1948963f7004f8071af62e21caabb3
|
|
|
|
| |
Change-Id: I88f5e8dacbd81d94a7f079d6c1b24c513e18bf34
|
| |
|
|
|
|
| |
Change-Id: Idda0262e62e42817b8c0502a38ee16913495233c
|
|
|
|
| |
Change-Id: I57463bdcb8f580866d56741c427fd9882a151b07
|
|
|
|
| |
Change-Id: I180bd296e3834c624174b7dce08af5b745bfc1b6
|
|
|
|
| |
Change-Id: If93cca6d8e12baae3369bcba62287d96072f1c93
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
This is only a partial fix to the bug, the second part will be the creation
and population of MsiFileHash table.
|
|
|
|
| |
Signed-off-by: Petr Mladek <pmladek@suse.cz>
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Even if it does nothing because there is no installation available .-)
|
|
|
|
|
|
| |
Commit 0c80ad06fd96a4fec062a7edfff12bb65ef204b4 broke MacOS X builds
because of this discrepancy. It would be easy to accept both, but I
think it is better to be consistent with gbuild.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
it is in the main installation tarball anyway; it was put in langpacks
that did not have its own dictionary from some strange reason
|
| |
|
| |
|
| |
|
| |
|