[ffms2.pc.in] Add -DFFMS_STATIC to Cflags.private

[moi15moi]

This allow static consumers to automatically get the FFMS_STATIC flag needed for correct symbol handling. This affects only static linking, as intended.
Here is a bit more detail about Cflags.private: https://www.msys2.org/docs/pkgconfig/#cflagsprivate-static-libraries

Note that Cflags.private is only supported by pkgconf. The original pkg-config has an feature request about this: https://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues/38

[dwbuiten]

How does this behave with normal pkg-config? Is it ignored or does it cause an error?

Using non-standard pkg-config stuff seems iffy to me (pkg-config defines .pc, not pkgconf, IMO...)

[moi15moi]

I believe it ignore the flag, but i dont have any proof.
I dont know any distro that this use the original pkgconfig, so i cant test it.

@TheOneric Do you the answer to dwbuiten question?

[TheOneric]

pkg-config simply ignores the additional field.

For testing, e.g. Haiku or pkgsrc still provide the original pkg-config, but many distros dropped it by now since it is efffecively abandoned. There have been no commits in over 4 years and almost no responses from maintainers to issues or patches for years too. You can find e.g. my PR to implement Cflags.private support to pkg-config here with more info on the whole topic. In fact, pkg-config doesn't even build from git source with modern toolchains (this has been the case for years!).

There are also other, more niche pkg-config implementations from e.g. OpenBSD and projects independent of any distro. Otoh I cannot say whether they parse this field or not; I doubt they’ll error on it though.

I agree pkg-config introduced and defined the standard *.pc format and thus whatever it supports and does holds weight. However as also acknowledged in various discussions in their repo this format was never perfect and various avenues to improve upon where once discussed. Unfortunately, the project died before any of those improvements were realised. The underlying issues and needs of developers didn’ŧ go away though. Given the now unclear governance of the format, we’re unlikely to ever see any of the more major changes (to e.g. improve on mixed static/shared linking, etc). Smaller improvements like Cflags.private seem realistic to (slowly) propagate through all active implementations though.

In practice pkgonf is now the most influential implementation by virtue of its large user base. Whether intentional (by both developers using pc files and pkgconf devs) or not, its quirks and additions are likely to spread and become a defacto standard target imho. This is not ideal, but unfortunately how it is.
Cflags.private in particular is already widely used (see the pkg-config patch linked above for examples), thus any implementation completely breaking on it seems quite unlikely.