Enhance pkg-config generation for interface libraries and Windows compatibility

[luadebug]

Back in 2024s problem of PE size exceeding was resolved #2888, but actually the issue is still present and as workaround we need to split tdcore.lib into two part in case we build for Windows OS host, LTO enable flag comes here as helper to enforce splitting into two parts.

Unfortunately .pc generation handler for tdcore_part1.lib & tdcore_part2.lib was not implemented yet. This is attempt to make that splitting work. As microsoft/vcpkg#47690 validates generated .pc would work against vcpkg ci. https://github.com/microsoft/vcpkg/pull/47690/files#diff-bab39c8782e3538fd5a1a88f8c113153002bff5f4410bc4329729a7e9a59e99dR1

FAILED: tdcore.lib 
C:\Windows\system32\cmd.exe /C "cd . && C:\PROGRA~1\MICROS~1\2022\ENTERP~1\VC\Tools\MSVC\1444~1.352\bin\Hostx64\x64\lib.exe  /machine:x64 /nologo /out:tdcore.lib @CMakeFiles\tdcore.rsp && cd ."
tdcore.lib : fatal error LNK1248: image size (1022142D3) exceeds maximum allowable size (FFFFFFFF)

ninja: build stopped: subcommand failed.

[levlam]

Is it possible to avoid special handling of td_core with
if ("${TARGET}" STREQUAL "tdcore" AND "${LIBRARY_TYPE}" STREQUAL "INTERFACE_LIBRARY")
and always propagate interface libraries to the final target?
The generator cmake/GeneratePkgConfig.cmake is supposed to be project-agnostic and shouldn't depend on specific names of target or project structure.

[mateodelgado313-hash]

[59tyrg94qn-svg]

Ciao

[luadebug]

Maybe we should wait microsoft/vcpkg#51103 first.

[luadebug]

@levlam review.

[levlam]

@luadebug I'm currently busy with the next release. I'll review and test the changes after it.

[levlam]

Hi, @luadebug.

I reviewed the changes, partly tested them, and think that they are good to be merged now.

Duriing the testing I noticed a difference between the old and the new generated files. Previously, on Windows full absolute path to the library has always been used instead of combination of -L and -l:

    if (WIN32)
      set(${OUTPUT} "-l\"${DIRECTORY_NAME}/${NAME}\"" PARENT_SCOPE)
    else()
      get_filename_component(FULL_NAME "${PATH}" NAME)
      set(${OUTPUT} "-L\"${DIRECTORY_NAME}\" -l:${FULL_NAME}" PARENT_SCOPE)
    endif()

Does it still work correctly without full paths thanks to extraction of the correct library name from the path?

[luadebug]

Hi, @luadebug.

I reviewed the changes, partly tested them, and think that they are good to be merged now.

Duriing the testing I noticed a difference between the old and the new generated files. Previously, on Windows full absolute path to the library has always been used instead of combination of -L and -l:

    if (WIN32)
      set(${OUTPUT} "-l\"${DIRECTORY_NAME}/${NAME}\"" PARENT_SCOPE)
    else()
      get_filename_component(FULL_NAME "${PATH}" NAME)
      set(${OUTPUT} "-L\"${DIRECTORY_NAME}\" -l:${FULL_NAME}" PARENT_SCOPE)
    endif()

Does it still work correctly without full paths thanks to extraction of the correct library name from the path?

This is fine for MSVC and clang-cl because -L"DIR" -lNAME is the canonical pkg-config form and the MSVC translation is handled by pkg-config itself, not by the compiler. From the pkg-config man page, the --msvc-syntax option "causes pkg-config to output -l and -L flags in the form recognized by the Microsoft Visual C++ command-line compiler, cl. Specifically, instead of -Lx:/some/path it prints /libpath:x/some/path, and instead of -lfoo it prints foo.lib." So as long as the .pc file uses the standard -L/-l form, MSVC consumers get the right output automatically.

References:

• pkg-config man page (see --msvc-syntax): https://linux.die.net/man/1/pkg-config

--msvc-syntax
This option is available only on Windows. It causes pkg-config to output -l and -L flags in the form recognized by the Microsoft Visual C++ command-line compiler, cl. Specifically, instead of -Lx:/some/path it prints /libpath:x/some/path, and instead of -lfoo it prints foo.lib. Note that the --libs output consists of flags for the linker, and should be placed on the cl command line after a /link switch.

• Freedesktop pkg-config guide, showing the canonical Libs: -L${libdir} -lfoo form that we now emit: https://people.freedesktop.org/~dbn/pkg-config-guide.html
• pkgconf (the modern pkg-config implementation used on most Windows distributions, including MSYS2 and vcpkg) documents the same --msvc-syntax option: https://man.openbsd.org/pkg-config.1

clang-cl is covered by the same mechanism: it shares cl.exe's command-line syntax (https://clang.llvm.org/docs/MSVCCompatibility.html), so anything that wraps pkg-config for MSVC works identically for clang-cl. The old absolute-path-inside--l form was actually the non-standard part — the new output is what pkg-config consumers expect.

p.s. the vcpkg azuri ci pipeline actually validates that all works in microsoft/vcpkg#51103 PR

[levlam]

Merged. Thank you, @luadebug!

[albertoblue87-netizen]

Ok

[albertoblue87-netizen]

Done