add pkg-config support

[trabucayre]

One classic way to detect and to obtain required parameters at build time requirements, to use a library, is through pkg-config.
This approach allows to fill FLAGS and LIBS with respect of dependencies (in this specific case liberror, common and libusb1)
This approach is Linux and msys2 compatible.
This PR add a pc.in file filled with prefix and all required informations, this one is installed in ${CMAKE_INSTALL_LIBDIR}/pkgconfig

[makestuff]

I'm a bit reluctant to add a lot more config to the library-level CMakeLists.txt files (i.e replicated across many repos) unless it aids the default way to build, with tools available by default, on both Linux and Windows. For example, the top-level fpgalink project builds on a vanilla Windows machine with VS2017 installed. With the change to get Linux libraries installed in /usr/local, it's possible to build an application with CMake very easily, without having to git-submodule the libfpgalink source, etc. I acknowledge that doing the same on Windows is tricky because Windows has no notion of standard install locations. My understanding is that the canonical way to fix that with CMake is the find_package() thing.

[trabucayre]

pkg-config has many advantages:

• not limited to cmake (works with make too)
• provides -I/somewhere and -L/somewhere -lmylib (with mylib required dependencies)

For example with libusbwrap:

gwe@x230 $ pkg-config --cflags libusbwrap                                                                                
-I/usr/include -I/usr/include/libusb-1.0
gwe@x230 $ pkg-config --libs libusbwrap                                                                                   
-L/usr/local/fpgalink/lib64 -lerror -lusb-1.0

So just with libusbwrap I everything required (libusbwrap AND libusb1) to build an application using this library.
According to @umarcor this way is compatible with msys2 too.

[makestuff]

I don't want to support any build tool except cmake. Otherwise where does it stop? Someone wants Bazel support, someone else wants NMAKE support, Premake support, Ninja support, or whatever. Could you create a separate repo which has git submodules for libfpgalink and its dependencies, which installs the pkgconfig stuff you need?

[umarcor]

I'm a bit reluctant to add a lot more config to the library-level (..) unless it aids the default way to build, with tools available by default, on both Linux and Windows. For example, the top-level fpgalink project builds on a vanilla Windows machine with VS2017 installed.

@makestuff I beg to disagree, as I find these two sentences contradictory between them, and with the licensing of this project. VS2017 is not available by default on Windows; AFAIAA it cannot be freely downloaded and installed; and it is not free or open source software. On the other hand, MSYS2 is the most used environment for providing open source EDA tooling on Windows, either explicitly or implicitly. The MSYS2 installer takes 90 MB and it can be freely downloaded. MSYS2 is free and open source software. Binaries built on MSYS2 are native Windows binaries/DLLs so it's possible to distribute the tools to be used outside of MSYS2. That is the case of https://github.com/YosysHQ/fpga-toolchain.

I acknowledge that doing the same on Windows is tricky because Windows has no notion of standard install locations.

In MSYS2, there is an standard location for libraries $MINGW_PREFIX/bin, and it's added to the PATH. Hence, there is the notion of a standard install location, just as in Unix. The motto of MSYS2 is for developers to build as if they were in a Unix environment, but generate native Windows binaries without any extra dependency.

Overall, I think it is legit to support a single build procedure in some project. At the same time, I must say I didn't dive deeply into the set of changes that will be required in newer versions of openFPGALoader. However, it feels to me that the modifications in this PR are not related to how to build this project, but about how to use it after it is installed. Since it is a library, I would expect making it easier for other projects to link against it.

Could you create a separate repo which has git submodules for libfpgalink and its dependencies, which installs the pkgconfig stuff you need?

I don't think this is desirable as a general approach. Build sources are typically located either within the project repository, or in package recipes (which might include patches). Therefore, suggesting to create a separate repo implies suggesting that each packager for each distribution might need to repeat the same fixes. It is sensible to evaluate when changes are specific to one packaging system or when can be used by many. pkg-config can be potentially used in Debian/Ubuntu/Mint, RedHat/Fedora, Arch/Manjaro, MSYS2... I don't think it's comparable to Bazel or Ninja.

Nevertheless, I'm not sure about this PR being useful in the given state. It seems that it only contains default locations, and the only additional option is lerror. Therefore, packagers that install this library using the regular cmake procedure should not need those files. At the same time, packagers using custom locations can easily create those files, since it is not more complex than actually providing the parameters at build time. @trabucayre, am I wrong? Is the Requires field used or is it metadata?

[trabucayre]

@umarcor I'm totally agree. Having to create and maintain a more or less a fork of fpgalink repository is totally overkill. I have already many thing to do to have to worry about this type of task.
pkg-config is, in my mind, a elegant way to limit the complexity to link an application to an library, without having to manage proper dependencies, include and lib directories and library name (static, dynamic for linux and windows).
This PR is enough to link an application (or a library) to libusbwrap. All variable with @ are automatically replaced by cmake to the corresponding value, thanks to that, values match CMAKE_INSTALL_PREFIX base.
Requires is used by pkg-config to know dependencies and fill ldflags (for example) with -l for this libary but also with -l for libraries needed by libusbwrap.
This why when you do:

 pkg-config --libs libftdi1

the answer is

-lftdi1 -lusb-1.0

because libftdi needs libusb

To be able to link an application to libfpgalink I need to create others PR in others repository, but since @makestuff seems not happy, I've delayed until a go / nogo.

[umarcor]

@trabucayre, thanks for clarifying the usefulness of Requires. I had used projects which called pkg-config before, but I did not actually dive into it.
That being the case, I do think this PR is sensible and not specific to a niche packaging approach.

[trabucayre]

My goal with this PR (and similars PR in others repositories) is not specifically dedicated to my need (openFPGALoader) but it's to provides a way for everyone to have a easy way to link an application or a library to fpgalink.