[GNC-dev] Documentation update problems

[Geert Janssens]

Op woensdag 19 september 2018 23:51:35 CEST schreef David Cousens:
> John, Geert, Adrien, David
> 
> Thanks for all the prespectives. I will attempt a restructure of the
> Building Gnucash page and its derivatives, trying to push as much
> information back to the generic Linux level as I can from the
> BuildingUbuntu 16.04 pages. I have no experience of building on Windows or
> MacOS X so I will definitely leave that to someone else. I'll start with
> Geert's comments as an overall plan and try to address the rest of your
> comments. I can set VMs up for the other distros so I can check them out a
> bit better
> 
Great!

> With the dependencies I compiled as complete a list as I was able to from my
> own experience and other users experiences when a lot of people were
> building v3.0-3.2 as it wasn't available from the distros. . I had a clean
> Linux Mint install at the time I did that so I captured a few that are
> usually already installed once you get a bit of other software on board.

Didn't apt-get build-dep gnucash install most of the dependencies already ?

I think it's nice to have an overview of the real dependencies, but probably 
rather as background information than as a build recipe. These could then 
become slightly more generic by using normal library names instead of package 
names. And it appears we have such a page already, though it may need review:
https://wiki.gnucash.org/wiki/Dependencies
Another opportunity for deduplication.

> Some distros do seem to use slightly different names for some libraries and
> headers so perhaps a warning to check your own distros naming using the
> equivalent of apt-cache search.
Good idea. FYI on fedora you can use "dnf search" for the same. I don't know 
what other package managers support (Arch uses pacman, Sabayon uses equo, 
OpenSuse uses or used to use yast,...)

> I'll do as much as I can from the online
> documentation for the other distros. I  I'll have a closer look and if I
> can get away perhaps with a subsitute "dnf" and "yum"and "apt" for apt-get
> as a note along the lines if compiling on xxx subsitute yyy for apt-get in
> the following.

I fear that will quickly get hairy. It's not only the tool that has a 
different name (dnf vs yum vs apt-get vs pacman vs yast,...) their options 
also differ - "dnf builddep" vs "apt-get build-dep" for example. The command 
is very similar, but not the same. And as you note package names differ 
slightly also. Development packager on Fedora end in -devel, where on debian 
and derivatives they end in -dev. Some distros split out packages in a 
different way (I know on some platforms both a libxml and an xml-tools package 
exist and should be installed, on others it's only libxml2).

Considering we want the instructions to be recipe like it makes sense to 
detail the instructions per distro/package manager as long as there are 
differences.
> 
> I was reluctant originally to touch the Fedora and Gentoo sections as I
> hadn't had any experience of them. It would appear the major difference is
> likely to be the name of the package manager on the various distros.

The package manager and subtleties in packaging and package naming.

> I appreciate there are sometimes also slight differences in the
> interpretation of the Linux File Heirarchy as well.
> 
There are, but they shouldn't affect building as far as I can see. If 
dependencies are set up properly, the generic instructions should work on all 
platforms. If not, that's likely a bug in our build system.

But this does bring up another point I'd like to bring up:
I think the generic, user-oriented build instructions should default to 
installing in the user's home directory. However unless an install prefix is 
passed to cmake the installation will default to /usr/local. That is however 
administrator territory and not without pitfalls. So it should be reserved for 
advanced users with system management experience. I agree with Adrien our 
target audience should be users that casually compile an application, but 
otherwise don't have much experience with this.

Geert