For those not in the know, vcpkg is Microsoft's attempt at a package manager for C/C++ libraries on Windows. This tool is pertinent to my interests because, look at what we currently keeping in our MapGuide/FDO source repos!
That's several GBs of source code for external thirdparty libraries we need to build MapGuide and FDO. It's a situation we can't avoid at the moment (especially on Windows) because until vcpkg, we had no choice. There was nothing akin to "nuget for C++ libraries" for Windows. On Linux we at least have the option of offloading to system installed libraries provided by the default distro package manager.
With vcpkg, this would greatly simplify the MapGuide/FDO build system on Windows. Most of the libraries listed here already exist as ports in vcpkg and most are more up-to-date as well. Imagine just doing a svn sparse checkout, skipping having to download whole parts of Oem/Thirdparty, point the MapGuide/FDO sources to our existing pre-built vcpkg packages and enjoy much faster build times, because we're not wasting a majority of it building external libraries. It may be even fast enough to continuously integrate!
It would also almost certainly spell the end of the difficult story around custom GDAL binaries as well, because I've been doing my part to add/enhance (geospatially-)relevant vcpkg ports and to light their current GDAL vcpkg port up with as many features as technically and legally possible. If we ever do get to building FDO using vcpkg-sourced external libraries, you're gonna get a GDAL/OGR provider with maximum vector/raster format support (barring the obvious omissions like Oracle, DWG, ECW, etc due to legal hurdles in obtaining and using their respective libraries and SDKs)
A vcpkg-based MapGuide/FDO build system for Windows is definitely something on my radar.
Posts
2 comments:
Getting up-to-date GDAL/OGR as a benefit of this is a major win -- creating RFC for component updates seems to be out of sync with modern packaging within solutions
How many GDAL releases is MG behind now (https://trac.osgeo.org/gdal/wiki/NewsAndStatus) ... 16?? [though it's more of an FDO issue than a MG one]
GDAL 2.2 was recently released.
The vcpkg port is at 1.11, which is still newer than what FDO uses currently (1.10)
The most tricky parts will be components that for licensing reasons we cannot put up as public vcpkg ports. Namely DWF Toolkit and DBXML. If we adopt vcpkg, we'd probably have to keep these components in the source tree.
Post a Comment