Re: [GNC-dev] Documentation update problems

[David Cousens]

Geert

"I think a generic page for autotools based build and one for cmake based 
builds would be useful. We can even consider abandoning the autotools based 
page to save time. This should be accompanied with a page that explains how
to 
set up the proper dependencies based on your platform. The Build
instructions 
page itself would then become a very short recipe referring to these two or 
three pages. "


These pages largely exist in some form in the breakouts from
BuildUbuntu16.04
so I will copy them back to the Build on Linux page. The autotools build
also 
applies to building the documentation so it could also be linked from there

David Cousens



-
David Cousens
--
Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Documentation update problems

[David Cousens]

Adrien,

I think it is better to leave packaging apps to specialists rather than the
general user. Using flatpak and snap can be better addressed on the
Installation page rather than a building page which also addresses using ,
Software Mmanager and installation of the version supported by the
particular distribution version.

I was thinking more of a few notes that people ouside the GnuCash developer
user group might pick up on to remind them to compile with all options and
setup access to the operating system utilities where needed, preferrably as
part of the app setup rather than a post configuration. I don't know enough
about flatchat or snap to know if it is possible to do that but I would
expect it to be possible

The current building page is linked in from the Installation page as an if
all else fails try building option (not quite in those terms).

David



-
David Cousens
--
Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Documentation update problems

[David Cousens]

On Thu, 2018-09-20 at 11:42 -0500, Adrien Monteleone wrote:
> While you’re tweaking this, consider changing the debian/derivative 
> instructions to use ‘apt’ instead of ‘apt-get’ as
> my understanding the distro preferences are for the newer ‘apt’ user tool. 
> (not to be confused, due to unfortunate
> naming, with the low level ‘apt’)

I was torn between using apt or apt-get when updating the Ubuntu16.04 but 
seeing that apt is the new package in 16.04.
I'll just use apt add a note to the effect that it may be apt-get in some 
distributions/versions along with reference to
the package managers


David
> 
> Regards,
> Adrien
> 
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Documentation update problems

[Adrien Monteleone]

I was thinking more along the lines of .deb/.rpm but if it adds complexity to 
get up and running, certainly, it should not be included. (or perhaps as a 
breakout page option)

I don’t take that route for my own installations as I’m more familiar with 
building and cleaning up after myself.

Regards,
Adrien

> On Sep 20, 2018, at 12:14 PM, Geert Janssens  
> wrote:
> 
> Op donderdag 20 september 2018 19:09:10 CEST schreef Adrien Monteleone:
>>> On Sep 20, 2018, at 5:46 AM, David Cousens 
>>> wrote:
>>> 
>>> 
>>> 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
>> 
>> If the target is going to be casual builders, should the recommendation
>> instead include in the recipe the commands to package the app first and
>> then install via the system package manager? That would seem a cleaner
>> approach and remove the need for retaining build directories for removal,
>> having to probably revisit the wiki to figure out how to uninstall just use
>> their regular package manager to handle it.
> 
> I think that goes very much in the direction of flatpak, snap and friends.
> 
> I personally don't think adding information on packaging will make it any 
> easier. This is in general rather challenging in fact.
> 
> Geert
> 
> 
> 


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Documentation update problems

[Geert Janssens]

Op donderdag 20 september 2018 19:09:10 CEST schreef Adrien Monteleone:
> > On Sep 20, 2018, at 5:46 AM, David Cousens 
> > wrote:
> > 
> > 
> > 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
> 
> If the target is going to be casual builders, should the recommendation
> instead include in the recipe the commands to package the app first and
> then install via the system package manager? That would seem a cleaner
> approach and remove the need for retaining build directories for removal,
> having to probably revisit the wiki to figure out how to uninstall just use
> their regular package manager to handle it.

I think that goes very much in the direction of flatpak, snap and friends.

I personally don't think adding information on packaging will make it any 
easier. This is in general rather challenging in fact.

Geert


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Documentation update problems

[Adrien Monteleone]

> On Sep 20, 2018, at 5:46 AM, David Cousens  wrote:
> 
>> 
> 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

If the target is going to be casual builders, should the recommendation instead 
include in the recipe the commands to package the app first and then install 
via the system package manager? That would seem a cleaner approach and remove 
the need for retaining build directories for removal, having to probably 
revisit the wiki to figure out how to uninstall just use their regular package 
manager to handle it.

Regards,
Adrien


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Documentation update problems

[Adrien Monteleone]

While you’re tweaking this, consider changing the debian/derivative 
instructions to use ‘apt’ instead of ‘apt-get’ as my understanding the distro 
preferences are for the newer ‘apt’ user tool. (not to be confused, due to 
unfortunate naming, with the low level ‘apt’)

Regards,
Adrien

> On Sep 19, 2018, at 4:51 PM, David Cousens  wrote:
> 
> 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
> 
> 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. 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. 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 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. I appreciate there
> are sometimes also slight differences in the interpretation of the Linux File 
> Heirarchy as well.
> 
> I'll come back when I've done a restructure and get everyone to check it out
> 
> David Cousens
> 

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Wiki Building Instructions Reorganization

[Adrien Monteleone]

That’s a vast improvement!

Per your question marks:


Distros
---
I wouldn’t include distros unless a survey of the mailing list archives shows 
there are quirks for them. (and perhaps revisit the currently listed quirks, if 
they are for very old versions rather than current processes, then they can be 
removed)

I see you left out Gentoo & Slackware which are on that page. (the Slackware 
link ’this page’ is really bad anchor text similar to ‘click here’ BTW)

From the installation page (which includes some RHEL based distro links) I see 
there are breakout pages for FreeBSD and Solaris. (now OpenIndiana) Are these 
still relevant? Should the ‘FreeBSD’ page be re-labeled ‘BSD’? The Solaris page 
looks like it is circa 2007.

On that note, perhaps backing up a step to ‘Installation’ might be a good idea 
to make sure everything is tidy.


Package Formats
---
I thought calameres was an installer used to install distros, not a packaging 
format, though I could be misunderstanding it’s scope. (QT based DE’s seem to 
like it)


Plugins
---
I agree the plugin section should be moved to a developer area. Are there any 
plugins currently?

Regards,
Adrien


> On Sep 20, 2018, at 1:58 AM, David Cousens  wrote:
> 
> Freeplane Mindmap of outline of proposed restructure
> 
> BuildingGnuCashRestructure.mm
> 
>   
> 
> David Cousens
> 
> 
> 
> -
> David Cousens
> --
> Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> 


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] ImpEx Sample files

[Frank H. Ellenberger]

Hi David,

for simple samples you could ask on the user list,
for full featured test files read the specs or dig in
https://github.com/aqbanking/aqbanking . At least I don't know good
examples.

Frank

Am 20.09.18 um 00:46 schrieb David Cousens:
> Frank,
> 
> I too had a look around and couldn't find any sample/test files but I had 
> found the SWIFT and DTAUS. I am surprised the
> maintainers of the standards don't generate them to allow testing for 
> compliance. If absolutely necessary I will
> generate my own. I'm reluctant to produce my own as there is no guarantee 
> that they will conform but anything is better
> than nothin. I guess there is a lot of work in defining a sample file which 
> tests all possible nuances of a given
> formatand particularly so when there is continuing development
> 
> Thanks for the information on the set of sample files.I'll check them out and 
> add any I do manage to find. 

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [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 
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Wiki Building Instructions Reorganization

[David Cousens]

Freeplane Mindmap of outline of proposed restructure

BuildingGnuCashRestructure.mm

  

David Cousens



-
David Cousens
--
Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [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


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel