summaryrefslogtreecommitdiffstats
path: root/cli_ure/Executable_climaker.mk
Commit message (Collapse)AuthorAgeFilesLines
* gbuild: Remove MSVC 2013 legacy codeDavid Ostrovsky2017-04-211-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>
* When building with clang-cl on Windows, build CLR code with MSVCStephan Bergmann2017-02-211-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>
* switch to EHs on windowsMarkus Mohrhard2016-06-201-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>
* gbuild: refactor CliLibraryMichael Stahl2013-10-281-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
* cli_ure: copy cli_basetypes to INSTDIR/sdk/binMichael Stahl2013-09-221-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
* Missing dependency (see "#using <cli_basetypes.dll>" in climaker_share.h)Stephan Bergmann2013-08-221-0/+3
| | | | Change-Id: I2575da1ccbe1c301dd826588aec2a787176d3cfd
* Remove dependency of climaker on registry formatStephan Bergmann2013-04-291-0/+2
| | | | | | See the comment in climaker_app.cxx main about room for improvement. Change-Id: I11cc2f62c9d42269d5c96253198ee4e730496e75
* cli_ure: remove obsolete USE_DEBUG_RUNTIME check for msvcmrtMichael Stahl2013-04-191-4/+1
| | | | | | This is handled in com_MSC_class.mk now. Change-Id: I5e4c2e791e9acd623d7c5ce352b5c39b6cb939b4
* fix warnings in cli_urePeter Foley2012-10-241-0/+4
| | | | Change-Id: I4e081473612403e0bf277e8dbf5f1b9a15541dd7
* gbuild: invert handling of standard system libraries:Michael Stahl2012-09-281-2/+0
| | | | | | | Always link in gb_STDLIBS, except when the library explicitly opts out with gb_LinkTarget_disable_standard_system_libs. Change-Id: I489a99114fbfa46d0421a27cf6c7b899dc268a4a
* gbuild: gb_Library_PLAINLIBS_NONE cleanup for WNT:Michael Stahl2012-09-281-2/+5
| | | | | | | add a new gb_LinkTarget_use_system_win32_libs to abstract different linker options on MSVC and GCC. Change-Id: Ic9bf2545f59bf7871e6fc06b290c486ddfbec03d
* gbuild: replace direct gb_STDLIBS use with ...Michael Stahl2012-09-281-1/+2
| | | | | | ... new gb_LinkTarget_add_standard_system_libs Change-Id: Ib2bc843098db3d8c6822b45a3d21724e67f57d69
* gbuild: split uwinapi out of gb_STDLIBSMichael Stahl2012-09-281-0/+1
| | | | Change-Id: I53316e0b9369d806197bccb42cf22d3497af43e7
* gbuildize cli_ureDavid Tardon2012-09-221-0/+41
Change-Id: I716d666fc6e9d5339bc65a1b3943b2cecf45b6fe
generated by cgit (git 2.34.1) at 2024-05-22 04:37:26 +0000