| Age | Commit message (Collapse) | Author |
|---|
|
...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>
|
|
This seems to be a good idea based on several discussions
in the project. In the end catching SEH exceptions is just
going to cause strange platform dependent bahavior.
This patch is based on on
http://thread.gmane.org/gmane.comp.documentfoundation.libreoffice.scm/39102/focus=55516
and includes some additional cleanup of the sal signal code.
Change-Id: Iedc998e37e6495afec445eccb60fa1c2b1a7defd
Reviewed-on: https://gerrit.libreoffice.org/26497
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
It looks like what works is to give the source file names with
backslashes but everything else with forward slashes?
Change-Id: Iaf910ab5fc41984d1315a30b164a334d28344c16
|
|
Change-Id: Ia54def7a404e07974eb1e8a556f4659cd974e7f8
Reviewed-on: https://gerrit.libreoffice.org/7081
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: Matúš Kukan <matus.kukan@collabora.com>
|
|
- stop copying the DLL to OUTDIR
- since that was the main reason for the separation between
CliLibrary and CliLibraryTarget, merge the targets;
the newly inherited variables are not expected to cause problems
- hardcode target to URE bin dir for now, no immediate need for
multiple layers
Change-Id: If0fea1337349c41f231c8cde122852c71d5080a7
|
|
Change-Id: I76b4815208354e78eb3575982235b6f26f1e02fd
|
|
This is handled in com_MSC_class.mk now.
Change-Id: I5e4c2e791e9acd623d7c5ce352b5c39b6cb939b4
|
|
Change-Id: I092a8183b7aa044cc6e55df91ac1109e269d8b8e
|
|
It turns out that the native library cannot be renamed after creation.
The right name must be used from the beginning, otherwise
publishing is failing with the follow error (gacutil -i):
"Failure adding assembly to the cache: Invalid file or assembly name.
The name of the file must be the name of the assembly plus .dll or .exe."
To rectify that create the native lib as cli_cppuhelper.dll,
rename the signed assembly to assembly/cli_cppuhelper.dll and
teach scp2 to pick up the right one: assembly/cli_cppuhelper.dll
(and not cli_cppuhelper.dll).
Change-Id: I2073b617cd440865ae4ab838bb801329f2b07194
|
|
Change-Id: I4e081473612403e0bf277e8dbf5f1b9a15541dd7
|
|
I am not sure this really fixes the problem, but it is the only
difference between dmake and gbuild builds I can see.
Change-Id: I96fa4120dc2a8221a75e150a62582aebda98f505
|
|
Change-Id: I7dbb065c8b1b2fef85e6e7f42ef80991102785e0
|
|
add a new gb_LinkTarget_use_system_win32_libs to abstract different
linker options on MSVC and GCC.
Change-Id: Ic9bf2545f59bf7871e6fc06b290c486ddfbec03d
|
|
Change-Id: Ibd19e82a41ceac76ec5c3d6059f497926b8b5d0e
|
|
Change-Id: I3f7d0034500b52e363f5cc3e136b89a5d75aab64
|
|
Change-Id: I716d666fc6e9d5339bc65a1b3943b2cecf45b6fe
|
