/icu/

Age	Commit message (Collapse)	Author
2019-02-05	Move dubious file: -> smb: conversion from INetURLObject to file UCP	Stephan Bergmann
	The Linux-only conversion of file URLs with a non-empty (other than "localhost") authority to smb URLs had been added in 2010 with 0b9ef81ba5ff08d85f21275222458a5b9b9e484c "tools-urlobj-smb-scheme-patch.diff: migrated" (applying a Go-oo patch?) but giving no rationale beyond "process relative SMB paths (in hyperlinks) correctly". That makes it hard to tell whether that patch is (still) actively useful for anything, or was just a misguided hack from the beginning: * Why make this Linux only? What about other non-Windows OSs? (On Windows, such URLs can be resolved as UNC pathnames.) If the reason for Linux-only was that it is the only OS where LO can handle smb URLs via GIO, why not make it conditional on ENABLE_GIO? * Why map to smb? There are various remote file access protocols. Hardcoding smb looks arbitrary here. Anyway, INetURLObject is arguably at a wrong level for such a patch. To not drop the hack wholesale, reimplement it in the file UCP, forwarding to a potential other UCP that can handle smb URLs any file://<host>/... URLs (rewritten as smb URLs) that the file UCP cannot handle itself. (file://localhost/... URLs will already have been normalized to file:///... by INetURLObject when they reach the file UCP, and even if they were not, the osl/file.hxx functionality underlying fileaccess::TaskManager::getUnqFromUrl knows how to handle them, so they will not take the forward-to-smb code branch.) (The corresponding #ifdef WIN code from 0b9ef81ba5ff08d85f21275222458a5b9b9e484c has already been removed with 82034b04e81b74a048595b0eac0f73581ecbc9e4 "tdf#119326 crash when adding "Windows Share" File resource".) (I came across that 2010 patch while looking into <https://bugs.documentfoundation.org/show_bug.cgi?id=107461> "Does not support 'file://' scheme with actual hostname". A next step would be to make the file UCP actually handle any file://<host>/... URLs that denote the local host.) Change-Id: I77242705dc4c6c1e9cb3a4f32253224ac6cb13cb Reviewed-on: https://gerrit.libreoffice.org/67372 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2017-04-21	gbuild: Remove MSVC 2013 legacy code	David Ostrovsky
	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>
2016-12-14	Merge shell into TaskManager base class	Stephan Bergmann
	(arbitrarily decided to keep the latter, being the less odd class name) Change-Id: I5c061a0f12b8f3095e283b4896f7c910948ac50f
2013-04-30	Move to MPLv2 license headers, with ESC decision and author's permission.	Michael Meeks

2013-01-26	gbuild: do not copy boost headers around	Michael Stahl
	- do not use gb_UnpackedTarball_copy_header_files for boost - adapt the optimization in concat-deps.c for new path - use boost_headers in all LinkTargets that require it - add explicit include paths to mysqlc, mysqlcppconn, libvisio, liborcus Change-Id: I0c43e73ed43cc9d2e6bce8faf55e992d655a0bb9
2012-09-28	gbuild: invert handling of standard system libraries:	Michael Stahl
	Always link in gb_STDLIBS, except when the library explicitly opts out with gb_LinkTarget_disable_standard_system_libs. Change-Id: I489a99114fbfa46d0421a27cf6c7b899dc268a4a
2012-09-28	gbuild: replace direct gb_STDLIBS use with ...	Michael Stahl
	... new gb_LinkTarget_add_standard_system_libs Change-Id: Ib2bc843098db3d8c6822b45a3d21724e67f57d69
2012-09-28	gbuild: split uwinapi out of gb_STDLIBS	Michael Stahl
	Change-Id: I53316e0b9369d806197bccb42cf22d3497af43e7
2012-08-27	fdo#46808, Adapt script::Converter service code to new style	Noel Grandin
	Change-Id: I19b3ba7c978e02ce865360f0411007525012149c
2012-07-02	targetted improvement of UNO API includes / usage	Michael Meeks

2012-04-08	gbuild: "use" vs. "add":	Michael Stahl
	Naming convention for gbuild methods: - "add" is used for stuff that is logically a part of the target (i.e. not registered at the Module, but defined in the target's makefile) - "use" is used for stuff that is logically a different target (i.e. it is registered at the Module, has it's own makefile, may be in a different module than the target)