[pjproject] add new port

[ShahriyarB]

Closes #30391

• 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.

---

Installs PJPROJECT (PJSIP) library with its dependencies (ffmpeg, openssl, libvpx, sdl2, opus)

[dg0yt]

IMO source modifications should be implemented as patches as much as possible.

For getting flags and actual link libs for dependencies, you could use x_vcpkg_pkgconfig_get_modules.
When generating pkgconfig files, the dependencies should be named in Requires.private (or Requires) instead of spelling out the libs.

Given the unusual port structure and the dependency network, it might make sense to add a test port to scripts/test_ports. Examples are there, e.g. vcpkg-ci-libavif.

[dg0yt]

I think this sufficiently covered by the vcpkg's heuristical output. (The vcpkg explicitly decided against documenting how to consume pkgconfig in cmake. It doesn't work with multi-config anyways.)

[ShahriyarB]

Done in 683167f

[dg0yt]

Suggested change

	"supports": "(windows & !uwp) | mingw | linux",
	"supports": "linux | (windows & !uwp)",

windows includes mingw.

[ShahriyarB]

Done in f3ae18e

[dg0yt]

Suggested change

	{
	"name": "pkgconf",
	"host": true
	},

Use

vcpkg_find_acquire_program(PKGCONFIG)
set(ENV{PKG_CONFIG} "${PKGCONFIG}")

in the port file instead.

[ShahriyarB]

Removed pkgconf from vcpkg.json file, but in my tests it wasn't necessary to add

vcpkg_find_acquire_program(PKGCONFIG)
set(ENV{PKG_CONFIG} "${PKGCONFIG}")

to the port file since pkgconfig is getting pulled via vcpkg-pkgconfig-get-modules which is in vcpkg.json
Is there any other reason to put it there that I'm not aware of?

34cbf7e

[dg0yt]

vcpkg-pkgconfig-get-modules takes care of its own dependencies.

But what we have now is that at least the unix build relies on transitve dependencies with

set(ENV{PKG_CONFIG} "${CURRENT_HOST_INSTALLED_DIR}/tools/pkgconf/pkgconf")

This is fragile.

[ShahriyarB]

Thanks for clarification.
Done in cf51d74

[ShahriyarB]

IMO source modifications should be implemented as patches as much as possible.

For getting flags and actual link libs for dependencies, you could use x_vcpkg_pkgconfig_get_modules. When generating pkgconfig files, the dependencies should be named in Requires.private (or Requires) instead of spelling out the libs.

Given the unusual port structure and the dependency network, it might make sense to add a test port to scripts/test_ports. Examples are there, e.g. vcpkg-ci-libavif.

Done in the following commits

0fd6405 23668a4

[JavierMatosD]

@ShahriyarB, first, thank you for your contribution to the registry. We appreciate the effort you've put into this port. That said, the team made a few suggestions for the port.

For example, we noticed the port uses a highly factorized approach with multiple helper functions, and worry this will create a higher maintenance burden over time. The addition of a test port was appreciated, but, in our experience, we've found that simpler, more linear ports tend to be easier for the community to review and maintain. We suggest inlining the logic directly within the portfile.cmake, with the normal exceptions for patches and similar assets.

Additionally, we noticed the port adds pkgconfig support that upstream doesn't provide. We generally prefer to stick with upstream's build system choices to avoid diverging from what the library authors intended and to reduce maintenance over time. In this case, we'd suggest sticking with upstream's CMake build system for Windows and avoiding the pkgconfig additions that upstream doesn't currently support.

Thanks again!

[ShahriyarB]

@ShahriyarB, first, thank you for your contribution to the registry. We appreciate the effort you've put into this port. That said, the team made a few suggestions for the port.

For example, we noticed the port uses a highly factorized approach with multiple helper functions, and worry this will create a higher maintenance burden over time. The addition of a test port was appreciated, but, in our experience, we've found that simpler, more linear ports tend to be easier for the community to review and maintain. We suggest inlining the logic directly within the portfile.cmake, with the normal exceptions for patches and similar assets.

Additionally, we noticed the port adds pkgconfig support that upstream doesn't provide. We generally prefer to stick with upstream's build system choices to avoid diverging from what the library authors intended and to reduce maintenance over time. In this case, we'd suggest sticking with upstream's CMake build system for Windows and avoiding the pkgconfig additions that upstream doesn't currently support.

Thanks again!

Thanks for the review. I can make the change to move all logic into portfile.cmake. Regarding pkg-config support on Windows, the upstream project is not based on CMake, it provides a Makefile for Unix builds and a .sln file for Windows builds. I added this support so the port can be used in Visual Studio CMake projects on Windows; without it, the port would only work with Visual Studio .sln projects. This pkg-config support is required by one of my projects and is the main reason I created this port, so I would appreciate it if we can keep it.

[JavierMatosD]

the upstream project is not based on CMake
I see CMakeLists.txt throughout the repo -> https://github.com/pjsip/pjproject/blob/master/CMakeLists.txt
We prefer to use CMake over msbuild whenever possible.

This pkg-config support is required by one of my projects and is the main reason I created this port, so I would appreciate it if we can keep it.

Unfortunately, we are hesitant to add pkgconfig support that isn't native to upstream. That said, you are more than welcome to use overlay ports for your specific project. We encourage you to submit a PR with upstream to add pkgconfig support you need.

[ShahriyarB]

the upstream project is not based on CMake
I see CMakeLists.txt throughout the repo -> https://github.com/pjsip/pjproject/blob/master/CMakeLists.txt
We prefer to use CMake over msbuild whenever possible.

This pkg-config support is required by one of my projects and is the main reason I created this port, so I would appreciate it if we can keep it.

Unfortunately, we are hesitant to add pkgconfig support that isn't native to upstream. That said, you are more than welcome to use overlay ports for your specific project. We encourage you to submit a PR with upstream to add pkgconfig support you need.

It's funny that CMakeLists.txt just been added to upstream 17 hours ago! To a 20 years old project ... just when I decide to create a vcpkg port ...
Anyway, I'll try their newly created CMakeLists.txt to see if it works fine or not because they mentioned Building pjproject with CMake is experimental in their cmake file.

[ShahriyarB]

I just noticed that the CMakeLists.txt file is missing in the latest upstream release (currently 2.15.1). If we rely on their CMakeLists.txt, it would mean pulling directly from the upstream master branch in our port, which I don’t think is the right approach. Perhaps we should hold off until upstream publishes a new release and, in the meantime, continue using their Makefile and .sln. What do you think?

@JavierMatosD

[JavierMatosD]

Perhaps we should hold off until upstream publishes a new release and, in the meantime, continue using their Makefile and .sln. What do you think?

@JavierMatosD

That sounds reasonable to me!