[pdal] vcpkg or conan (was: PDAL Windows debug configuration)

[Mateusz Loskot]

On 25 April 2018 at 13:24, Howard Butler <howard at hobu.co> wrote:
> On 4/25/18 3:27 AM, Mateusz Loskot wrote:
>> On 25 April 2018 at 10:24, Lars <laasunde at hotmail.com> wrote:
>>> Hello Odd Ragnar,
>>>
>>> Appreciate your feedback.
>>>
>>> The https://www.pdal.io/development/compilation/dependencies.html lists all
>>> of PDAL's dependencies which is quiet long.
>> You can iterate over run cmake - get dependency cmake complains about
>> - run cmake.
>> You can also try to build-install many of the dependencies (also debug builds)
>> from the vcpkg [1] packages, including GDAL 2.2
>
> Mat,
>
> Is vcpkg the thing we should be investing in for post-OSGeo4W Windows
> packages and packaging?

Howard,

This is strategically quite a heavy question and short answer is: I
don't know :-)

> The ecosystem is densely populated, and which
> one the community has gotten behind is not clear to someone like me who
> isn't plugged into Windows development.

Generally, the C++ ecosystem is slowly getting overloaded with
packaging options:
conan, vcpkg, build2 to name a few [1]

>From what I've observed, conan and vcpkg have gost picked by largest
communities.

I have used both, but not for long enough period to give thorough comparison.
The vcpkg FAQ [1] includes a short comparison - which by the way spawned
a long discussion [3] between the two camps. For a CMake-based project,
using both to pull dependencies is very easy and even semi-automatic.

I only developed or patched packages for vcpkg and I found the process
quite simple.

Some of my random thoughts about the two:
- conan is multiplatform from beginning of its time
- vcpkg has just become multiplatform: Windows, Linux, OSX [4] or FreeBSD [5]
- conan targets precompiled binaries with complementary `conan install --build`
- vcpkg targets installation from sources
- both support optimised and debug configurations
- conan seems to prefer/rely on community of package maintainers, so
it might have larger community
- vcpkg has smaller community around, I think
- both have largish compilers behind ;-)
- vcpkg uses CMake, portfile.cmake
- conan uses Python, conanfile.py
- vcpkg idea of single 'platform' version with support for multiple
installations/integrations (eg. per project) is something I like [6]
- conan puts local cache in %USERPROFILE%\.conan, at least that's what
I see by default
- vcpkg can offer always one libpng package (w/ configuration
triplets: arch, platform, etc.), I like it :)
- conan can offer multiple libpng packages
- vcpkg is more like system package management, or OSGeo4W, where
every accepted package is official
- conan seems to me like ArchLinux AUR - easy to find N packages of
the same library, which one to install?
- vcpkg install is just copying files, vcpkg export can zip
binaries/headers so you can share with team members
- vcpkg respects CMake target names as defined by CMake modules of a project
- conan seems to always generate custom CONAN_PKG::PkgName, so for
find_package(PNG)
we get
target_link_libraries(myapp PRIVATE PNG::PNG)
vs
target_link_libraries(myapp PRIVATE CONAN_PKG::libpng)

Finally, what you probably can guess, I find the vcpkg idea/design
simpler, easier to grasp,
docs are shorter, I find those as important traits from perspective of
ad-hoc use/contributions.

> I would much rather be putting our Windows packaging effort into
> something that's Windows-wide rather than OSGeo4W-wide,
> especially because OSGeo4W packages stale to the point of unusability.

Looking beyond OSGeo4W and towards more generic C++ package
ecosystems seems a good idea, I think.

> I know that Windows packaging has improved over recent years, but I
> don't have enough experience on the topic to know where to invest PDAL's
> limited resources to fall in line.

Since both, conan and vcpkg support multiple platforms, it is no longer
Windows only question.

There is lots of questions regarding which strategy to choose.
>From my perspective, that is a development-oriented consumer:
- system packages (eg. deb, rpm) are always behind
- PPA are often left unmaintained
- both, are too tight to particular OS/distribution release.
- packaging for systems and distributions means very steep learning curve
and numberof 'beaurocracy' requirements to fulfil ;-)

conan and vcpkg come with this cool freedom that let me as consumer
inluence the state of the package with
- vcpkg: simple GitHub PR
- conan: same or upload my own package (ArchLinux AUR mode)

That was lots of thoughts dumped and to get back to the business,
I would be willing to help and prototype the vcpkg package for PDAL.
If someone could go for package for conan, then we can compare efforts
and results, and see which is preferred to be officially maintained.
Perhaps both, who knows ;)


[1] http://pfultz2.com/blog/2017/10/27/universal-package-manager/
[2] https://github.com/Microsoft/vcpkg/blob/master/docs/about/faq.md
[3] https://github.com/Microsoft/vcpkg/issues/478
[4] https://blogs.msdn.microsoft.com/vcblog/2018/04/24/announcing-a-single-c-library-manager-for-linux-macos-and-windows-vcpkg/
[5] https://github.com/qis/windows-10/blob/master/vcpkg.md
[6] https://github.com/Microsoft/vcpkg/issues/3052#issuecomment-373727187

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net