[libvhdi] Initial Port

[TomKatom]

• Changes comply with the maintainer guide
• The name of the port matches an existing name for this component on https://repology.org/ if possible, and/or is strongly associated with that component on search engines.
• Optional dependencies are resolved in exactly one way. For example, if the component is built with CMake, all find_package calls are REQUIRED, are satisfied by vcpkg.json's declared dependencies, or disabled with CMAKE_DISABLE_FIND_PACKAGE_Xxx
• The versioning scheme in vcpkg.json matches what upstream says.
• The license declaration in vcpkg.json matches what upstream says.
• The installed as the "copyright" file matches what upstream says.
• The source code of the component installed comes from an authoritative source.
• The generated "usage text" is accurate. See adding-usage for context.
• The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
• Only one version is in the new port's versions file.
• Only one version is added to each modified port's versions file.

[TomKatom]

@microsoft-github-policy-service agree

@microsoft-github-policy-service agree

[dg0yt]

Why not just build with vcpkg_configure_make?

[TomKatom]

vcpkg_configure_make

It's preferred to use CMake when possible, this library is quite small so it is manageable to do so.
Also, it would make life easier when compiling for Windows and etc...

I took inspiration from the libvmdk port, its by the same library author so it's pretty much the same.
Although if you've got a better idea on how do this better I'm open to ideas.

Thanks,
Tom

[dg0yt]

It is preferred to use the build system maintained upstream.

[TomKatom]

It is preferred to use the build system maintained upstream.

Got it, now using autoconf and msbuild.

[dg0yt]

I still think it should use its native build system. Maybe even autotools for windows.

[dg0yt]

No, this isn't what you need.

[TomKatom]

Why do you think that? According to the libvhdi build requirements gettext is needed.

[dg0yt]

What is needed? libintl? gettext tools?

[dg0yt]

And often it can be disabled with autotools.

[dg0yt]

What is needed? libintl? gettext tools?

Still not answered.

[TomKatom]

I still think it should use its native build system. Maybe even autotools for windows.

The thing is, autotools is not the "native build system" for this library.
This library along with all the other libyal libraries (3 of them are ported in this exact same way already mind you) has a very odd windows compilation instructions which require running a custom python script to convert the vcproj files into vcxproj files for MSBuild compilation.

I'm open to suggestions on how to overcome that barrier and compile using MSBuild for windows and autotools for Unix, but as far as I am aware there's no simple way to build vcproj using vcpkg.
But the status quo for the libyal library suite ports is this solution so I think that just for consistency alone this cmake port is the way to go.

[dg0yt]

So for all platforms but MSVC, autotools is known to work. And for MSVC, we didn't try to use it.

[dg0yt]

Who cares about guidelines?
This port violates the guidelines also with regard to the exported CMake config. It must be moved to the unofficial namespace.
(I didn't want to review the CMake code before it is necessary.)

[dg0yt]

There are four ports now from https://github.com/libyal/: libpff, libqcow, libvmdk, libvhdi.
The individual git repos contain only specific code, but the tarball assets share extra subdirs which are actually other repos / tiny libs there.
Overview: https://github.com/libyal/libyal/wiki/Overview