* [libcroco] Initial port files for libcroco
From the libcroco readme file:
Libcroco is a standalone css2 parsing and manipulation library.
The parser provides a low level event driven SAC like api
and a css object model like api.
Libcroco provides a CSS2 selection engine and an experimental
xml/css rendering engine.
libcroco is part of the GNOME project.
* [libcroco] Build fixes for Linux.
* [pthread] update to v3
* [flint, mosquitto, usbmuxd] bump CONTROL files and add final touches for PThreads4W v3
* [arb] add compatibility with PThreads4W
* Prevent stale MSYS gpg-agent.exe process blocking command control
This commit fixes:
https://github.com/microsoft/vcpkg/issues/5476
The issue is that CI environments such as Appveyor's VS2017 image will wait for all processes to complete. If a stale process resides as a result, builds will hang.
There does not appear to be any good reason for gpg-agent.exe to be running once the build of icu has completed.
Without this patch builds of icu4c using CI systems will very likely hang and not in an obvious way.
Is this the _right_ solution to this problem? Probably not but it is one solution. And it degrades gracefully in that the build will not fail if gpg-agent.exe is not running. The gpg-agent.exe will not run again once MSYS has been configured, so to test this patch, a fresh install of vcpkg is required. Open the task manager and before the icu build completes, look for gpg-agent.exe just sitting there for no reason.
Might I suggest that the issue is fixed in vcpkg MSYS instead or as well?
Please don't request further from this commit.
* [icu] Kill MSYS gpg-agent.exe on Windows
* initial usd port
* [usd] Acquire python2 required to build
* Use copy instead of rename
Handle the source path and the package path being on different partitions.
* [g3log] Add new port (fix#5684, fix#5941)
* [g3log] Remove usage
* [g3log] Restore usage
* [g3log] Add UNIX support
* [g3log] Use vcpkg_install_cmake
* [g3log] Update to 2019-05-14
* [g3log] Update version number
https://github.com/cbeck88/visit_struct
The motivation for this port is that we do not have to lock ourselves
with Boost.Fusion, or Boost.Hana, and can benefit from some downstream
projects such as Configuru at the same time.
