Recommended way to expose port compile options to make

[sketch34]

We're beginning migration of a large makefile build system to cmake and establishing a standardized vcpkg+cmake build process for internal library projects going forward. For now the main build must remain make-driven.

Questions:

1. Is the "vcpkg way" to expose compile options to non-cmake builds to use pkg-config (assuming the port generates .pc files)?
2. Is there any standard fallback approach if a port doesn't support pkg-config?
   • Maybe sniff required values from the cmake cache or build.ninja for each port?

Structure:

Uber Makefile (builds all projects)
  Makefile Project A
  Makefile Project B
    * Depends on Makefile Project D
    * Depends on Internal Vcpkg Port X
    * Depends on External Vcpkg Port Y
  Makefile Project C
  ...
  Makefile Project Z

Goal:

# Makefile for Project B

# Add any required public interface compiler options, defines etc. for Vcpkg Port X and Y.
EXTRA_CXXFLAGS += <...>
EXTRA_LDFLAGS += <...>
EXTRA_CFLAGS += <...>
...

[Neumann-A]

I might want to have a look at #33198. The general way is to call vcpkg_get_cmake_vars (from port vcpkg-cmake-get-vars) which creates a bunch of files which can be included to get a bunch of variables from cmake. You then can use those variables to correctly setup your environment.

compile options to non-cmake builds to use pkg-config

the non cmake build should already use pkg-config. If everything else has pc files than it is just a matter of setting up pkg-config paths. as done by all ports using pkg-config. But there is also the port vcpkg-pkgconfig-get-modules if you need the info in the portfile itself.

Maybe sniff required values from the cmake cache or build.ninja for each port?

No. Just generate a working pc file to move forward. Otherwise you are in find_library hell as qt5-base does.

You can forward options to direct dependent ports using vcpkg-port-config.cmake

[sketch34]

Thanks! While I study those functions I want to check I understand a couple of things...

Just generate a working pc file to move forward.

Do you mean that if my makefile project wants to consume some vcpkg port A, and A does not generate pc files, then I should somehow manually add pkg-config support for A?

the non cmake build should already use pkg-config.

I don't understand this part. My large makefile project is pure make, neither it nor any of its many makefile sub-projects are using pkg-config.

I don't think I was clear enough, updated the question to clarify.

[Neumann-A]

Do you mean that if my makefile project wants to consume some vcpkg port A, and A does not generate pc files, then I should somehow manually add pkg-config support for A?

I was more speaking about your own projects. The problem is if there is no pc file usage is kind of in the air and manually linking is in general suboptimal but possible

nor any of its many makefile sub-projects are using pkg-config.

That is a problem since that often means every library name is hardcoded. As soon as the library name is different from what is expected or you have transitive deps your build breaks. That is why it is preferred to use pkg-config in the first place.