Re: Recent lib changes

2017-12-03 Thread John Ralls
Followup: I tested -DCMAKE_INSTALL_LIBDIR and it worked, so no changes to the 
top-level CMakeLists.txt are needed.

Regards,
John Ralls

> On Dec 3, 2017, at 7:17 AM, John Ralls  wrote:
> 
> Bob,
> 
> We added “import(GNUInstallDirs)” to CMakeLists.txt and then went through and 
> changed all of the hard-coded installation directories (e.g. 
> ${CMAKE_INSTALL_PREFIX}/lib to ${CMAKE_INSTALL_LIBDIR} so that GnuCash would 
> install stuff in the right places for the Debian packager. It works for him, 
> we haven’t heard from any of the others yet.
> 
> The GNUInstallDirs module automates the directories a bit more than 
> autotools; typically in autotools if you want libdir to be /usr/lib64 (or on 
> Debian, /usr/lib/x86_64-linux-gnu) you tell configure that with --libdir 
> /usr/lib64. GNUInsalldirs figures out somehow what distro you’re running and 
> sets up the defaults for what it thinks are that distro’s rules. If you want 
> something different you pass e.g. -DCMAKE_INSTALL_LIBDIR=/usr/lib to cmake… 
> but I think we need modify the top-level  CMakeLists.txt to enable that.
> 
> core-utils/binreloc.c had hard-coded directory names of bin, lib, etc, and 
> share relative to the prefix it detects by finding the executable’s path. Rob 
> Gowin fixed lib on Friday but the rest need to be changed to use the paths 
> from gncla-dir.h; that’s the source of your /usr/etc/gnucash problem and yes, 
> that’s a long-standing error: There isn’t supposed to be a /usr/etc [1].
> 
> I think your change to CMAKE_INSTALL_RPATH is correct; ${PKGLIBDIR} is a 
> relative path that doesn’t belong in the executable’s rpath.
> 
> Regards,
> John Ralls
> 
> [1] http://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/usr.html 
> 
> 
>> On Dec 3, 2017, at 4:51 AM, Robert Fewell <14ubo...@gmail.com> wrote:
>> 
>> Just a follow up, the VM I was using with a checkout before the changes at
>> some point a /usr/etc/gnucash directory was created and hence works. If I
>> rename the directory I get the same in the VM with an up to date checkout
>> of unstable that does not have this directory but /etc/gnucash.
>> 
>> I am confused !!!
>> 
>> Bob
>> 
>> On 3 December 2017 at 12:10, Robert Fewell <14ubo...@gmail.com> wrote:
>> 
>>> Hi,
>>> 
>>> I see there have been a lot of changes regarding lib directories and I am
>>> wondering if the overall effect is I should be able to compile/build just
>>> like I used to with out changing any thing because I can't.
>>> 
>>> The first problem is that I build on Gentoo and occasionally try to build
>>> from a local package / ebuild and as part of this scanelf is used which is
>>> now reporting a possible security problem with DT_RUNPATH
>>> 
>>> Prior to the changes it showed RPATH to be /usr/lib:/usr/lib/gnucash but
>>> now it is /usr/lib64:lib64/gnucash. I can fix this by changing line 501 of
>>> CMakeLists.txt to the following...
>>> 
>>> SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_FULL_LIBDIR}:
>>> ${CMAKE_INSTALL_FULL_LIBDIR}/gnucash")
>>> 
>>> If it is just Gentoo specific, I will just patch it locally.
>>> 
>>> The main problem is that it will not run because it can not find the
>>> gnc-modules, after some poking around, the enviroment file is not being
>>> found and so does not set GNC_MODULE_PATH.
>>> 
>>> In gnc-enviroment.c, line 197,  gnc_path_get_pkgsysconfdir returns
>>> /usr/etc/gnucash which comes from binreloc.c, line 606, with prefix being
>>> /usr
>>> 
>>> The strange thing is that I get the same values for before these changes
>>> were made, was this ever correct ?
>>> 
>>> How to fix ?
>>> 
>>> Regards,
>>> 
>>> Bob
>>> 
>>> 
>> ___
>> 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

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


Re: Recent lib changes

2017-12-03 Thread Geert Janssens
Op zondag 3 december 2017 13:51:18 CET schreef Robert Fewell:
> Just a follow up, the VM I was using with a checkout before the changes at
> some point a /usr/etc/gnucash directory was created and hence works. If I
> rename the directory I get the same in the VM with an up to date checkout
> of unstable that does not have this directory but /etc/gnucash.
> 
> I am confused !!!

Bob,

In addition to the information John gave, check whether your source directory 
has a files named
libgnucash/core-utils/gncla-dir.h

If so remove it and rebuild gnucash. This file contains the paths (libdir, 
bindir,...) that the gnucash code will use to locate its modules and related 
files at runtime. However the file in the source dir is created by autotools 
and may not have been updated properly during a cmake run. On my system this 
caused the build to pick up the wrong paths and not find the gnc-modules at 
runtime.

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


Re: Recent lib changes

2017-12-03 Thread John Ralls
Bob,

We added “import(GNUInstallDirs)” to CMakeLists.txt and then went through and 
changed all of the hard-coded installation directories (e.g. 
${CMAKE_INSTALL_PREFIX}/lib to ${CMAKE_INSTALL_LIBDIR} so that GnuCash would 
install stuff in the right places for the Debian packager. It works for him, we 
haven’t heard from any of the others yet.

The GNUInstallDirs module automates the directories a bit more than autotools; 
typically in autotools if you want libdir to be /usr/lib64 (or on Debian, 
/usr/lib/x86_64-linux-gnu) you tell configure that with --libdir /usr/lib64. 
GNUInsalldirs figures out somehow what distro you’re running and sets up the 
defaults for what it thinks are that distro’s rules. If you want something 
different you pass e.g. -DCMAKE_INSTALL_LIBDIR=/usr/lib to cmake… but I think 
we need modify the top-level  CMakeLists.txt to enable that.

core-utils/binreloc.c had hard-coded directory names of bin, lib, etc, and 
share relative to the prefix it detects by finding the executable’s path. Rob 
Gowin fixed lib on Friday but the rest need to be changed to use the paths from 
gncla-dir.h; that’s the source of your /usr/etc/gnucash problem and yes, that’s 
a long-standing error: There isn’t supposed to be a /usr/etc [1].

I think your change to CMAKE_INSTALL_RPATH is correct; ${PKGLIBDIR} is a 
relative path that doesn’t belong in the executable’s rpath.

Regards,
John Ralls

[1] http://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/usr.html 


> On Dec 3, 2017, at 4:51 AM, Robert Fewell <14ubo...@gmail.com> wrote:
> 
> Just a follow up, the VM I was using with a checkout before the changes at
> some point a /usr/etc/gnucash directory was created and hence works. If I
> rename the directory I get the same in the VM with an up to date checkout
> of unstable that does not have this directory but /etc/gnucash.
> 
> I am confused !!!
> 
> Bob
> 
> On 3 December 2017 at 12:10, Robert Fewell <14ubo...@gmail.com> wrote:
> 
>> Hi,
>> 
>> I see there have been a lot of changes regarding lib directories and I am
>> wondering if the overall effect is I should be able to compile/build just
>> like I used to with out changing any thing because I can't.
>> 
>> The first problem is that I build on Gentoo and occasionally try to build
>> from a local package / ebuild and as part of this scanelf is used which is
>> now reporting a possible security problem with DT_RUNPATH
>> 
>> Prior to the changes it showed RPATH to be /usr/lib:/usr/lib/gnucash but
>> now it is /usr/lib64:lib64/gnucash. I can fix this by changing line 501 of
>> CMakeLists.txt to the following...
>> 
>>  SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_FULL_LIBDIR}:
>> ${CMAKE_INSTALL_FULL_LIBDIR}/gnucash")
>> 
>> If it is just Gentoo specific, I will just patch it locally.
>> 
>> The main problem is that it will not run because it can not find the
>> gnc-modules, after some poking around, the enviroment file is not being
>> found and so does not set GNC_MODULE_PATH.
>> 
>> In gnc-enviroment.c, line 197,  gnc_path_get_pkgsysconfdir returns
>> /usr/etc/gnucash which comes from binreloc.c, line 606, with prefix being
>> /usr
>> 
>> The strange thing is that I get the same values for before these changes
>> were made, was this ever correct ?
>> 
>> How to fix ?
>> 
>> Regards,
>> 
>> Bob
>> 
>> 
> ___
> 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: Recent lib changes

2017-12-03 Thread Robert Fewell
Just a follow up, the VM I was using with a checkout before the changes at
some point a /usr/etc/gnucash directory was created and hence works. If I
rename the directory I get the same in the VM with an up to date checkout
of unstable that does not have this directory but /etc/gnucash.

I am confused !!!

Bob

On 3 December 2017 at 12:10, Robert Fewell <14ubo...@gmail.com> wrote:

> Hi,
>
> I see there have been a lot of changes regarding lib directories and I am
> wondering if the overall effect is I should be able to compile/build just
> like I used to with out changing any thing because I can't.
>
> The first problem is that I build on Gentoo and occasionally try to build
> from a local package / ebuild and as part of this scanelf is used which is
> now reporting a possible security problem with DT_RUNPATH
>
> Prior to the changes it showed RPATH to be /usr/lib:/usr/lib/gnucash but
> now it is /usr/lib64:lib64/gnucash. I can fix this by changing line 501 of
> CMakeLists.txt to the following...
>
>   SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_FULL_LIBDIR}:
> ${CMAKE_INSTALL_FULL_LIBDIR}/gnucash")
>
> If it is just Gentoo specific, I will just patch it locally.
>
> The main problem is that it will not run because it can not find the
> gnc-modules, after some poking around, the enviroment file is not being
> found and so does not set GNC_MODULE_PATH.
>
> In gnc-enviroment.c, line 197,  gnc_path_get_pkgsysconfdir returns
> /usr/etc/gnucash which comes from binreloc.c, line 606, with prefix being
> /usr
>
> The strange thing is that I get the same values for before these changes
> were made, was this ever correct ?
>
> How to fix ?
>
> Regards,
>
> Bob
>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Recent lib changes

2017-12-03 Thread Robert Fewell
Hi,

I see there have been a lot of changes regarding lib directories and I am
wondering if the overall effect is I should be able to compile/build just
like I used to with out changing any thing because I can't.

The first problem is that I build on Gentoo and occasionally try to build
from a local package / ebuild and as part of this scanelf is used which is
now reporting a possible security problem with DT_RUNPATH

Prior to the changes it showed RPATH to be /usr/lib:/usr/lib/gnucash but
now it is /usr/lib64:lib64/gnucash. I can fix this by changing line 501 of
CMakeLists.txt to the following...

  SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_FULL_LIBDIR}:
${CMAKE_INSTALL_FULL_LIBDIR}/gnucash")

If it is just Gentoo specific, I will just patch it locally.

The main problem is that it will not run because it can not find the
gnc-modules, after some poking around, the enviroment file is not being
found and so does not set GNC_MODULE_PATH.

In gnc-enviroment.c, line 197,  gnc_path_get_pkgsysconfdir returns
/usr/etc/gnucash which comes from binreloc.c, line 606, with prefix being
/usr

The strange thing is that I get the same values for before these changes
were made, was this ever correct ?

How to fix ?

Regards,

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


Re: GnuCash Draft Concept Guide, or, Whose WIki Is This, Anyway?

2017-12-03 Thread David T. via gnucash-devel
Frank,

Thank you for your reply. 

I will start with an overall observation: I think that you and I see the 
GnuCash documentation realm in fundamentally different ways. 

I believe that the wiki and what I will refer to as the official documentation 
(defined as the Tutorial & Concepts Guide and the Help Manual) should primarily 
serve complementary roles, with information in the official docs taking 
precedence. To me, the wiki supplements the official docs. The wiki amplifies 
the official docs by providing information that is of limited interest to the 
broader community (such as methods for handling some esoteric accounting issue 
in GnuCash, or a technical issue on a specific platform). To me, information 
(such as the wiki glossary) should be removed in favor of material that is 
entered as part of the official documentation set.

I think that you see the wiki as a primary information source for users, and as 
such, you think it should contain its own more or less complete set of 
information about the program and its functions. I may be wrong about this, but 
I believe you have expressed opinions that seem to support this idea.

This means that information can be put in both the wiki and the official 
documentation without a problem for you. However, I do have a problem with 
keeping information in two places: it is a challenge to keep both sets of 
information up to date and in sync with one another—and it makes for more work 
for someone to maintain this synchronization. Your words below suggesting that 
the work is too much for you to manage only supports my point.

As for the specific example of the term “reconciliation’: You say that there is 
something missing from the documentation realm regarding this topic, and want 
to add information to the wiki and the glossary. I, however, see that 
Reconciliation has an entire section (4.4 in the Guide) dedicated to it. It is 
fully explained there as an aspect of Transactions. This section is also 
referenced in the chapter on Checkbooks, section 5.4. As you note, adding 
“reconciliation” to the glossary might be useful; that, however, doesn’t seem 
to me to be a legitimate reason to retain the Draft Concept Guide in its 
entirety.

On the issue of the Guide Glossary, I will note that this section is literally 
version 1, made completely based on the Wiki glossary and my own ideas of terms 
that could use definition for users. (I’ll note that I had thought that 
‘reconciliation’ was a common enough term that it didn’t need an entry in the 
Glossary. I am happy to have someone suggest otherwise, and will take steps to 
add it to the Guide Glossary). Since the Guide Glossary was based directly on 
the Wiki Glossary, I felt that the Wiki Glossary was superceded, and thus I 
deleted most of the Wiki content and added a note to consult the Guide 
Glossary. You overrode that decision, and I respected your wish to retain the 
duplicated information (despite the fact that I disagreed and still disagree 
with your assessment). 

I will note that it was never my intention that this version be considered the 
final one, and I would hope that others in the community with vested interests 
and different perspectives might have taken it upon themselves to contribute to 
the enhancement of the glossary to make it more complete (i.e., with more terms 
in it) and more useful (as in ensuring that first use of terms in the 
documentation referred to the glossary where necessary). 

There are methods for others to bring such enhancements to the docs—either by 
learning how to edit and submit documentation changes (as I somewhat have), or 
by submitting documentation bugs. 

As for scanning the Draft Concept Guide for such keywords, if I were to 
consider taking on such a task, I would go through the current versions of the 
documentation for such terms, rather than a ten-year old version. As I noted in 
another thread recently, that doesn’t sound like something I would want to 
spend my time on, however.

Finally, the GnuCash Wiki (and GnuCash in general) is no doubt a better place 
as a result of your contributions, and as you know, I have been quite 
collaborative in making some of your contributions read more idiomatically in 
English. In a reflection of my priorities, I have focused my energies in the 
Tutorial & Concept Guide. Given our different philosophies regarding the 
documentation roles, I think it might be better if *I* were the one to drop out 
of the Wiki world. I seem mostly to stir up trouble.

David


> On Dec 3, 2017, at 1:26 AM, Frank H. Ellenberger 
>  wrote:
> 
> Hi,
> 
> Am 01.12.2017 um 04:55 schrieb David Thomas:
>> Frank,
>> 
>> I am struggling right now to find the right way to bring up the issue of the 
>> Gnucash Draft Concept Guide, which still resides on the wiki.
>> 
>> As you know, I have proposed on numerous occasions (most recently, two and a 
>> half weeks ago) to have these pages removed from the