Developer/Packager RFC - Use GNU standardized layout
Moderator: Forum Moderators
-
- Inactive Developer
- Posts: 503
- Joined: April 24th, 2016, 4:18 pm
Developer/Packager RFC - Use GNU standardized layout
I have been assigned a Pull Request from a Gentoo package maintainer to change CMake to use the standard GNU file-system layout, along with other changes to the CMake configuration.
Most of these changes are internal to the CMake configuration and present no issues.
During initial testing of the original Pull Request I noted that, during an in-tree build, the compiled localization text was moved from the ~wesnoth/translations directory to the ~wesnoth/po directory. This means the source and compiled versions of locale text appears in the same directory. Conceptually, when building out-of-tree this simply means changing the translations directory name to po; but for in-tree it means picking apart the po directory to obtain the deliverable files and omit the original sources.
This raises the question: Should Wesnoth's build systems (SCons and CMake) change to use the GNU common file-system layout?
I am seeking responses from Developers and Packagers, especially those targeting Linux, on these changes.
Would the translations layout changes cause problems?
Would switching to the GNU common file-system layout make your packaging process simpler, cleaner, or easier?
Or would this simply cause a bit of work for you, adjusting to the changes, for no positive effect?
The current goal is to produce 1.14 RC1 mid-month. If there does not appear to be sufficient call for the file-system layout changes in the next week or so (before we freeze for the release), I will decline the file-system layout changes and proceed with a few internal, unrelated, CMake and SCons changes.
Most of these changes are internal to the CMake configuration and present no issues.
During initial testing of the original Pull Request I noted that, during an in-tree build, the compiled localization text was moved from the ~wesnoth/translations directory to the ~wesnoth/po directory. This means the source and compiled versions of locale text appears in the same directory. Conceptually, when building out-of-tree this simply means changing the translations directory name to po; but for in-tree it means picking apart the po directory to obtain the deliverable files and omit the original sources.
This raises the question: Should Wesnoth's build systems (SCons and CMake) change to use the GNU common file-system layout?
I am seeking responses from Developers and Packagers, especially those targeting Linux, on these changes.
Would the translations layout changes cause problems?
Would switching to the GNU common file-system layout make your packaging process simpler, cleaner, or easier?
Or would this simply cause a bit of work for you, adjusting to the changes, for no positive effect?
The current goal is to produce 1.14 RC1 mid-month. If there does not appear to be sufficient call for the file-system layout changes in the next week or so (before we freeze for the release), I will decline the file-system layout changes and proceed with a few internal, unrelated, CMake and SCons changes.
I forked real life and now I'm getting merge conflicts.
- Pentarctagon
- Project Manager
- Posts: 5564
- Joined: March 22nd, 2009, 10:50 pm
- Location: Earth (occasionally)
Re: Developer/Packager RFC - Use GNU standardized layout
What is the GNU common file-system layout? Googling that only returned this thread as a result.
99 little bugs in the code, 99 little bugs
take one down, patch it around
-2,147,483,648 little bugs in the code
take one down, patch it around
-2,147,483,648 little bugs in the code
-
- Inactive Developer
- Posts: 503
- Joined: April 24th, 2016, 4:18 pm
Re: Developer/Packager RFC - Use GNU standardized layout
The PR has the following commit comment:
CMake documentation states:
I've not exhaustively examined the list to see if it's an actual change from what we're presently doing, nor looked up "Kitware" (never heard of it), nor do I know if the "most distributions" claim it correct, nor have I examined if the in-tree and out-of-tree layout changes were moved by the GNUInstallDirs option or were an avoidable change (they seemed to be changed by the CMake macro and not the PR but I might have missed something).
Frankly, I think this is all too much hassle and, personally, would forget it. But if the consensus among packagers or developers with more experience at this think it's A Good Thing, I'll clean it up and commit it.
Code: Select all
Use GNUInstallDirs to specify directories
* GNUInstallDirs is the only Kitware-supported
way to change the default directories. Most
distributions have hooks for changing these
directories, which makes integrating wesnoth
easier and more consistent with the rest of
the CMake ecosystem.
* Make build system perfectly out-of-source
compatible. The build system should never
touch files in the source tree.
Which linked page begins by stating:GNUInstallDirs
Define GNU standard installation directories
Provides install directory variables as defined by the GNU Coding Standards.
Which then proceeds to define quite a list of variables.7.2.5 Variables for Installation Directories
Installation directories should always be named by variables, so it is easy to install in a nonstandard place. The standard names for these variables and the values they should have in GNU packages are described below. They are based on a standard file system layout; variants of it are used in GNU/Linux and other modern operating systems.
Installers are expected to override these values when calling make (e.g., make prefix=/usr install) or configure (e.g., configure --prefix=/usr). GNU packages should not try to guess which value should be appropriate for these variables on the system they are being installed onto: use the default settings specified here so that all GNU packages behave identically, allowing the installer to achieve any desired layout.
I've not exhaustively examined the list to see if it's an actual change from what we're presently doing, nor looked up "Kitware" (never heard of it), nor do I know if the "most distributions" claim it correct, nor have I examined if the in-tree and out-of-tree layout changes were moved by the GNUInstallDirs option or were an avoidable change (they seemed to be changed by the CMake macro and not the PR but I might have missed something).
Frankly, I think this is all too much hassle and, personally, would forget it. But if the consensus among packagers or developers with more experience at this think it's A Good Thing, I'll clean it up and commit it.
I forked real life and now I'm getting merge conflicts.