[GNC-dev] Documentation update problems

[David Cousens]

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

It does , but it installs the dependencies for the version of GnuCash that the 
distribution supports in its package management system. I ran into this problem
with 3.0-3.2 where a few libraries were up dated. Can always use it as a starting
point and then get users to update whatever fails the cmake /configure.
> 
> 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).

Point taken. It would be nice if you could get readers to specify their distribution 
up front and then just display the relevant bits downstream. I don't know if a wiki can do that
but will try and find out. 
https://www.mediawiki.org/wiki/Manual:Magic_words looks promising
> 
> 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.

>  
I'll set the examples up to default to a /home/user/.local install and then perhaps
add an extra section on installing for all users and the various options there and 
the need for administrator privileges. Most Linux users do get used to that pretty
quickly

> 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
> 
> 
David