Follow GNU conventions for installation #453
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
First of all, move Soter and Themis installation rules out from Makefile
to their individual makefiles. This makes them a bit easier to maintain.
After that, reduce installation targets to just "install",
"install_themis" and "install_soter" (plus "uninstall" counterparts).
No one should really be using individual targets to instally only some
parts of the library. And these targets are not really documented, and
are not standard.
Finally, adhere to GNU Makefile conventions [1] when installing files.
This encompasses multiple aspects:
- $(INSTALL), $(INSTALL_DATA), $(INSTALL_PROGRAM) variables
It's not strictly necessary, but nice to have. This allows
to override the tool for installing files, and makes sure that
data files are not marked executable.
- $(DESTDIR) prefix
This is an important variable for packaging as it allows staged
installation. It gets prefixed to each installation destination
so that it could be made into a temporary directory which will
get packaged later.
Note that this variable is never set explicitly in the Makefile
and is empty by default. It's also used only during installation,
the library is built as if it's going to be installed to the usual
location with DESTDIR preprended to it.
- $(prefix), $(includedir), $(libdir), etc. variables
These variables allow fine tuning of installation paths when
packaging for distributions that have varying conventions.
Most prominently, they affect the destination for libraries which
may be /lib, /usr/lib, /usr/lib64, /usr/lib/x86_64-linux-gnu, or
something else.
Note that it's lowercase "prefix", not uppercase "PREFIX". That's
how it should be by the book, but all our documentation uses the
capitalized version, so we keep it for compatibility.
This teaches our Makefile to play nicely with other tools that expect
GNU conventions to hold. Primarily, these are various package-building
tools that rely on the variables to interpose their helper tools and
override installation paths to distribution-specific places.
(We could have gotten all of that automatically by using Autotools, but
no one really knows Autotools nowadays. Even these GNU conventions are
arcane knowledge in the days of "curl | sudo sh" and every language
having their own package manager.)
[1]: https://www.gnu.org/prep/standards/html_node/Makefile-Conventions.html
First of all, there are quite a few ThemisPP-specific rules in the main Makefile. Move them all into a separate one, just for ThemisPP. After that, update ThemisPP installation targets to follow the same conventions as for Soter and Themis.
ilammy
force-pushed
the
ilammy/gnu-install
branch
from
a5a0c70
to
3754248
Compare
ilammy
added
infrastructure
|
Ready for review now. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
First of all, move Soter and Themis installation rules out from Makefile to their individual makefiles. This makes them a bit easier to maintain.
After that, reduce installation targets to just
install,install_themisandinstall_soter(plusuninstallcounterparts). No one should really be using individual targets to install only some parts of the library. These targets are not really documented, and are not standard.Adhere to GNU Makefile conventions when installing files. This encompasses multiple aspects:
INSTALL,INSTALL_DATA,INSTALL_PROGRAMvariablesIt's not strictly necessary, but nice to have. This allows to override the tool for installing files, and makes sure that data files are not marked executable.
DESTDIRprefixThis is an important variable for packaging as it allows staged installation. It gets prefixed to each installation destination so that it could be made into a temporary directory which will get packaged later.
Note that this variable is never set explicitly in the Makefile and is empty by default. It's also used only during installation, the library is built as if it's going to be installed to the usual location with DESTDIR preprended to it.
prefix,includedir,libdir, etc. variablesThese variables allow fine tuning of installation paths when packaging for distributions that have varying conventions. Most prominently, they affect the destination for libraries which may be
/lib,/usr/lib,/usr/lib64,/usr/lib/x86_64-linux-gnu, or something else.Note that it's lowercase
prefix, not uppercasePREFIX. That's how it should be by the book, but all our documentation uses the capitalized version, so we keep it for compatibility.This teaches our Makefile to play nicely with other tools that expect GNU conventions to hold. Primarily, these are various package-building tools that rely on the variables to interpose their helper tools and override installation paths to distribution-specific places.
(We could have gotten all of that automatically by using Autotools, but no one really knows Autotools nowadays. Even these GNU conventions are arcane knowledge in the days of "curl | sudo sh" and every language having their own package manager.)
Now, there are quite a few ThemisPP-specific rules in the main Makefile. Move them all into a separate one, just for ThemisPP.
After that, update ThemisPP installation targets to follow the same conventions as for Soter and Themis.