[CMake] generate pkg-config flatbuffers.pc file

[mpoquet]

This PR enables CMake to generate a flatbuffers.pc file on install, so end users can find the flatbuffers library.

pkg-config eases the utilization of software libraries by enabling the developers of a library to define how the library should be used.

It can be used as a tool by build systems to find and manage dependencies, this is notably the default Meson behavior and optionally used by CMake.

---

I Tested that the generated flatbuffers.pc was valid:

• On the supplied commit 322a90d
  • By manually building/installing flatbuffers via Cmake, in a shell with cmake-3.14.5, then inspecting flatbuffers.pc manually.
  • In a Nix setup where flatbuffers is used by my external library — flatbuffers is found by Meson via pkg-config. Everything builds/runs correctly.
• On top of last release v1.12.0, applying only 7e4124d and 322a90d as patches
  • In a Nix setup where flatbuffers is used by my external library — flatbuffers is found by Meson via pkg-config. Everything builds/runs correctly.

[aardappel]

You forgot to mention which os/platform(s) need this file, and to do what :)

[mpoquet]

Oops :p. Strictly speaking this support is not needed by any platform, this is an improvement of the packaging/distribution of flatbuffers. Packages often contain pkg-config files in most Linux distros (examples below) and are used by build systems to externalize library retrieval and use. Personally I need pkg-config to find the flatbuffers C++ library to build my tools using Meson+Nix, which will enable me to deploy my tools on Linux and macOS.

Here are debian packages of serialization libraries packaged with pkg-config files:

• libprotobuf-dev on debian (amd64 file list) — generated by these CMake lines
• libcapnp-dev on debian (amd64 file list) — generated by these CMake lines

[aardappel]

@vglavnyy opinion?

Note that in the case of FlatBuffers (moreso than Protobuf) distributing it thru linux distro packages is not great, since FlatBuffers depends heavily on flatc & runtime & generated code coming from the same version (commit), and distro packages being more long-lived things this easily creates problems. Ensuring you build flatc yourself as part of your CMake build is less error prone for example.

That said, not particularly for or against adding this file.

[vglavnyy]

@aardappel
I don't have an opinion. I've never used pkg-config.

Note that in the case of FlatBuffers (moreso than Protobuf) distributing it thru linux distro packages is not great

Ubuntu 20.04 already has flatbuffers packages.

[aardappel]

Ok, looks like we should just merge this and see :)
Thanks!

[aardappel]

This PR is now making our CI fail, because it generates different paths on different OSes: https://ci.appveyor.com/project/aardappel/flatbuffers/builds/38015947/job/9ne7publivh24q4p

Maybe simply turn off generating of this file on Windows, or non-*nix?

[vglavnyy]

I think the generated flatbuffers.pc should be removed from the version control.
Even on Linux, install paths might differ from the paths from the current flatbuffers.pc file.
For example, protobuf project has only the template file protobuf.pc.in like the CMake/flatbuffers.pc.in.
@mpoquet what do you think?

[mpoquet]

I also think that flatbuffers.pc should not be in the git tree as its content depends on where end users want to install flatbuffers. My commit added a flatbuffers.pc.in file instead, so that the build system (CMake here) can generate a flatbuffers.pc file with correct content at install time (depending on CMAKE_INSTALL_PREFIX or other finer-grain installation path CMake variables if they are set).