Developer/Packager RFC - Use GNU standardized layout

Get help with compiling or installing the game, and discuss announcements of new official releases.

Moderators: Forum Moderators, Developers

Post Reply
Posts: 357
Joined: April 24th, 2016, 4:18 pm

Developer/Packager RFC - Use GNU standardized layout

Post by Tad_Carlucci » November 1st, 2017, 10:37 pm

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.
I forked real life and now I'm getting merge conflicts.

User avatar
Forum Administrator
Posts: 3696
Joined: March 22nd, 2009, 10:50 pm
Location: Earth (occasionally)

Re: Developer/Packager RFC - Use GNU standardized layout

Post by Pentarctagon » November 2nd, 2017, 12:43 am

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

Posts: 357
Joined: April 24th, 2016, 4:18 pm

Re: Developer/Packager RFC - Use GNU standardized layout

Post by Tad_Carlucci » November 2nd, 2017, 5:16 am

The PR has the following commit comment:

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.
CMake documentation states:
Define GNU standard installation directories

Provides install directory variables as defined by the GNU Coding Standards.
Which linked page begins by stating:
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.
Which then proceeds to define quite a list of variables.

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.

Post Reply