summaryrefslogtreecommitdiff
path: root/cli_ure/Executable_climaker.mk
AgeCommit message (Collapse)AuthorFilesLines
2017-04-21gbuild: Remove MSVC 2013 legacy codeDavid Ostrovsky1-1/+0
Uwinapi is discontinued. Change-Id: I063b4d0d8fab2d60de168e960a63b8181158ac01 Reviewed-on: https://gerrit.libreoffice.org/23198 Reviewed-by: David Ostrovsky <david@ostrovsky.org> Tested-by: David Ostrovsky <david@ostrovsky.org>
2017-02-21When building with clang-cl on Windows, build CLR code with MSVCStephan Bergmann1-5/+2
...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>
2016-06-20switch to EHs on windowsMarkus Mohrhard1-1/+1
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>
2013-10-28gbuild: refactor CliLibraryMichael Stahl1-1/+1
- 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
2013-09-22cli_ure: copy cli_basetypes to INSTDIR/sdk/binMichael Stahl1-0/+4
The library is already in the URE/bin directory, but that is not sufficient to be able to run sdk/bin/climaker.exe. There are apparently 4 ways for a .net/CLR executable to locate shared libraries: 1) in the same directory as the executable 2) in some mysterious "GAC" thing in C:/Windows (which is presumably how it works if you actually install LO) 3) via an application configuration file entry "probing", which only works when it's in a sub-directory of the one the executable is in 4) via a DEVPATH variable, but that only works with a special configuration entry in a system "machine config" file of the .net framework Specifically PATH is apparently ignored. Since building on Windows is enough of a PITA already and we don't want developers to have to edit another config file, put another copy of the library into sdk/bin. http://tutorials.csharp-online.net/.NET_CLR_Components%E2%80%94Resolving_Names_to_Locations http://tutorials.csharp-online.net/.NET_CLR_Components%E2%80%94CLR_Loader Change-Id: I511957ad9a9a918ed0c316126304a1980fb2d289
2013-08-22Missing dependency (see "#using <cli_basetypes.dll>" in climaker_share.h)Stephan Bergmann1-0/+3
Change-Id: I2575da1ccbe1c301dd826588aec2a787176d3cfd
2013-04-29Remove dependency of climaker on registry formatStephan Bergmann1-0/+2
See the comment in climaker_app.cxx main about room for improvement. Change-Id: I11cc2f62c9d42269d5c96253198ee4e730496e75
2013-04-19cli_ure: remove obsolete USE_DEBUG_RUNTIME check for msvcmrtMichael Stahl1-4/+1
This is handled in com_MSC_class.mk now. Change-Id: I5e4c2e791e9acd623d7c5ce352b5c39b6cb939b4
2012-10-24fix warnings in cli_urePeter Foley1-0/+4
Change-Id: I4e081473612403e0bf277e8dbf5f1b9a15541dd7
2012-09-28gbuild: invert handling of standard system libraries:Michael Stahl1-2/+0
Always link in gb_STDLIBS, except when the library explicitly opts out with gb_LinkTarget_disable_standard_system_libs. Change-Id: I489a99114fbfa46d0421a27cf6c7b899dc268a4a
2012-09-28gbuild: gb_Library_PLAINLIBS_NONE cleanup for WNT:Michael Stahl1-2/+5
add a new gb_LinkTarget_use_system_win32_libs to abstract different linker options on MSVC and GCC. Change-Id: Ic9bf2545f59bf7871e6fc06b290c486ddfbec03d
2012-09-28gbuild: replace direct gb_STDLIBS use with ...Michael Stahl1-1/+2
... new gb_LinkTarget_add_standard_system_libs Change-Id: Ib2bc843098db3d8c6822b45a3d21724e67f57d69
2012-09-28gbuild: split uwinapi out of gb_STDLIBSMichael Stahl1-0/+1
Change-Id: I53316e0b9369d806197bccb42cf22d3497af43e7
2012-09-22gbuildize cli_ureDavid Tardon1-0/+41
Change-Id: I716d666fc6e9d5339bc65a1b3943b2cecf45b6fe