When running "make install" the destination of pkgconfig/openh264.pc and
lib/libopenh264.a was hard coded to "lib". When building packages it
might be required to change the install location of those files to
the systems default library location (like lib64 or lib/x86_64-linux-gnu
for example).
This commit adds an additional make variable "LIBDIR_NAME" that allows
it to change the destination directory for those files.
Without setting LIBDIR_NAME the installation location is the same as before
(lib).
- Generate version header in the build tree
- Generate .res file in the build tree on Windows
- Add the $(SRC_PATH) prefix to the .def files on Windows
Instead of repeating everything hardcoded with platform ifdefs,
use a common define BUILD_UT_EXE to define whether we should build
an executable or a library of the unit test suite. Later factorize
all other platform differences into smaller and simpler ifdefs.
If DESTDIR is set, it needs to include a trailing slash now.
This fixes "make install" on msys (i.e. on windows), where a path
starting with // is interpreted as a special network path.
When generating a new version of the header, that includes the
actual git hash, don't overwrite the file that is tracked by git.
Instead create a new file, and include this only if the build system
indicates that it exists (by setting a define). This allows the
untouched source tree to be built from within an IDE even if make
has not been run.
This reduces the hassle with a file that needs to be ignored in the
git configuration.
The downside is that the generated file isn't used if building
from within an IDE, if the header has been updated by calling make
before (since the IDE configuration doesn't know whether the user
actually has run make). Since users of the IDE might not build via
make in the command line at all (in the same source checkout at least),
this should not be an issue in practice. The previous way things worked,
the version hash (generated by make) when used in an IDE could actually
be outdated and misleading.
This is similar to how it is done in release mode already.
The fact that this behaviour differed between release and debug
can be traced back to commit cf92e8d6.
If only a static library is installed, the user of the library may
not know that only a static version of this particular library is
available (and doesn't know that --static should be added to the
pkg-config call). Therefore, one common practice is to include private
dependencies in the public Libs line if a static-only library is
installed.
This makes sure both "make libopenh264.so" and "make libopenh264.so.0"
work as intended.
Use the versionless name as dependency for the install rule,
to make sure both (if possible) are created.
This feels more straightforward - some file systems/environments
(such as MSys) implement symlinks as plain file copies, where
distinguishing whether a file is a link might be hard.
Prior to 3f69873c99, there already was a mechanism for installing
the import library, used for the MSVC builds. Use that for mingw
as well, instead of adding more hardcoded rules.
