Age | Commit message (Collapse) | Author | Files | Lines |
|
...now that LIBO_INTERNAL_ONLY always has constexpr support.
It had been added for LO 5.0 (effectively always expanding to nothing for
!LIBO_INTERNAL_ONLY), not wrapped in '#if LIBO_INTERNAL_ONLY' presumably because
it was assumed to be used freely in URE include files, but turned out to be only
used in LIBO_INTERNAL_ONLY code. It is unlikely that any 3rd party code made
use of it.
Change-Id: I68970c5a2e2d7ef68ac5b79efc8dc1de54c43198
|
|
/debug:fastlink improve build performance and reduce resources
consumption. When this linker oprion is used the linker-produced
program database (PDB) files doesn’t have any private symbol
information. Debug information is distributed among input object
and library files, and the linker PDB just serves as an indexing
database. Obviously, this provides a huge performance benefit for
the daily developer builds.
fastlink PDB files cannot be shared with another developer on the
team or uploaded directly to symbol server. There is spcial tooling
which is able to create a full PDB from the /debug:fastlink PDB
on demand: mspdbcmf: [1]. The integration of mspdbcmf is beyond
the scope of this change.
[1] https://blogs.msdn.microsoft.com/vcblog/2016/10/05/faster-c-build-cycle-in-vs-15-with-debugfastlink/
Change-Id: I14e29cf116407b420598f692c8d6d851e686268b
Reviewed-on: https://gerrit.libreoffice.org/34330
Reviewed-by: David Ostrovsky <david@ostrovsky.org>
Tested-by: David Ostrovsky <david@ostrovsky.org>
|
|
Change-Id: Ib25dadb25d8c2df1361de194f74cf3ddd459650d
Reviewed-on: https://gerrit.libreoffice.org/34783
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Icaf1de556ae20027e27321750197ed574b508435
|
|
Change-Id: I3dbbf84af75fd5ec3598302252ee1103bb9d5596
|
|
...post 3c946d688627ba0c31bcb37dfed4e6e180608854 "Put also the LICENSE file in
Resources on macOS"
Change-Id: I0a3435cc973d09e029ce4133d62544e4e432f6b5
|
|
...with 198c41c4fe8be4ce8a6ddab43ae0c5f17a4889ac "new loplugin unoany"
Change-Id: Ia4e59356ad8ef3af899209a287ac5326e1389c5e
|
|
Change-Id: I5d6c4a67cb2a09e7cd5bd620c6b262d188701b89
Reviewed-on: https://gerrit.libreoffice.org/34714
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: Ic14140f197a2c5e1632fd27cfae38ca4eff9bd8c
Reviewed-on: https://gerrit.libreoffice.org/34562
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
|
|
Use the -e and -o pipefail bash option to make the script fail more
reliably if some command inside a pipeline fails. Use the -u option to
catch mistyped variable names.
Move the signing of executables in the bundle's Contents/MacOS after
signing nested bundles.
Change-Id: I21d441bcb2dbfc19b0cb5718b76402b1686d2239
|
|
...as clang-cl doesn't support the /clr switch.
* In configure.ac, capture the MSCV version (that would be used if CC hadn't
been overridden to use clang-cl) into MSVC_CXX.
* The logic which flags to pass into gb_CObject__command_pattern is coded into
the platform-agnostic LinkTarget.mk, so it's too late to try and filter all
relevant flags in com_GCC_class.mk, depending on whether a given .cxx file is
a normal one built with the normal $CXX or a special /clr one built with
$MSVC_CXX. Thus, a new CxxClrObject class had to be introduced that captures
this information early.
* When building with clang-cl, the generated config_host/config_*.h files
contain values suitable for clang-cl, but not for MSVC. But the .cxx files
compiled with MSVC happen to include config_global.h, and would fail. Hack
around that problem for now by introducing a hard-coded, minimal
solenv/clang-cl/config_global.h that is found first when buliding such a
CxxClrObject. Needs cleaning-up properly.
Change-Id: Iff8aac51c0b4fa906b14503c692640dda0996d33
Reviewed-on: https://gerrit.libreoffice.org/34509
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I1cd5331157e684afb01e6555168ce646194c6ff2
Reviewed-on: https://gerrit.libreoffice.org/34493
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Khaled Hosny <khaledhosny@eglug.org>
|
|
Change-Id: I95be6c97e7c01159f274397b636ef0599d872c0f
|
|
...including some double-warnings that'll get cleaned up shortly
Change-Id: I14e9796f2846a6bb61e4c93dfb23cba6488ea2e6
|
|
In OOo times, there'd originally been efforts to allow building on Windows with
MinGW. Later, in LO times, this has been shifted to an attempt of cross-
compiling for Windows on Linux. That attempt can be considered abandoned, and
the relevant code rotting.
Due to this heritage, there are now three kinds of MinGW-specific code in LO:
* Code from the original OOo native Windows effort that is no longer relevant
for the LO cross-compilation effort, but has never been removed properly.
* Code from the original OOo native Windows effort that is re-purposed for the
LO cross-compilation effort.
* Code that has been added specifially for the LO cross-compilation effort.
All three kinds of code are removed.
(An unrelated, remaining use of MinGW is for --enable-build-unowinreg, utilizing
--with-mingw-cross-compiler, MINGWCXX, and MINGWSTRIP.)
Change-Id: I49daad8669b4cbe49fa923050c4a4a6ff7dda568
Reviewed-on: https://gerrit.libreoffice.org/34127
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
It's faster to change our code not to rely on -DSOLARIS than to
wait for python developers to remove such nonsense from their public
headers.
Change-Id: I3ab05d41bbb51b91a2add599339ce334b5099330
|
|
Starting from MSVC 14.0, the directory table layout of VC++ Runtime merge
module changed. As consequence, all MSI produced with newer compilers,
including MSVC 15.0 (aka VS 2017) are broken in term that the VC++
Runtime DLLs are installed in the wrong directory, e.g.: C:\System64.
According to the specification for merging merge module (msm), see:
"Authoring Merge Module Directory Tables": [1], custom action 51 (set
property) must be emitted for every directory name in the merge module
directory table if the directory name is starting with the standard
directory name.
Quoting it here:
"
When a predefined directory is included in a merge module, the merge
tool automatically adds a Custom Action Type 51 to the target database.
The merge module author must ensure that a CustomAction table is also
included. The CustomAction table may be empty, but this table is required
to exist in the target database and ensures that the modified predefined
directories are written to the correct locations. For example, when a
system directory is included in a merge module, the merge module author
must ensure that a Custom Action table exists.
Note that the matching algorithm for the generation of these type 51
custom actions only checks that the directory name begins with one of
the predefined SystemFolder properties. It does not verify that the
directory name exactly equals the directory property. Any directory
beginning with one of these standard folder names gets a type 51 custom
action, even if the rest of the name is not a GUID. Authors need to take
care that this does not generate false positive matches, and unintended
custom action generation, on derivative primary keys that begin with one
of the SystemFolder properties."
Rectify the problem by analyzing the directory table from the merge
module, checking whether the directory name starts with the standard
prefix name and if it is the case, emitting custom action 51 to set this
variable to the standard directory name.
Implementation details:
We use the existing facility for emitting the custom action table events
including referencing them in the corresponding sequence tables. Given
that the specification above doesn't mention what sequence table should
be referencing this emitted custom action, we reversed engineer this
information from WiX toolkit. Merging the VC++ CRT module with WiX
toolkit and investigating the resulting MSI with Orca MSI reader, reveals
that these sequence tables were referencing from these sequence tables:
* AdminExecuteSequence
* AdminUISequence
* AdvtExecuteSequence
* InstallExecuteSequence
* InstallUISequence
Replicate this behaviour here as well. Note, though, that custom actions
are generally not referenced in AdminUISequence and AdvtExecuteSequence
tables in LibreOffice MSI building tool chain.
Rendering of the custom action is achieved by programmatic emulation of
custom action in SCP module. Consider this similar SCP module based
action:
Name = "MigrateInstallPath";
Typ = "321";
Source = "shlxtmsi.dll";
Target = "MigrateInstallPath";
Inbinarytable = 1;
Assignment1 = ("InstallExecuteSequence", "", "CostInitialize");
Assignment2 = ("InstallUISequence", "", "CostInitialize");
We instantiate the following data structure to emit custom action
System64Folder.3CFBED52_9B44_3A4D_953C_90E456671BA1:
Name = "System64Folder.3CFBED52_9B44_3A4D_953C_90E456671BA1"
Typ = "51"
Source = "System64Folder.3CFBED52_9B44_3A4D_953C_90E456671BA1"
Target = "[System64Folder]"
Styles = "NO_FILES"
Assignment1 = ("AdminExecuteSequence", "", "CostInitialize")
Assignment2 = ("InstallExecuteSequence", "", "CostInitialize")
Assignment3 = ("InstallUISequence", "", "CostInitialize")
[1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa367787%28v=vs.85%29.aspx
Change-Id: I2fbd37ff63298d99b2ba1b6afe6e875f56d8e378
Reviewed-on: https://gerrit.libreoffice.org/33366
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: David Ostrovsky <david@ostrovsky.org>
|
|
...in a somewhat hacked-up way for now (see the TODO comment)
Change-Id: Ida89fb8257b876cfca05b3048ce15996091c5703
|
|
Change-Id: I783a121b43223bbd0fd3f6250b2e009a77c87a85
|
|
Rename of FLEX to LEX needs to be done in the unittest as well.
Change-Id: Ic038fa01d65edb5724c3d9dc8a04c72c6367372d
|
|
added support for add_grammars macro
Change-Id: I17955bd1534d9f43e1953691d985a18ee8241d38
|
|
added add_scanner macro
Finalized the move around in gbuild-to-ide, to signal
which generators are actively supported.
Change-Id: I11699cd4380d49efc3b541abb7780b5136162433
|
|
Change-Id: I56c91974a27cf100bc0faa1b009f4bf6358b47f5
|
|
Change-Id: I0b39526c0f0854ddbb29e77ece303cf2bdd842c4
|
|
Change-Id: Ic535de878c17749cdb2e7a6eadeb27dd2194810e
|
|
Change-Id: I8aab9004001a9a2ddd54b4c73857b6f9c5b51515
Reviewed-on: https://gerrit.libreoffice.org/33486
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Takeshi Abe <tabe@fixedpoint.jp>
|
|
This reverts commit 2757ee9fe610e253e4ccc37423fa420004d0f388.
Besides causing a performance regression, I now notice that
there is code in SW that relies on iterating over two different
SfxItemSet's in parallel, and assumes that missing items are
returned as nullptr, which is not the case for my std::map based
change.
Change-Id: I2b1110350fe4c4b74e5508558e9661ef1e1a103e
|
|
Change-Id: I6a139d5be193c968c2bf3373b415baa25dc32595
|
|
Change-Id: I2ed12aae6596492e1059f8461efbafb711d16472
|
|
Drops a lot of duplicated code, as Idle is just a convenience
class for instant, mostly low priority timers.
Change-Id: I847592e92e86d15ab1cab168bf0e667322e48048
|
|
Moves all the "task-specific" stuff into a Task class and just
keeps the "real" static Scheduler functions in the original
Scheduler class.
Change-Id: I9eb02d46e2bcf1abb06af5bab1fa0ee734d1984c
|
|
In addition to the GDB pretty printer, this annotates a lot more
Timers and Idles.
Change-Id: I5b93fab02161b23bb753e65ef92643a04fb0789c
|
|
instead of naked array
SfxItemIter ended up needing to take copies of stuff because various
code likes to iterate over the items and delete items inside the loop.
The gdb pretty printer is no longer quite as pretty as it was before,
but it still prints useful info.
Change-Id: I59b07ea42f6b1c74798a15402970b9dbd8233dbe
|
|
Change-Id: Id915626324a692d8ec87cc6899c3de298682348b
|
|
Extended the call to gbuildtojson, with extra file types.
Some filetypes still need data collection, this
is noted in the file as todo.
Change-Id: I3e832f82656236d42d1d7b59bf3ac2925c5b1568
|
|
gbuild-to-ide now contains a dict with json name -> file extension
post_GbuildToJson.ml contains a todo list (missing files, new arguments)
gbuildtojson.cxx made resistent (no extra argument list to maintain)
Change-Id: I7f346f606ed5fba0a1eaffdd38454b484cecfcf5
|
|
Change-Id: I7e51445e890bd1ed5bcafb9cc713c6f5fad24631
|
|
as otherwise signing fails (LibreOffice.app: code object is not signed at all
In subcomponent: path/to/foo.jnilib)
Change-Id: I3e4691f2ada408d9e76d200a3291b044753ec85c
|
|
addressed issues in order of appearance:
warnings
- prefer [..] && [..] (SC2166)
- unused 'awkCMD' (SC2034)
- typo currentFirstLIne -> currentFirstLine (SC2154)
recommendations
- use $(..) instead of `..` (SC2006)
- remove $ on arithmetic variable OPTIND (SC2004)
- double quote to prevent globbing in $findArgs (SC2086)
Change-Id: I2d2b7aecac97b2e4e0df8ce556c85995d4ecf7cf
Reviewed-on: https://gerrit.libreoffice.org/33003
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
|
|
see 7a75b39273de47190b7a1fa20e0bcaca6d089033
Change-Id: I575e5d5dc757cc054a49ae6596183f46373072f2
|
|
There is some problem with the pattern rule in post_GbuildToJson.mk
being ignored, causing spurious
workdir/GbuildToJson/Library/lib*.exports files with bogus content to be
written; rather than trying to adapt that to 3.81 pattern rule
evaluation, just refuse to run with 3.81, which is obsolete anyway.
Change-Id: I492866464b309f8c475e34e8f311e42bf8736247
|
|
Fails because library has dep on GeneratedPackage_python3, so nerf the
dep like the others.
Change-Id: I050a0f50996ce4231eb966fb6b624908d2f1788c
|
|
Change-Id: Ib35d8fcc41e1c49bfef01c980b25c051190cb753
Reviewed-on: https://gerrit.libreoffice.org/32990
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I0b4ee6377aac984b7acf7085ac43cad3d088612d
|
|
That sanity check was added in
615fae2f67028f3c5c51c70c77dbaa9b9f3856d6 but we lost it at some stage.
The codesigning script has a very confusing history, in part caused by
its use for two purposes, when building for the Mac App Store and when
building for a TDF style distribution on a dmg disk image. Those who
work with the former and those who work with the latter haven't
necessarily checked that it doesn't break for the other case. Sorry.
Change-Id: I79011302f60b1f6551328c8b80e00f5d3698504c
|
|
Change-Id: Ibde5189ecf09ec8dfaf3223683c5480974084865
|
|
Change-Id: I63571c0003e6e0d7bd7a0c71a7dd47955a8871e0
|
|
Change-Id: Ie5404f11cbc5b05bd18455ae81526eb2de01548c
|
|
cat is a tool for con"cat"enating files. Reading a single file
as input to a program is considered a Useless Use Of Cat (UUOC).
It's more efficient and less roundabout to simply give file as input.
Also use $(..) instead of legacy `..`
Backtick command substitution `..` is legacy syntax with several issues.
It has a series of undefined behaviors related to quoting in POSIX.
It imposes a custom escaping mode with surprising results.
It's exceptionally hard to nest.
$(..) command substitution has none of these problems, and is therefore strongly encouraged.
Change-Id: Ia668c6323660641bbb5084ee824ae9ae7631c76f
Reviewed-on: https://gerrit.libreoffice.org/32473
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
This currently has no effect and so the CppunitTest_cppcanvas_emfplus
pops up an annoying window.
(regression from 181932b31ea9c07a9bec3677e73b67a9a6d4e3f2)
Change-Id: I26314d98f10f6b39ca1c28821ccd0de6ba2a4358
|