[libmem] add new port

[luadebug]

https://github.com/rdbo/libmem
It should be DLL or LIB.

• No vcpkg_from_git.
• Use vcpkg ports as dependencies.
• Let vcpkg control the flags.
• Remove the corresponding include(), overwrite it with an empty string, or remove the CMAKE_GENERATOR lines.
• The GENERATOR option should probably just be removed (which selects the Ninja generator).
• PreLoad.cmake overwrite it with an empty string.
• set(CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS ON) is removed & followed upstream by rdbo/libmem@04830fb as patch.
• INTERFACE $<INSTALL_INTERFACE:include>is applied.
• vcpkg_from_github uses REF ${VERSION} as param.
• Port build time is simplified from 1.5h to 2m by using bundled LLVM module of Demangler.
• Upstream`s CMakeLists.txt is being patched now, port goes to be official.
• In addition, using imported targets mandates find_dependency in exported config.
• Use vcpkg_find_acquire_program(PKGCONFIG), and pass it to CMake with "-DPKG_CONFIG_EXECUTABLE=${PKGCONFIG}".
• Redundant Findcapstone.cmake was removed.
• Upstream`s patch content CMakeLists.txt is trimmed.
• Rely over pkgconfigs keystone.
• Tests are persist disabled by default.
• Fix .cmake.in

[luadebug]

@microsoft-github-policy-service agree

[dg0yt]

This will need many changes.

• No vcpkg_from_git
• Use vcpkg ports as dependencies.
• Let vcpkg control the flags.

Does it really have to use nmake? This limits the port to Windows hosts.

[luadebug]

This will need many changes.

* No `vcpkg_from_git`

* Use vcpkg ports as dependencies.

* Let vcpkg control the flags.

Does it really have to use nmake? This limits the port to Windows hosts.

• No vcpkg_from_git - Done.
• Use vcpkg ports as dependencies. - Done, but I wish I do not compile WHOLE LLVM dependency. I need only Demangle.
• We need define LM_EXPORT in case we build static LIB for Windows OS.
  Not really, it should work for Linux OS as well, so I enforce NMake only in case of Windows OS build.
  Should something like this being used? Most likely LLVM would conflict about it.

if(VCPKG_TARGET_IS_WINDOWS AND VCPKG_CRT_LINKAGE STREQUAL "static")
    list(APPEND ADDITIONAL_OPTIONS
        -DITK_MSVC_STATIC_RUNTIME_LIBRARY=ON
        -DITK_MSVC_STATIC_CRT=ON
    )
endif()

Maybe I should enforce Unix Makefiles generator for x64-osx ?

[luadebug]

I tried to fix vcpkg.json for LLVM but it did not work, it just fallback to default features of LLVM package.

[dg0yt]

I tried to fix vcpkg.json for LLVM but it did not work, it just fallback to default features of LLVM package.

In a port manifest, default-features is just an enabler (but useful!). The actual control comes from the top-level install request, which is either the command line (classic mode) or top-level manifest (manifest mode).

[luadebug]

Regarding 0001-CMakeLists.patch, please avoid adding large blocks of empty lines. Also, if you want to remove a continuous block of code, you can wrap it with:

if(0)
...
endif()

This will help reduce the size of the corresponding patch.

Done.
Most likely some rework with ports/libmem/Findkeystone.cmake & ports/libmem/portfile.cmake still required.

[luadebug]

Seems working as expected, tested over x86-windows.
Now relying over pkgconfig's keystone.

[luadebug]

If there still need changes feel free to review.

[Cheney-W]

I got below error when I test the usage of libmem:x64-windows-static:

CMake Error at E:/VS2022/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/share/cmake-3.29/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
1> [CMake]   Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE)

[luadebug]

We could go for Findkeystone.cmake.
Or either you could try to download msys64 and try again.

[luadebug]

I don't know why it didn't install pkgconfig during vcpkg_find_acquire_program(PKGCONFIG) call though.

[dg0yt]

We could go for Findkeystone.cmake.

The module you had didn't solve the problem but just added a layer of indirection. (#41345 (comment)).
To avoid requiring pkgconfig downstream, don't use the imported target from pkg_check_modules but <prefix>_LINK_LIBRARIES.

I don't know why it didn't install pkgconfig during vcpkg_find_acquire_program(PKGCONFIG) call though.

It does, when building libmem. That's why building succeeds.

The problem occurs when using libmem (exported config).

[luadebug]

We could go for Findkeystone.cmake.

The module you had didn't solve the problem but just added a layer of indirection. (#41345 (comment)).
To avoid requiring pkgconfig downstream, don't use the imported target from pkg_check_modules but <prefix>_LINK_LIBRARIES.

I don't know why it didn't install pkgconfig during vcpkg_find_acquire_program(PKGCONFIG) call though.

It does, when building libmem. That's why building succeeds.

The problem occurs when using libmem (exported config).

Can you please provide more information about further changes that should be done @dg0yt ?

Do we need to remain everything as is and change .cmake.in file like this

@PACKAGE_INIT@ 
  
include(CMakeFindDependencyMacro) 
find_dependency(capstone CONFIG REQUIRED)

include("${CMAKE_CURRENT_LIST_DIR}/libmem-target.cmake")

set(INSTALLED_ROOT "${VCPKG_INSTALLED_DIR}/${VCPKG_TARGET_TRIPLET}")

set(KEYSTONE_LIBRARY_DIRS "${INSTALLED_ROOT}/lib")

set(KEYSTONE_INCLUDE_DIRS "${INSTALLED_ROOT}/include")

find_path(KEYSTONE_INCLUDE_DIR 
    NAMES keystone.h
    PATHS ${KEYSTONE_INCLUDE_DIRS}
    PATH_SUFFIXES keystone
    REQUIRED
)

find_library(KEYSTONE_LIBRARY_DEBUG 
    NAMES keystoned
    PATHS ${KEYSTONE_LIBRARY_DIRS}
    PATH_SUFFIXES debug
    REQUIRED
)

find_library(KEYSTONE_LIBRARY_RELEASE 
    NAMES keystone
    PATHS ${KEYSTONE_LIBRARY_DIRS}
    REQUIRED
)

include(SelectLibraryConfigurations)
select_library_configurations(keystone)

include(FindPackageHandleStandardArgs)
find_package_handle_standard_args(
    keystone
    REQUIRED_VARS KEYSTONE_LIBRARY KEYSTONE_INCLUDE_DIR
)

target_link_libraries(libmem::libmem INTERFACE capstone::capstone ${KEYSTONE_LIBRARY})
#This line is redundant because we already have required dependencies
#check_required_components(libmem)

Or I need to copy paste keystone search mechanics into CMakeLists.txt as well & link against found keystone?

[dg0yt]

If you do the right thing in CMakeLists.txt, you need do nothing in the exported cmake config.

[luadebug]

It's success over static builds but fails over dynamic builds due keystone linkage as for my side & as azure CI side.
@dg0yt should we try some another variables instead of keystone_LINK_LIBRARIES?