Re: [GNC-dev] Single User Installation location on Linux
Hi, Am 06.03.20 um 10:25 schrieb Geert Janssens: > Yes, I noticed that too. Looking at the history it looks like Frank already > made this change in May > last year. > > I also googled around a bit more on this subject. And it looks like there are > different > interpretations of how $HOME/.local should be used. Looking back that change was incomplete, because I had the implicit assumption of building while developing. In that case i would still suggest to use a separate directory like $HOME/test and the PATH adjustment in the one or other way - as it has to be done IIRC when installing to /opt. Then you can simply remove it, if something went wrong. Building a stable/released version is a different task and then using $HOME/.local is the right place. You can always return to that version and run 'make uninstall'. > The freedesktop base directory specification [1] is fairly vague in its > definition. It mentions > "user-specific data files". GnuCash interprets this as internal state files, > which is gnucash data > that's user specific. Many other applications do the same including > gnome-shell and plenty of > other default gnome and kde applications. Others like LibreOffice on the > other hand exclusively > use $HOME/.config. > > On the other hand systemd reinterprets this differently and has its own > freedesktop spec for this > [2]: in their interpretation $HOME/.local is used to install applications > locally for a single user. > From this it follows $HOME/.local/share is supposed to hold the equivalent of > /usr/share. > > The systemd spec defines $HOME/.config to be the location for user-specific > configuration and > state data. So according to that spec what we currently store in > $HOME/.local/share/gnucash > would actually belong in $HOME/.config as well. IMHO we should keep the almost constant, user editable configuration separated from the programs state data. I assume the mentioned programs have been lazy and simply moved $HOME/.appname to $HOME/.config/appname. > This new interpretation conflicts with ours unfortunately but does explain > why many debian > based distros have $HOME/.local/bin in their PATHs by default. > > I don't know what is the best way forward. These two standards simply > conflict and many other > apps are (still) in the same boat. We could avoid the conflict by shunning > $HOME/.local/share > and instead save all metadata in $HOME/.config as LibreOffice does. In a way > that would > simplify matters as that would give us a single config directory per > supported platform where > we currently have two for linux and one for the other platforms. On the other > hand it would > mean yet another relocation of metadata which is no fun. > > Regards, > > Geert > > [1] > https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html > [2] https://www.freedesktop.org/software/systemd/man/file-hierarchy.html > Op vrijdag 6 maart 2020 04:37:55 CET schreef David Cousens: >> Strange >> >> I or someone else must have changed the wiki after the previous discussion. >> It now has $HOME/opt as a recommended location and points out that it can be >> any directory the user chooses. >> >> David Regards Frank ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Single User Installation location on Linux
Op vrijdag 6 maart 2020 11:53:30 CET schreef Colin Law: > On Fri, 6 Mar 2020 at 09:50, Geert Janssens > wrote: > > ... > > So we have identified at least one installation method that indeed does > > follow the systemd spec. I wonder whether npm (for nodeJS), guix (for > > guile), cpan (for perl) and so on have similar user local installation > > options that use $HOME/.local. > Not npm, assuming you mean when you use it to install modules. It > installs into a folder node_modules in the folder from which it is > run. So an npm local install is local to the current folder, not the > user. > > Colin Ok, thanks for the additional info. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Single User Installation location on Linux
On Fri, 6 Mar 2020 at 09:50, Geert Janssens wrote: > ... > So we have identified at least one installation method that indeed does > follow the systemd spec. I wonder whether npm (for nodeJS), guix (for guile), > cpan (for perl) and so on have similar user local installation options that > use $HOME/.local. Not npm, assuming you mean when you use it to install modules. It installs into a folder node_modules in the folder from which it is run. So an npm local install is local to the current folder, not the user. Colin ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Single User Installation location on Linux
Op vrijdag 6 maart 2020 10:39:29 CET schreef Colin Law: > On Fri, 6 Mar 2020 at 09:29, Geert Janssens > wrote: > > ... > > What I am still curious about though is how applications get installed in > > $HOME/.local/bin. > Looking at my notes on platformio I believe it got there via > pip install --user platformio > In my notes it also says to add .local/bin to the path but I don't > know whether in fact it was there already. > > Colin Ah, interesting! pip is the installer for python packages. When I run the command above it will also install that package in $HOME/.local/bin on my Fedora box. It's the first tool that does so. $HOME/.local.bin didn't exist before I ran this command. Still $HOME/.local/bin is not on my PATH. I'd have to add it myself. So we have identified at least one installation method that indeed does follow the systemd spec. I wonder whether npm (for nodeJS), guix (for guile), cpan (for perl) and so on have similar user local installation options that use $HOME/.local. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Single User Installation location on Linux
On Fri, 6 Mar 2020 at 09:29, Geert Janssens wrote: > ... > What I am still curious about though is how applications get installed in > $HOME/.local/bin. Looking at my notes on platformio I believe it got there via pip install --user platformio In my notes it also says to add .local/bin to the path but I don't know whether in fact it was there already. Colin ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Single User Installation location on Linux
Op vrijdag 6 maart 2020 10:09:01 CET schreef Colin Law: > Inspecting my Ubuntu 19.10 system I see that a number of applications > have installed themselves to ~/.local/bin. Platformio for example. > Also that folder is in the PATH, but whether it is there on a clean > install I don't know. > > Colin It probably is in the PATH by default. See my other mail for more details. What I am still curious about though is how applications get installed in $HOME/.local/bin. I would assume using apt would install system wide. Are those applications coming in via another installation mechanism ? Snaps perhaps ? Can you figure out how these applications got installed and how that installation method differs from the typical system-wide ones ? Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Single User Installation location on Linux
Yes, I noticed that too. Looking at the history it looks like Frank already made this change in May last year. I also googled around a bit more on this subject. And it looks like there are different interpretations of how $HOME/.local should be used. The freedesktop base directory specification [1] is fairly vague in its definition. It mentions "user-specific data files". GnuCash interprets this as internal state files, which is gnucash data that's user specific. Many other applications do the same including gnome-shell and plenty of other default gnome and kde applications. Others like LibreOffice on the other hand exclusively use $HOME/.config. On the other hand systemd reinterprets this differently and has its own freedesktop spec for this [2]: in their interpretation $HOME/.local is used to install applications locally for a single user. >From this it follows $HOME/.local/share is supposed to hold the equivalent of >/usr/share. The systemd spec defines $HOME/.config to be the location for user-specific configuration and state data. So according to that spec what we currently store in $HOME/.local/share/gnucash would actually belong in $HOME/.config as well. This new interpretation conflicts with ours unfortunately but does explain why many debian based distros have $HOME/.local/bin in their PATHs by default. I don't know what is the best way forward. These two standards simply conflict and many other apps are (still) in the same boat. We could avoid the conflict by shunning $HOME/.local/share and instead save all metadata in $HOME/.config as LibreOffice does. In a way that would simplify matters as that would give us a single config directory per supported platform where we currently have two for linux and one for the other platforms. On the other hand it would mean yet another relocation of metadata which is no fun. Regards, Geert [1] https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html [2] https://www.freedesktop.org/software/systemd/man/file-hierarchy.html Op vrijdag 6 maart 2020 04:37:55 CET schreef David Cousens: > Strange > > I or someone else must have changed the wiki after the previous discussion. > It now has $HOME/opt as a recommended location and points out that it can be > any directory the user chooses. > > 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 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Single User Installation location on Linux
Inspecting my Ubuntu 19.10 system I see that a number of applications have installed themselves to ~/.local/bin. Platformio for example. Also that folder is in the PATH, but whether it is there on a clean install I don't know. Colin On Thu, 5 Mar 2020 at 22:20, David Cousens wrote: > > Geert > > I had a short discussion about where to install for local use with John when > I started updating the wiki a couple of years ago. At that time the user > gnucash data files weren't in $HOME/.local/share/gnucash so there was no > possible conflict at that time. > > The $HOME/.local/bin was added to PATH in my default user .profile supplied > in Linux Mint which is executed by the command interpreter in login shells. > It also adds $HOME/bin to the PATH and includes .bashrc if it exists., so it > is a distro dependent addition and we can't assume it will have been added > in all distributions. > .profile <http://gnucash.1415818.n4.nabble.com/file/t375329/.profile> > > > If $HOME/.local/bin or $HOME/bin is in the PATH and has a soft link in > either location to the executable then just typing gnucash at the prompt in > a terminal will start it (AFAIK as long as there isn't another link earlier > in the PATH variable which gets activated first). My own practice is to > create aliases which address the specific executable and locations when I > have multiple versions installed or if the use is likely to be longer term > create launchers for the specific version in the LM menu. > > > That will depend a bit on the history behind the choice for $HOME/.local > > in > > the first place. > > That was the main reason why I raised it here after Frank pointed it out in > a comment on my reply to a user in the user forum. It may be the user data > files can coexist happily in $HOME/.local/share along with the program data > files as it is a single user installation. > > I built and installed 3.8 to $HOME/.local yesterday to check it out. make > uninstall seems to have removed the files placed in > $HOME/.local/share/gnucash in the install without affecting the user data > files in the same location, but just leaves the trail of empty directories > the files were in.The risk is in a user doing a manual uninstall of the > program and accidentally deleting the user data files with custom reports, > checks books etc. > > > David Cousens > > > 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 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Single User Installation location on Linux
Strange I or someone else must have changed the wiki after the previous discussion. It now has $HOME/opt as a recommended location and points out that it can be any directory the user chooses. 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] Single User Installation location on Linux
John, These were previous mentionsof $HOME/.local. My emeory of things is getting a bit flawed these days. I don't think it was a rtecommendation as such. The original wiki before I modified it had $HOME/.local as the single user location http://gnucash.1415818.n4.nabble.com/GNC-dev-About-the-HOME-local-installation-prefix-tp4710196p4710237.html http://gnucash.1415818.n4.nabble.com/GNC-Building-v3-Wiki-entry-for-Ubuntu-tt4701508.html#a4701569 http://gnucash.1415818.n4.nabble.com/GNC-dev-About-the-HOME-local-installation-prefix-tp4710196p4710262.html The thread above seems to also conclude a $HOME/apps location or similar as a better alternative. i obviously didn't follow up and modify the wiki at the time. Will put it on the to do list this time. http://gnucash.1415818.n4.nabble.com/GNC-Uninstall-GC-tp4708376p4708497.html I couldn't find any earlier references. I will change the wiki to recommend using a directory under $HOME aka /home/. I will suggest using $HOME/apps but point out it can be any directory name the user chooses and can be a hidden directory if the user so wishes. I will also add some suggestions for alternative ways to include the executable in the PATH environment as well as a suggestion to include a launcher in the OS's menu system as per the distro's methods. 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] Single User Installation location on Linux
Geert I had a short discussion about where to install for local use with John when I started updating the wiki a couple of years ago. At that time the user gnucash data files weren't in $HOME/.local/share/gnucash so there was no possible conflict at that time. The $HOME/.local/bin was added to PATH in my default user .profile supplied in Linux Mint which is executed by the command interpreter in login shells. It also adds $HOME/bin to the PATH and includes .bashrc if it exists., so it is a distro dependent addition and we can't assume it will have been added in all distributions. .profile <http://gnucash.1415818.n4.nabble.com/file/t375329/.profile> If $HOME/.local/bin or $HOME/bin is in the PATH and has a soft link in either location to the executable then just typing gnucash at the prompt in a terminal will start it (AFAIK as long as there isn't another link earlier in the PATH variable which gets activated first). My own practice is to create aliases which address the specific executable and locations when I have multiple versions installed or if the use is likely to be longer term create launchers for the specific version in the LM menu. > That will depend a bit on the history behind the choice for $HOME/.local > in > the first place. That was the main reason why I raised it here after Frank pointed it out in a comment on my reply to a user in the user forum. It may be the user data files can coexist happily in $HOME/.local/share along with the program data files as it is a single user installation. I built and installed 3.8 to $HOME/.local yesterday to check it out. make uninstall seems to have removed the files placed in $HOME/.local/share/gnucash in the install without affecting the user data files in the same location, but just leaves the trail of empty directories the files were in.The risk is in a user doing a manual uninstall of the program and accidentally deleting the user data files with custom reports, checks books etc. David Cousens 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] Single User Installation location on Linux
Hi Frank,
I agree with the general point of using a directory under $HOME as the
installation point. What it is called is really up to the users preference.
$HOME/.local/bin seems to be included in PATH by default on Linux Mint. Not
sure if that is necessarily the case for other Linux distributions. I have
adopted using a simlink from $HOME/.local/bin to the executable in
$HOME//bin/gnucash if I have a local installation.
That has the advantage that the PATH variable doesn't become cluttered with
a lot of individual paths to other installed applications. Not all other
aprograms necessarily install cleanly in the $HOME/{\bin | \etc
| \lib | /include | \share} structure. I have some which have the structure
$HOME///{\bin | \etc | \lib | /include |
\share} which in time will hopefully become more consistent.
I personally only have a few apps I install for a single user, usually just
apps I am trying out. Most including GnuCash are installed system wide in
either /usr/local or /opt but we probably need to consider those users who
are either not comfortable with system installation or do not have the
privileges for system wide installation or easy access to those who do.
I do also install builds of maint and master branches locally but I use a
separate directory again under my home directory for any development
installations.
Possibly the best way to go in the wiki is to specify a general form like
in the syntax and point out that the user can subsitute
their choice for .
I am experimenting with a bash script to do the full install including
download of a selected version from a list of the current available versions
from SourceForge, extracting it and either a system wide to /usr/local or
/opt or a local install to a specified directory under $HOME. I would like
eventually to be able to query SourceForge for the list of available
versions but my bash skills are still too rudimentary. The install part of
the script is easy it is just setting up the option selection which is
proving a challenge
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] Single User Installation location on Linux
I can't, perhaps David remembers ? Geert [1] https://lists.gnucash.org/pipermail/gnucash-user/2020-March/089602.html Op donderdag 5 maart 2020 20:57:04 CET schreef John Ralls: > Can you point me at that recommendation? I don't remember it and all Google > is finding for me is > https://lists.gnucash.org/pipermail/gnucash-user/2018-May/076971.html where > I use $HOME/.local as an e.g. > > Regards, > John Ralls > > > On Mar 5, 2020, at 12:53 AM, Geert Janssens > > wrote: > > > > I just now read your original reply on the user list. > > > > So the recommendation comes from John. We'll have to wait for his answer > > to > > see where he got it from then. > > > > In addition you suggest there the installation process adds > > $HOME/.local/bin to the PATH. I don't think it does. There is nothing in > > the build scripts that would suggest otherwise. > > So it must be either something your distro does for you or something you > > may have done yourself in the past. > > > > For the record on Fedora this is not added to the path by default. It's > > not in mine. > > > > Regards, > > > > Geert > > > > Op donderdag 5 maart 2020 09:43:44 CET schreef Geert Janssens: > >> David, > >> > >> I'm interested where you got the recommendation to install into > >> $HOME/.local from ? Perhaps this is a practice used by some distros in > >> specific ?>> > >> Op donderdag 5 maart 2020 02:47:36 CET schreef David Cousens: > >>> If I create a directory .apps under $HOME then GnuCash installs to it > >>> without any problem but no link from $HOME/.local/bin to the executable > >>> in > >>> $HOME/.apps is created by the installation and the user would have to > >>> create this this manually. Once this is done GnuCash seems to run fine > >>> from $HOME/.apps as a single user app. > >> > >> How do you start gnucash when installed in $HOME/.local/bin ? > >> What's different with doing so from $HOME/.apps ? > >> > >>> The question is do we need to change the recommendation for installing > >>> under $HOME/.local on the wiki and what should we change it to? If it is > >>> agreed this is necessary I will modify the wiki to suit. > >> > >> That will depend a bit on the history behind the choice for $HOME/.local > >> in > >> the first place. > >> > >> Regards, > >> > >> Geert > >> > >> > >> ___ > >> 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: [GNC-dev] Single User Installation location on Linux
Can you point me at that recommendation? I don't remember it and all Google is finding for me is https://lists.gnucash.org/pipermail/gnucash-user/2018-May/076971.html where I use $HOME/.local as an e.g. Regards, John Ralls > On Mar 5, 2020, at 12:53 AM, Geert Janssens > wrote: > > I just now read your original reply on the user list. > > So the recommendation comes from John. We'll have to wait for his answer to > see where he got it from then. > > In addition you suggest there the installation process adds $HOME/.local/bin > to the PATH. I don't think it does. There is nothing in the build scripts > that > would suggest otherwise. > So it must be either something your distro does for you or something you may > have done yourself in the past. > > For the record on Fedora this is not added to the path by default. It's not > in > mine. > > Regards, > > Geert > > Op donderdag 5 maart 2020 09:43:44 CET schreef Geert Janssens: >> David, >> >> I'm interested where you got the recommendation to install into $HOME/.local >> from ? Perhaps this is a practice used by some distros in specific ? >> Op donderdag 5 maart 2020 02:47:36 CET schreef David Cousens: >>> If I create a directory .apps under $HOME then GnuCash installs to it >>> without any problem but no link from $HOME/.local/bin to the executable in >>> $HOME/.apps is created by the installation and the user would have to >>> create this this manually. Once this is done GnuCash seems to run fine >>> from $HOME/.apps as a single user app. >> >> How do you start gnucash when installed in $HOME/.local/bin ? >> What's different with doing so from $HOME/.apps ? >> >>> The question is do we need to change the recommendation for installing >>> under $HOME/.local on the wiki and what should we change it to? If it is >>> agreed this is necessary I will modify the wiki to suit. >> >> That will depend a bit on the history behind the choice for $HOME/.local in >> the first place. >> >> Regards, >> >> Geert >> >> >> ___ >> 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: [GNC-dev] Single User Installation location on Linux
I just now read your original reply on the user list. So the recommendation comes from John. We'll have to wait for his answer to see where he got it from then. In addition you suggest there the installation process adds $HOME/.local/bin to the PATH. I don't think it does. There is nothing in the build scripts that would suggest otherwise. So it must be either something your distro does for you or something you may have done yourself in the past. For the record on Fedora this is not added to the path by default. It's not in mine. Regards, Geert Op donderdag 5 maart 2020 09:43:44 CET schreef Geert Janssens: > David, > > I'm interested where you got the recommendation to install into $HOME/.local > from ? Perhaps this is a practice used by some distros in specific ? > Op donderdag 5 maart 2020 02:47:36 CET schreef David Cousens: > > If I create a directory .apps under $HOME then GnuCash installs to it > > without any problem but no link from $HOME/.local/bin to the executable in > > $HOME/.apps is created by the installation and the user would have to > > create this this manually. Once this is done GnuCash seems to run fine > > from $HOME/.apps as a single user app. > > How do you start gnucash when installed in $HOME/.local/bin ? > What's different with doing so from $HOME/.apps ? > > > The question is do we need to change the recommendation for installing > > under $HOME/.local on the wiki and what should we change it to? If it is > > agreed this is necessary I will modify the wiki to suit. > > That will depend a bit on the history behind the choice for $HOME/.local in > the first place. > > Regards, > > Geert > > > ___ > 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] Single User Installation location on Linux
David, I'm interested where you got the recommendation to install into $HOME/.local from ? Perhaps this is a practice used by some distros in specific ? Op donderdag 5 maart 2020 02:47:36 CET schreef David Cousens: > If I create a directory .apps under $HOME then GnuCash installs to it > without any problem but no link from $HOME/.local/bin to the executable in > $HOME/.apps is created by the installation and the user would have to > create this this manually. Once this is done GnuCash seems to run fine from > $HOME/.apps as a single user app. How do you start gnucash when installed in $HOME/.local/bin ? What's different with doing so from $HOME/.apps ? > > The question is do we need to change the recommendation for installing under > $HOME/.local on the wiki and what should we change it to? If it is agreed > this is necessary I will modify the wiki to suit. That will depend a bit on the history behind the choice for $HOME/.local in the first place. Regards, Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Single User Installation location on Linux
Hi David, some historical background: In Gnucash 2.x we followed the FHS http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s08.html Note, that "Home Directory Specifications and Conventions" is new in version 3, released March 19, 2015. In Gnucash 3.x we obey the XDG Base Directory Specification https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html "Environment variables" shows the defaults $HOME/.local/share and $HOME/.config. I would not use $HOME/.local as PREFIX because, as you show, $HOME/.local/share would be cluttered by 2 different types of data, which are output of 1. make install 2. running gnucash If you forgot to run 'make uninstall' before each 'make && make install' you can not remove $HOME/.local without loosing the "memory" of gnucash and other XDG conform programs. My approach: I would use $HOME/test as prefix and a) insert $HOME/test/bin into PATH or b) create in $HOME/bin a shell script, whith e.g.: $HOME/test/bin/gnucash --nofile I would not use a hidden directory without a specific reason. Regards Frank Am 05.03.20 um 02:47 schrieb David Cousens: > The wiki Building on Linux currently recommends doing a single user local > installation to $HOME/.local. > > Frank Ellenberger pointed out to me in a thread > (http://gnucash.1415818.n4.nabble.com/GNC-How-to-install-GnuCash-from-Source-for-Linux-tt4716225.html) > on the User forum that this results in $HOME/.local/share containing both > program and user configuration data in $HOME/.local/share/gnucash. > > The data seems to happily coexist, i.e. no folders or files from the program > and configuration data seem to have the same name and make uninstall appears > to leave program data in that location after uninstalling. The following is > a list of the accounts in the location after an install to $HOME/.local. The > files/folders marked with a * following them are the ones which were present > in that location prior to installing GnuCash in $HOME/.local (my user > config data from my normal installation running from in /usr/local). After > an uninstall, the files seem to be deleted but the folders are not generally > deleted so an uninstall of the program is not complete. > > $HOME/.local/share/gnucash*/accounts > /books* > /checks * > /gtkbuilder > /icons > /jqplot > /pixmaps > /python > /scm > /translog * > /ui* > /accelerator-map * > /expressions-2.0 * > /qif-accounts-map * > /saved-reports-2.8 * > /saved-reports-2.8-backup * > /stylesheets-2.0 * > > If I create a directory .apps under $HOME then GnuCash installs to it > without any problem but no link from $HOME/.local/bin to the executable in > $HOME/.apps is created by the installation and the user would have to > create this this manually. Once this is done GnuCash seems to run fine from > $HOME/.apps as a single user app. > > The question is do we need to change the recommendation for installing under > $HOME/.local on the wiki and what should we change it to? If it is agreed > this is necessary I will modify the wiki to suit. > > David Cousens ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[GNC-dev] Single User Installation location on Linux
The wiki Building on Linux currently recommends doing a single user local installation to $HOME/.local. Frank Ellenberger pointed out to me in a thread (http://gnucash.1415818.n4.nabble.com/GNC-How-to-install-GnuCash-from-Source-for-Linux-tt4716225.html) on the User forum that this results in $HOME/.local/share containing both program and user configuration data in $HOME/.local/share/gnucash. The data seems to happily coexist, i.e. no folders or files from the program and configuration data seem to have the same name and make uninstall appears to leave program data in that location after uninstalling. The following is a list of the accounts in the location after an install to $HOME/.local. The files/folders marked with a * following them are the ones which were present in that location prior to installing GnuCash in $HOME/.local (my user config data from my normal installation running from in /usr/local). After an uninstall, the files seem to be deleted but the folders are not generally deleted so an uninstall of the program is not complete. $HOME/.local/share/gnucash*/accounts /books* /checks * /gtkbuilder /icons /jqplot /pixmaps /python /scm /translog * /ui* /accelerator-map * /expressions-2.0 * /qif-accounts-map * /saved-reports-2.8 * /saved-reports-2.8-backup * /stylesheets-2.0 * If I create a directory .apps under $HOME then GnuCash installs to it without any problem but no link from $HOME/.local/bin to the executable in $HOME/.apps is created by the installation and the user would have to create this this manually. Once this is done GnuCash seems to run fine from $HOME/.apps as a single user app. The question is do we need to change the recommendation for installing under $HOME/.local on the wiki and what should we change it to? If it is agreed this is necessary I will modify the wiki to suit. 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] About the "$HOME/.local" installation prefix
Geert, Agree with all the points you and david Carlson made. I had expected and guessed that the GnuCashbuild configured its search directories for resources from the cmake install prefix, but hadn't actually checked it out to be sure. The problem as I see it is recommending a setup for a novice or inexperienced user new to building and installing who may or may not have admin privileges to use that will allow them to install and uninstall fairly easily even when they no longer have the build directory and access to the make uninstall. Even with a little bit of development experience you can usually work it out for yourself. A user who is primarily interested in just using Gnucash and doesn't want to know about the nitty gritty of development per se but wants to be using the most up to date version, on the other hand, will get frustrated if every time he has to update, he has to figure out what went where and how to get rid of it. I'll rework the Wiki page to use a non hidden directory with a gnucash specific subdirectory as an install point in the example rather than $HOME/.local and just add notes to the effect that this directory can be hidden if desired by prefixing it with a dot. Then a simple rm -rf can be used easily. I'll also add some notes about setting up aliases to start it up. That should cover the user new to building from source. Then anyone who wants a more sophisticated setup can roll their own. cheers 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] About the "$HOME/.local" installation prefix
Colin There is no reason why the install directory can't just be an ordinary directory. There is no real reason for it to be hidden. It is what I use if I do do a local install. The only possible advantage is that if you can hide the directory it doesn't clutter the view of files when you won't be looking at program files the majority of the time even though you will be using them 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] About the "$HOME/.local" installation prefix
Op vrijdag 3 mei 2019 03:09:43 CEST schreef David Cousens: > Hi John, > > It was because of a number of posts in the forum, not sure whether DEV or > USER around the time I reworked the pages which suggested $HOME/.local for > single user local installations of GnuCash . I think it may also have been > specified the previous Wiki page I started from as well. At the time I could > not find any better suggestions so I left it in place. My own preference > has been to install in /usr/local or /opt system wide for production. If > you use make uninstall from the build directory it seems to uninstall > correctly from $HOME/.local as long as the manifest still exists as the > paths to each file installed are specified > Indeed. That's the mechanism in place to uninstall packages. It has a few flaws though. For this to work 1. the build directory is still around 2. the current state of the build directory still would install files in the same spot and at least the same files as the original install. I have been bitten both ways (one of the conditions didn't apply any more). These flaws are what triggered the creation of package managers. So in general I prefer installing via make install into a unique directory per installed application. That way the above pitfalls don't matter. If something changes such that make uninstall can't clean up, you can simply remove the complete installation directory. > If I do a local temporary install, I personally install in a subdirectory of > my home directory and add the relevant search paths to the front of the > PATH environment variable . You of course have the problem with the order > in PATH as to whether you search $HOME directories before or after system > installed paths if you have multiple copies of different versions. Ideally > in that case you could invoke a startup script which setup the PATH > variable depending on which version you are starting up and where its > resouces are located. I have used /opt and /usr/local for different > versions but the same problem with ordering the search order in PATH > arises. You could also define aliases to deal with this, like alias gnucash-my-build = /home/user/path/to/my/install/bin/gnucash Then "gnucash" would run the system installed gnucash, "gnucash-my-build" would run your own Or, as I would think most users would like to start gnucash from their Destkop environment's menu or application launcher, you can copy the gnucash.desktop file from /share/applications to /home/user/.local/share/ applications. If you then edit the file and change the "Name" value to say "My GnuCash" (and do the same for the Name in your language), you can start "My GnuCash" from your DE's menu or application launcher. You may have to log out and back in for this to work. > > Python installs what it calls site-packages under $HOME/.local which seem to > be user specific but most of the other data I find in the directory is in > $HOME/.local/share which seems to be mainly user specific data for various > packages. > > The Linux File Heirarchy gives no real guidance for the structure of a users > home directory apart from a reference to XDG and GLib conventions ( can't > find any reference): > > https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html > > One stackexchange article suggested duplicating sections of the FHS under > $HOME which seems a bit extreme. I believe that suggestion goes with the concept of having $HOME/bin on the PATH. But the weakness of installing multiple applications in the same install prefix without the safety net of a decent package manager remains. > If I did that I would be inclined to have a > specific directory under $HOME with the /bin, /etc, /lib /share directories > under it. I have an Applications directory for that purpose usually with a > package sub directory under that which contains the above directories. > I'm more in favor of this approach as well. > For the little development work on GnuCash I do I have a separate structure > again under my home directory which has an install subdirectory which I > install to. Same here. > I have often wondered whether I am actually getting to the > correct libraries by setting up the PATH variable (particularly if I forget > to set it up). Then there is unsetting PATH when you want to go back to > production work. You shouldn't worry about setting paths for getting the proper libraries. GnuCash should take care of this itself. It's encoded based on the installation prefix you provide while running cmake. The only reason to add something to the PATH is to allow you to simply type "gnucash" somewhere in a shell and that would then start your local installation. But even that's entirely optional. You could jus
Re: [GNC-dev] About the "$HOME/.local" installation prefix
On Fri, 3 May 2019 at 07:26, David Cousens wrote: > ... > I.e. we recommend using cmake commands as follows for inexperienced or users > who don't have admin privileges rather than simply installing directly under > $HOME/.local which already has a gnucash directory for GnuCash user > preferences. > > cmake -DCMAKE_INSTALL_PREFIX=$HOME/.local/programs/gnucash absolute path to sources> > > If you think this is a better idea (or there is another more general > alternative I can update the Wiki build instructions to reflect this. The > user could then create an alias in the bashrc file to access the executable > and/or add it to their launcher etc. I really don't like the idea of installing under a hidden directory (~/.local). Colin ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] About the "$HOME/.local" installation prefix
John, Geert et al I have not been able to find any references on user directory organization apart from the XDG (https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html). There was one comment in this link (https://itsfoss.com/install-software-from-source-code/) which suggests that software installed in /opt from source expects to find its resources in directories relative to a package parent directory in /opt. and that this is why simlinks are used from/usr/bin or /usr/local/bin to the executable in /opt/ where the application stores its resources relative to /opt/. This seems to be how LibreOffice is installed on Linux Mint for example. I haven't had gnucash installed in /opt for quite a while now (or $HOME/.local) but I remember noticing that the resources for/opt were under a package directory. If the same situation (i.e. the ability to find program resources in a relative directory structure) applies for the installation in a user directory rather than installing directly under $HOME/.local we could recommend installing to a subdirectory of this location specifically for program installations and in turn create a directory under that for gnucash which would contain the executable and its resources. This would then facilitate easy removal of the package from a users home directory by simply deleting the package level directory to simplify things for inexperienced users. The above seems to be the case as I install development builds to an install subdirectory which is a subdirectory of a main directory which contains my gnucash sources and separate build directories for make and ninja etc and I have never detected that starting gnucash from the .../install/bin/gnucash executable has accessed resouces for production builds which I have installed in /usr/local. Can't be definitive about that but it has included changes to gnucash library files which appeared in the executable which wouldn't be the case if it was picking up libraries from the system installation. I guess this was the munge of the file locations that occurs with cmake for /opt and $HOME/.local type installations you referred to in an earlier post compared with installation in a system location. I.e. we recommend using cmake commands as follows for inexperienced or users who don't have admin privileges rather than simply installing directly under $HOME/.local which already has a gnucash directory for GnuCash user preferences. cmake -DCMAKE_INSTALL_PREFIX=$HOME/.local/programs/gnucash If you think this is a better idea (or there is another more general alternative I can update the Wiki build instructions to reflect this. The user could then create an alias in the bashrc file to access the executable and/or add it to their launcher etc. 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] About the "$HOME/.local" installation prefix
Hi John, It was because of a number of posts in the forum, not sure whether DEV or USER around the time I reworked the pages which suggested $HOME/.local for single user local installations of GnuCash . I think it may also have been specified the previous Wiki page I started from as well. At the time I could not find any better suggestions so I left it in place. My own preference has been to install in /usr/local or /opt system wide for production. If you use make uninstall from the build directory it seems to uninstall correctly from $HOME/.local as long as the manifest still exists as the paths to each file installed are specified If I do a local temporary install, I personally install in a subdirectory of my home directory and add the relevant search paths to the front of the PATH environment variable . You of course have the problem with the order in PATH as to whether you search $HOME directories before or after system installed paths if you have multiple copies of different versions. Ideally in that case you could invoke a startup script which setup the PATH variable depending on which version you are starting up and where its resouces are located. I have used /opt and /usr/local for different versions but the same problem with ordering the search order in PATH arises. Python installs what it calls site-packages under $HOME/.local which seem to be user specific but most of the other data I find in the directory is in $HOME/.local/share which seems to be mainly user specific data for various packages. The Linux File Heirarchy gives no real guidance for the structure of a users home directory apart from a reference to XDG and GLib conventions ( can't find any reference): https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html One stackexchange article suggested duplicating sections of the FHS under $HOME which seems a bit extreme. If I did that I would be inclined to have a specific directory under $HOME with the /bin, /etc, /lib /share directories under it. I have an Applications directory for that purpose usually with a package sub directory under that which contains the above directories. For the little development work on GnuCash I do I have a separate structure again under my home directory which has an install subdirectory which I install to. I have often wondered whether I am actually getting to the correct libraries by setting up the PATH variable (particularly if I forget to set it up). Then there is unsetting PATH when you want to go back to production work. Perhaps it is worth investigating the update-alternatives command used when several python versions are installed, e.g. https://askubuntu.com/questions/315646/update-java-alternatives-vs-update-alternatives-config-java. perhaps using this in startup scripts. Here the installed files are labelled with the version number and selected by setting a master and slave symbolic link groups which are setup with the "update-alternatives --set name path" command. Not sure what is the best location and structure for general users for a local installation though. I would be inclined to go for a directory labelled with a package name and version number with its own /bin, /etc, /lib and /share directories and then prepend these to the PATH. 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] About the "$HOME/.local" installation prefix
Correction: http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s13.html says that AT invented /opt for SYSV. http://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html is as close to canonical as one gets for what different parts of the file hierarchy are for and how they should be used. Regards, John Ralls > On May 2, 2019, at 10:03 AM, John Ralls wrote: > > AT Unix and the real BSD did have /usr/local as the place for installing > stuff not part of the system. Sun Microsystems started using that for their > Solaris extensions to BSD and invented /opt as the place for > locally-installed packages. Both typically require root to install into and > some distros have put stuff in one or the other, so care is advised when > using either. > > There's another problem: CMake treats both specially and munges the > subdirectory locations; this is worst with /opt as it insists on stuffing > etc/gnucash into a weird path under /etc so root is required for the install > step and gnucash can't find the environment file. > > I lean towards guiding inexperienced users toward keeping everything in their > home directories and away from using su or sudo for anything. > > Regards, > John Ralls > >> On May 2, 2019, at 9:40 AM, Colin Law wrote: >> >> On many varieties of Linux /usr/local is the conventional location to >> add locally built packages. In this case probably /usr/local/gnucash. >> I think the build instructions used to suggest that but I may be >> mistaken. >> >> Colin >> >> On Thu, 2 May 2019 at 17:27, Geert Janssens >> wrote: >>> >>> Op donderdag 2 mei 2019 18:03:22 CEST schreef Tommy Trussell: >>>> On Thu, May 2, 2019 at 6:02 AM Geert Janssens >>>> >>>> wrote: >>>>> Our current wiki on building gnucash for Ubuntu 16.04 (https:// >>>>> wiki.gnucash.org/wiki/BuildUbuntu16.04) suggests $HOME/.local as a valid >>>>> installation prefix. >>>> >>>> ... >>>> >>>>> So personally I would recommend against using $HOME/.local as installation >>>>> prefix. I am however curious where this suggestion originally came from. >>>> >>>> This is entirely speculation... I'm looking at this system where I've been >>>> testing the GnuCash versions available as Snap and Flatpak... and I see >>>> that the Flatpak installation apparently added >>>> ~/.local/share/flatpak/exports/share to the $XDG_DATA_DIRS environment >>>> variable. >>>> >>>> Maybe whoever wrote the wiki entry was also working with Flatpak and >>>> thought .local would be a good place to stash things to make them more >>>> accessible to Flatpak. >>>> >>> Possibly. >>> >>>> I would think ~/bin would be a more ideal suggestion because I see it is >>>> already defined in my bash $PATH on this Ubuntu machine. (And I'm pretty >>>> sure I didn't add it, though I may have.) >>> >>> That would be another alternative location. To have gnucash benefit from >>> ~/bin >>> being on the path though the gnucash binary itself should be ~/bin/gnucash. >>> >>> Translating this back to the required installation prefix would mean the >>> installation prefix should be $HOME. >>> >>> This is certainly possible but has the drawback the installation would add >>> extra directories in your home directory, like >>> ~/share >>> ~/etc >>> ~/lib(64) >>> ... >>> >>> That may be cluttering the home directory more than the average user may >>> like. >>> And in addition if someone is adding other binaries to ~/bin it again >>> becomes >>> more difficult to keep the gnucash build separate from everything else. >>> >>> To me something like Adrien suggested makes most sense. >>> One could add two extra steps to simplify launching gnucash afterwards: >>> - make a softlink from /bin/gnucash to >>> /home/bin/gnucash. >>> This would allow console users to simply type "gnucash" to run their own >>> gnucash build. >>> - copy /share/applications/gnucash.desktop to >>> ~/.local/share/applications >>> That should make you graphical environment aware of your self-built gnucash >>> and have it pop up in the usual places to launch applications (the Kicker >>> menu >>> on KDE, or the gnome-shell application launcher). >>> >>> Regards, >>> >>> Geert >>> >>> >>> ___ >>> 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 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] About the "$HOME/.local" installation prefix
AT Unix and the real BSD did have /usr/local as the place for installing stuff not part of the system. Sun Microsystems started using that for their Solaris extensions to BSD and invented /opt as the place for locally-installed packages. Both typically require root to install into and some distros have put stuff in one or the other, so care is advised when using either. There's another problem: CMake treats both specially and munges the subdirectory locations; this is worst with /opt as it insists on stuffing etc/gnucash into a weird path under /etc so root is required for the install step and gnucash can't find the environment file. I lean towards guiding inexperienced users toward keeping everything in their home directories and away from using su or sudo for anything. Regards, John Ralls > On May 2, 2019, at 9:40 AM, Colin Law wrote: > > On many varieties of Linux /usr/local is the conventional location to > add locally built packages. In this case probably /usr/local/gnucash. > I think the build instructions used to suggest that but I may be > mistaken. > > Colin > > On Thu, 2 May 2019 at 17:27, Geert Janssens > wrote: >> >> Op donderdag 2 mei 2019 18:03:22 CEST schreef Tommy Trussell: >>> On Thu, May 2, 2019 at 6:02 AM Geert Janssens >>> >>> wrote: >>>> Our current wiki on building gnucash for Ubuntu 16.04 (https:// >>>> wiki.gnucash.org/wiki/BuildUbuntu16.04) suggests $HOME/.local as a valid >>>> installation prefix. >>> >>> ... >>> >>>> So personally I would recommend against using $HOME/.local as installation >>>> prefix. I am however curious where this suggestion originally came from. >>> >>> This is entirely speculation... I'm looking at this system where I've been >>> testing the GnuCash versions available as Snap and Flatpak... and I see >>> that the Flatpak installation apparently added >>> ~/.local/share/flatpak/exports/share to the $XDG_DATA_DIRS environment >>> variable. >>> >>> Maybe whoever wrote the wiki entry was also working with Flatpak and >>> thought .local would be a good place to stash things to make them more >>> accessible to Flatpak. >>> >> Possibly. >> >>> I would think ~/bin would be a more ideal suggestion because I see it is >>> already defined in my bash $PATH on this Ubuntu machine. (And I'm pretty >>> sure I didn't add it, though I may have.) >> >> That would be another alternative location. To have gnucash benefit from >> ~/bin >> being on the path though the gnucash binary itself should be ~/bin/gnucash. >> >> Translating this back to the required installation prefix would mean the >> installation prefix should be $HOME. >> >> This is certainly possible but has the drawback the installation would add >> extra directories in your home directory, like >> ~/share >> ~/etc >> ~/lib(64) >> ... >> >> That may be cluttering the home directory more than the average user may >> like. >> And in addition if someone is adding other binaries to ~/bin it again becomes >> more difficult to keep the gnucash build separate from everything else. >> >> To me something like Adrien suggested makes most sense. >> One could add two extra steps to simplify launching gnucash afterwards: >> - make a softlink from /bin/gnucash to >> /home/bin/gnucash. >> This would allow console users to simply type "gnucash" to run their own >> gnucash build. >> - copy /share/applications/gnucash.desktop to >> ~/.local/share/applications >> That should make you graphical environment aware of your self-built gnucash >> and have it pop up in the usual places to launch applications (the Kicker >> menu >> on KDE, or the gnome-shell application launcher). >> >> Regards, >> >> Geert >> >> >> ___ >> 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: [GNC-dev] About the "$HOME/.local" installation prefix
On many varieties of Linux /usr/local is the conventional location to add locally built packages. In this case probably /usr/local/gnucash. I think the build instructions used to suggest that but I may be mistaken. Colin On Thu, 2 May 2019 at 17:27, Geert Janssens wrote: > > Op donderdag 2 mei 2019 18:03:22 CEST schreef Tommy Trussell: > > On Thu, May 2, 2019 at 6:02 AM Geert Janssens > > > > wrote: > > > Our current wiki on building gnucash for Ubuntu 16.04 (https:// > > > wiki.gnucash.org/wiki/BuildUbuntu16.04) suggests $HOME/.local as a valid > > > installation prefix. > > > > ... > > > > > So personally I would recommend against using $HOME/.local as installation > > > prefix. I am however curious where this suggestion originally came from. > > > > This is entirely speculation... I'm looking at this system where I've been > > testing the GnuCash versions available as Snap and Flatpak... and I see > > that the Flatpak installation apparently added > > ~/.local/share/flatpak/exports/share to the $XDG_DATA_DIRS environment > > variable. > > > > Maybe whoever wrote the wiki entry was also working with Flatpak and > > thought .local would be a good place to stash things to make them more > > accessible to Flatpak. > > > Possibly. > > > I would think ~/bin would be a more ideal suggestion because I see it is > > already defined in my bash $PATH on this Ubuntu machine. (And I'm pretty > > sure I didn't add it, though I may have.) > > That would be another alternative location. To have gnucash benefit from ~/bin > being on the path though the gnucash binary itself should be ~/bin/gnucash. > > Translating this back to the required installation prefix would mean the > installation prefix should be $HOME. > > This is certainly possible but has the drawback the installation would add > extra directories in your home directory, like > ~/share > ~/etc > ~/lib(64) > ... > > That may be cluttering the home directory more than the average user may like. > And in addition if someone is adding other binaries to ~/bin it again becomes > more difficult to keep the gnucash build separate from everything else. > > To me something like Adrien suggested makes most sense. > One could add two extra steps to simplify launching gnucash afterwards: > - make a softlink from /bin/gnucash to /home/bin/gnucash. > This would allow console users to simply type "gnucash" to run their own > gnucash build. > - copy /share/applications/gnucash.desktop to > ~/.local/share/applications > That should make you graphical environment aware of your self-built gnucash > and have it pop up in the usual places to launch applications (the Kicker menu > on KDE, or the gnome-shell application launcher). > > Regards, > > Geert > > > ___ > 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] About the "$HOME/.local" installation prefix
Op donderdag 2 mei 2019 18:03:22 CEST schreef Tommy Trussell: > On Thu, May 2, 2019 at 6:02 AM Geert Janssens > > wrote: > > Our current wiki on building gnucash for Ubuntu 16.04 (https:// > > wiki.gnucash.org/wiki/BuildUbuntu16.04) suggests $HOME/.local as a valid > > installation prefix. > > ... > > > So personally I would recommend against using $HOME/.local as installation > > prefix. I am however curious where this suggestion originally came from. > > This is entirely speculation... I'm looking at this system where I've been > testing the GnuCash versions available as Snap and Flatpak... and I see > that the Flatpak installation apparently added > ~/.local/share/flatpak/exports/share to the $XDG_DATA_DIRS environment > variable. > > Maybe whoever wrote the wiki entry was also working with Flatpak and > thought .local would be a good place to stash things to make them more > accessible to Flatpak. > Possibly. > I would think ~/bin would be a more ideal suggestion because I see it is > already defined in my bash $PATH on this Ubuntu machine. (And I'm pretty > sure I didn't add it, though I may have.) That would be another alternative location. To have gnucash benefit from ~/bin being on the path though the gnucash binary itself should be ~/bin/gnucash. Translating this back to the required installation prefix would mean the installation prefix should be $HOME. This is certainly possible but has the drawback the installation would add extra directories in your home directory, like ~/share ~/etc ~/lib(64) ... That may be cluttering the home directory more than the average user may like. And in addition if someone is adding other binaries to ~/bin it again becomes more difficult to keep the gnucash build separate from everything else. To me something like Adrien suggested makes most sense. One could add two extra steps to simplify launching gnucash afterwards: - make a softlink from /bin/gnucash to /home/bin/gnucash. This would allow console users to simply type "gnucash" to run their own gnucash build. - copy /share/applications/gnucash.desktop to ~/.local/share/applications That should make you graphical environment aware of your self-built gnucash and have it pop up in the usual places to launch applications (the Kicker menu on KDE, or the gnome-shell application launcher). Regards, Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] About the "$HOME/.local" installation prefix
> On May 2, 2019, at 4:01 AM, Geert Janssens wrote: > > Our current wiki on building gnucash for Ubuntu 16.04 (https:// > wiki.gnucash.org/wiki/BuildUbuntu16.04) suggests $HOME/.local as a valid > installation prefix. > > While checking for another thread I have found this to be problematic. > > In particular when using this installation prefix, a number of files and > directories will be added in $HOME/.local/share/. That directory however is > also to primary directory where a running applications store their runtime > data. So the same directory is being used as installation directory and data > directory. > > That makes it pretty difficult to quickly remove the local gnucash > installation in one go as the installation directory may also hold runtime > data (and from more than one application!). > > So personally I would recommend against using $HOME/.local as installation > prefix. I am however curious where this suggestion originally came from. A quick search of history shows it was added by David Cousens in https://wiki.gnucash.org/wiki/index.php?title=BuildUbuntu16.04=13834=13833. David, what led you to use that directory? Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] About the "$HOME/.local" installation prefix
Yes, something like that would make more sense to me as well. Op donderdag 2 mei 2019 17:03:53 CEST schreef Adrien Monteleone: > Good question. > > I’ve never used that location, and have not otherwise seen any > recommendation to use it for a single/local-user installation. > > I’ve seen people recommend to recreate the official tree under ~/ (~/usr, > ~/usr/local, ~/usr/bin) which doesn’t make much sense to me, or something > else like: > > ~/apps, ~/applications > > I would think a recommendation of: > > $HOME/apps/gnucash, $HOME/applications/gnucash > > would be fine as it would be easier to remove. (one could maybe keep a > `$HOME/apps/gnucash/build` directory around for that eventual removal) > > Regards, > Adrien > > > On May 2, 2019, at 6:01 AM, Geert Janssens > > wrote: > > > > Our current wiki on building gnucash for Ubuntu 16.04 (https:// > > wiki.gnucash.org/wiki/BuildUbuntu16.04) suggests $HOME/.local as a valid > > installation prefix. > > > > While checking for another thread I have found this to be problematic. > > > > In particular when using this installation prefix, a number of files and > > directories will be added in $HOME/.local/share/. That directory however > > is > > also to primary directory where a running applications store their runtime > > data. So the same directory is being used as installation directory and > > data directory. > > > > That makes it pretty difficult to quickly remove the local gnucash > > installation in one go as the installation directory may also hold runtime > > data (and from more than one application!). > > > > So personally I would recommend against using $HOME/.local as installation > > prefix. I am however curious where this suggestion originally came from. > > > > Regards, > > > > Geert > > ___ > 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] About the "$HOME/.local" installation prefix
On Thu, May 2, 2019 at 6:02 AM Geert Janssens wrote: > Our current wiki on building gnucash for Ubuntu 16.04 (https:// > wiki.gnucash.org/wiki/BuildUbuntu16.04) suggests $HOME/.local as a valid > installation prefix. > ... > So personally I would recommend against using $HOME/.local as installation > prefix. I am however curious where this suggestion originally came from. > This is entirely speculation... I'm looking at this system where I've been testing the GnuCash versions available as Snap and Flatpak... and I see that the Flatpak installation apparently added ~/.local/share/flatpak/exports/share to the $XDG_DATA_DIRS environment variable. Maybe whoever wrote the wiki entry was also working with Flatpak and thought .local would be a good place to stash things to make them more accessible to Flatpak. I would think ~/bin would be a more ideal suggestion because I see it is already defined in my bash $PATH on this Ubuntu machine. (And I'm pretty sure I didn't add it, though I may have.) ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] About the "$HOME/.local" installation prefix
Good question. I’ve never used that location, and have not otherwise seen any recommendation to use it for a single/local-user installation. I’ve seen people recommend to recreate the official tree under ~/ (~/usr, ~/usr/local, ~/usr/bin) which doesn’t make much sense to me, or something else like: ~/apps, ~/applications I would think a recommendation of: $HOME/apps/gnucash, $HOME/applications/gnucash would be fine as it would be easier to remove. (one could maybe keep a `$HOME/apps/gnucash/build` directory around for that eventual removal) Regards, Adrien > On May 2, 2019, at 6:01 AM, Geert Janssens wrote: > > Our current wiki on building gnucash for Ubuntu 16.04 (https:// > wiki.gnucash.org/wiki/BuildUbuntu16.04) suggests $HOME/.local as a valid > installation prefix. > > While checking for another thread I have found this to be problematic. > > In particular when using this installation prefix, a number of files and > directories will be added in $HOME/.local/share/. That directory however is > also to primary directory where a running applications store their runtime > data. So the same directory is being used as installation directory and data > directory. > > That makes it pretty difficult to quickly remove the local gnucash > installation in one go as the installation directory may also hold runtime > data (and from more than one application!). > > So personally I would recommend against using $HOME/.local as installation > prefix. I am however curious where this suggestion originally came from. > > Regards, > > Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[GNC-dev] About the "$HOME/.local" installation prefix
Our current wiki on building gnucash for Ubuntu 16.04 (https:// wiki.gnucash.org/wiki/BuildUbuntu16.04) suggests $HOME/.local as a valid installation prefix. While checking for another thread I have found this to be problematic. In particular when using this installation prefix, a number of files and directories will be added in $HOME/.local/share/. That directory however is also to primary directory where a running applications store their runtime data. So the same directory is being used as installation directory and data directory. That makes it pretty difficult to quickly remove the local gnucash installation in one go as the installation directory may also hold runtime data (and from more than one application!). So personally I would recommend against using $HOME/.local as installation prefix. I am however curious where this suggestion originally came from. Regards, Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Mac Installation
John, Thanks, I’ll take a look. Regards, Adrien > On Dec 4, 2018, at 11:02 PM, John Ralls wrote: > > > >> On Dec 5, 2018, at 1:49 PM, Adrien Monteleone >> wrote: >> >> There seems to be a rash of confusion with installing on MacOS suddenly. >> I’ve been lurking here for a few years and never noticed this before. Has >> this been a problem in the past? >> >> I think I have a grasp on the general principle of how some other software >> "holds users’ hands” and guides them to drag the .app over an /Applications >> soft-link to ‘install’. >> >> I understand the small pool of devs are busy with more pressing matters. If >> there are no objections, I don’t mind doing the homework digging up details >> to craft a similar .dmg Finder window for GnuCash. I’d of course use artwork >> from the website for branding consistency. >> >> I’ll hazard the presumption based on my experience here that John Ralls is >> the packager for MacOS. Thoughts? Requirements? >> >> I’ll also presume any such packaging changes need to be PR’d somewhere. Is >> this to maint? master? (sorry, need to brush up on the procedures and >> branches) > > Adrien, > > Yes, I do the mac bundles along with everything else associated with > releases. Any images and scripts would go in > https://github.com/gnucash/gnucash-on-osx. The Gnu Emacs folks have it set up > so you can probably borrow from them. > > Regards, > John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Mac Installation
> On Dec 5, 2018, at 1:49 PM, Adrien Monteleone > wrote: > > There seems to be a rash of confusion with installing on MacOS suddenly. I’ve > been lurking here for a few years and never noticed this before. Has this > been a problem in the past? > > I think I have a grasp on the general principle of how some other software > "holds users’ hands” and guides them to drag the .app over an /Applications > soft-link to ‘install’. > > I understand the small pool of devs are busy with more pressing matters. If > there are no objections, I don’t mind doing the homework digging up details > to craft a similar .dmg Finder window for GnuCash. I’d of course use artwork > from the website for branding consistency. > > I’ll hazard the presumption based on my experience here that John Ralls is > the packager for MacOS. Thoughts? Requirements? > > I’ll also presume any such packaging changes need to be PR’d somewhere. Is > this to maint? master? (sorry, need to brush up on the procedures and > branches) Adrien, Yes, I do the mac bundles along with everything else associated with releases. Any images and scripts would go in https://github.com/gnucash/gnucash-on-osx. The Gnu Emacs folks have it set up so you can probably borrow from them. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[GNC-dev] Mac Installation
There seems to be a rash of confusion with installing on MacOS suddenly. I’ve been lurking here for a few years and never noticed this before. Has this been a problem in the past? I think I have a grasp on the general principle of how some other software "holds users’ hands” and guides them to drag the .app over an /Applications soft-link to ‘install’. I understand the small pool of devs are busy with more pressing matters. If there are no objections, I don’t mind doing the homework digging up details to craft a similar .dmg Finder window for GnuCash. I’d of course use artwork from the website for branding consistency. I’ll hazard the presumption based on my experience here that John Ralls is the packager for MacOS. Thoughts? Requirements? I’ll also presume any such packaging changes need to be PR’d somewhere. Is this to maint? master? (sorry, need to brush up on the procedures and branches) Regards, Adrien ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Windows installation size, nightly
Indeed. This is because from that point on the documentation ships with images again. They have been missing for a while. Regards, Geert Op vrijdag 21 september 2018 10:52:37 CEST schreef cicko: > FYI, a couple of days ago the installation size for Windows nightlies jumped > from 95 to 157 MB. A significant increase for what I hoped were the new > features. ;) > Just a quick question on whether this was intentional and/or if the size can > be brought back down again. > > https://imgur.com/Uga1ckd > > Cheers > > > > -- > 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
[GNC-dev] Windows installation size, nightly
FYI, a couple of days ago the installation size for Windows nightlies jumped from 95 to 157 MB. A significant increase for what I hoped were the new features. ;) Just a quick question on whether this was intentional and/or if the size can be brought back down again. https://imgur.com/Uga1ckd Cheers -- 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: Fix for installation of HTML Help Workshop on Windows Vista more recent
On Saturday 28 June 2014 15:52:07 Geert Janssens wrote: Thanks for the heads up. I'm not sure why I didn't notice this. There is no hhc anywhere on the path at this point. There may have been one before, I don't recall. In any case I'm testing a fix now. It's a one-line fix. You may want to test it already as well before I push it: In install-imple.sh, change line 1161 from add_to_env $_HH_UDIR PATH to add_to_env $_HH_SYS_UDIR PATH The patch needed some quotes still but the version I committed just now works ok for me. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Fix for installation of HTML Help Workshop on Windows Vista more recent
On Wednesday 25 June 2014 18:38:39 Wm wrote: Tue, 17 Jun 2014 19:26:56 13239941.bj5nrgt...@legolas.kobaltwit.lan Geert Janssens janssens-ge...@telenet.be [quote reordered] On Tuesday 17 June 2014 18:05:28 Geert Janssens wrote: I have just pushed a number of commits to gnucash-on-windows that hopefully fixes the issue that HTML Help Workshop could not be installed on Windows Vista and more recent due to insufficient privileges. I don't have such a Windows system so I need some volunteers to test it and give feedback. The way to test would be to set up a development environment on Windows following the instructions here: https://github.com/Gnucash/gnucash-on-windows/blob/master/README If you already have a development environment set up based on the gnucash-on-windows repository you can skip the basic set up and just remove HTML Help Workshop via the Windows control panel and rerun install.sh What I hope is that you can successfully install HTML Help Workshop when during the corresponding step. On Windows Vista and more recent I expect Windows to show a UAC which you should grant. In all cases, please keep in mind that you should *NOT* install HTML Help Workshop in the gcdev directories. Just install it in the default location somewhere under Program Files or similar. This has the added benefit that one single installation is ever needed. If you set up multiple development environments for gnucash, they will all use the same HH installation. I'm looking forward for all feedback. I just found a bug in my own code: if you install HTML Help Workshop in a path containing spaces the gnucash build step will fail. I'm looking into this right now. The htmlhelp step itself should work though. I haven't checked what else has changed [1] (obviously boost is new) but === \gcdev\gnucash-on-windows.git\install-impl.sh line 1419 is breaking the build as the PATH to hhc isn't being remembered from (I think) === function inst_hh () 1146_HH_UDIR=`unix_path $HH_DIR` 1147_HH_SYS_UDIR=`unix_path $HH_SYS_DIR` === so === function make_chm() 1418echo Will now call hhc.exe for $_CHM_TYPE ($_CHM_LANG)... 1419hhc htmlhelp.hhp /dev/null || true 1420echo ... hhc.exe completed successfully. === can't find hhc. if I change line 1419 to === /c/e/progs/hh/hhc htmlhelp.hhp /dev/null || true === where: /c/e/progs/hh/ is my new HH location with no spaces it builds OK so finding hhc in the PATH is the issue. I'm guessing that when you moved HH out of the build directory the PATH to hhc.exe was in your environment so you didn't notice the HH DIR related changes in inst_hh() Thanks for the heads up. I'm not sure why I didn't notice this. There is no hhc anywhere on the path at this point. There may have been one before, I don't recall. In any case I'm testing a fix now. It's a one-line fix. You may want to test it already as well before I push it: In install-imple.sh, change line 1161 from add_to_env $_HH_UDIR PATH to add_to_env $_HH_SYS_UDIR PATH [1] I had [2] given up on your build + python and moved my attention to building under cygwin and understanding how applications like GIMP that need python and work on Win just as well as *nix manage what we (or at least I) seem unable to do. [2] language note: had past tense. I'll have another go but the whole gnc + python (not just on Win) all seems very flaky. [3] [3] This is probably better suited for another thread but there are some parts of configure that I don't believe could ever have resulted in a working gnc+python under Win. Maybe a working gnc+python has never actually happened and is actually mythical? I thought I'd be formalising something extant ... I don't recall offhand where you started and what your goal is. I have successfully used the python bindings to synchronize data between an inhouse inventory system (based on postgresql and - yuck - MS Access 2000). This relied on querying several business objects, accounts, transactions, lots and splits. So that part did work well at least in the 2.4 series. I haven't ported my scripts to 2.6 because we switched to a different system around the same time. So I would indeed think you were formalising something existent. But from what I've read and heard it's pretty ugly to get python on Windows to cooperate with mingw based applications. I have never tried that because I'm on linux 99% of my time. I tried to follow your progress but I don't have enough spare time lately :( So it's still in my queue somewhere. I'll let you know when I get to it. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Fix for installation of HTML Help Workshop on Windows Vista more recent
Tue, 17 Jun 2014 19:26:56 13239941.bj5nrgt...@legolas.kobaltwit.lan Geert Janssens janssens-ge...@telenet.be [quote reordered] On Tuesday 17 June 2014 18:05:28 Geert Janssens wrote: I have just pushed a number of commits to gnucash-on-windows that hopefully fixes the issue that HTML Help Workshop could not be installed on Windows Vista and more recent due to insufficient privileges. I don't have such a Windows system so I need some volunteers to test it and give feedback. The way to test would be to set up a development environment on Windows following the instructions here: https://github.com/Gnucash/gnucash-on-windows/blob/master/README If you already have a development environment set up based on the gnucash-on-windows repository you can skip the basic set up and just remove HTML Help Workshop via the Windows control panel and rerun install.sh What I hope is that you can successfully install HTML Help Workshop when during the corresponding step. On Windows Vista and more recent I expect Windows to show a UAC which you should grant. In all cases, please keep in mind that you should *NOT* install HTML Help Workshop in the gcdev directories. Just install it in the default location somewhere under Program Files or similar. This has the added benefit that one single installation is ever needed. If you set up multiple development environments for gnucash, they will all use the same HH installation. I'm looking forward for all feedback. I just found a bug in my own code: if you install HTML Help Workshop in a path containing spaces the gnucash build step will fail. I'm looking into this right now. The htmlhelp step itself should work though. I haven't checked what else has changed [1] (obviously boost is new) but === \gcdev\gnucash-on-windows.git\install-impl.sh line 1419 is breaking the build as the PATH to hhc isn't being remembered from (I think) === function inst_hh () 1146_HH_UDIR=`unix_path $HH_DIR` 1147_HH_SYS_UDIR=`unix_path $HH_SYS_DIR` === so === function make_chm() 1418echo Will now call hhc.exe for $_CHM_TYPE ($_CHM_LANG)... 1419hhc htmlhelp.hhp /dev/null || true 1420echo ... hhc.exe completed successfully. === can't find hhc. if I change line 1419 to === /c/e/progs/hh/hhc htmlhelp.hhp /dev/null || true === where: /c/e/progs/hh/ is my new HH location with no spaces it builds OK so finding hhc in the PATH is the issue. I'm guessing that when you moved HH out of the build directory the PATH to hhc.exe was in your environment so you didn't notice the HH DIR related changes in inst_hh() [1] I had [2] given up on your build + python and moved my attention to building under cygwin and understanding how applications like GIMP that need python and work on Win just as well as *nix manage what we (or at least I) seem unable to do. [2] language note: had past tense. I'll have another go but the whole gnc + python (not just on Win) all seems very flaky. [3] [3] This is probably better suited for another thread but there are some parts of configure that I don't believe could ever have resulted in a working gnc+python under Win. Maybe a working gnc+python has never actually happened and is actually mythical? I thought I'd be formalising something extant ... -- Wm... ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Fix for installation of HTML Help Workshop on Windows Vista more recent
I have just pushed a number of commits to gnucash-on-windows that hopefully fixes the issue that HTML Help Workshop could not be installed on Windows Vista and more recent due to insufficient privileges. I don't have such a Windows system so I need some volunteers to test it and give feedback. The way to test would be to set up a development environment on Windows following the instructions here: https://github.com/Gnucash/gnucash-on-windows/blob/master/README If you already have a development environment set up based on the gnucash-on-windows repository you can skip the basic set up and just remove HTML Help Workshop via the Windows control panel and rerun install.sh What I hope is that you can successfully install HTML Help Workshop when during the corresponding step. On Windows Vista and more recent I expect Windows to show a UAC which you should grant. In all cases, please keep in mind that you should *NOT* install HTML Help Workshop in the gcdev directories. Just install it in the default location somewhere under Program Files or similar. This has the added benefit that one single installation is ever needed. If you set up multiple development environments for gnucash, they will all use the same HH installation. I'm looking forward for all feedback. Regards, Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r20501 - gnucash/trunk/packaging/win32 - During win32 build, if a component is already installed, print the installation path
Phil,
Should this get back-ported to 2.4? You didn't mark it BP.
-derek
Phil Longstaff plongst...@code.gnucash.org writes:
Author: plongstaff
Date: 2011-03-28 21:17:00 -0400 (Mon, 28 Mar 2011)
New Revision: 20501
Trac: http://svn.gnucash.org/trac/changeset/20501
Modified:
gnucash/trunk/packaging/win32/install-impl.sh
Log:
During win32 build, if a component is already installed, print the
installation path
Modified: gnucash/trunk/packaging/win32/install-impl.sh
===
--- gnucash/trunk/packaging/win32/install-impl.sh 2011-03-28 18:51:22 UTC
(rev 20500)
+++ gnucash/trunk/packaging/win32/install-impl.sh 2011-03-29 01:17:00 UTC
(rev 20501)
@@ -66,7 +66,7 @@
add_to_env $_WGET_UDIR/bin PATH
if quiet $_WGET_UDIR/wget --version || quiet wget --version
then
-echo already installed. skipping.
+echo already installed in $_WGET_UDIR/bin. skipping.
else
mkdir -p $_WGET_UDIR/bin
tar -xjpf $DOWNLOAD_UDIR/wget*.tar.bz2 -C $_WGET_UDIR
@@ -80,7 +80,7 @@
_MSYS_UDIR=`unix_path $MSYS_DIR`
if quiet ${_MSYS_UDIR}/bin/perl --help [ check_m4_version_ok ]
then
-echo msys dtk already installed. skipping.
+echo msys dtk already installed in ${_MSYS_UDIR}. skipping.
else
smart_wget $DTK_URL $DOWNLOAD_DIR
$LAST_FILE //SP- //SILENT //DIR=$MSYS_DIR
@@ -117,7 +117,7 @@
if quiet test_for_mingw
then
-echo mingw already installed.
+echo mingw already installed in $_MINGW_UDIR. skipping.
else
mkdir -p $_MINGW_UDIR
if [ $CROSS_COMPILE != yes ]; then
@@ -150,7 +150,7 @@
add_to_env $_UNZIP_UDIR/bin PATH
if quiet $_UNZIP_UDIR/bin/unzip --help || quiet unzip --help
then
-echo unzip already installed. skipping.
+echo unzip already installed in $_UNZIP_UDIR. skipping.
else
smart_wget $UNZIP_URL $DOWNLOAD_DIR
$LAST_FILE //SP- //SILENT //DIR=$UNZIP_DIR
@@ -167,7 +167,7 @@
add_to_env $_REGEX_UDIR/bin PATH
if quiet ${LD} $REGEX_LDFLAGS -o $TMP_UDIR/ofile
then
-echo regex already installed. skipping.
+echo regex already installed in $_REGEX_UDIR. skipping.
else
mkdir -p $_REGEX_UDIR
wget_unpacked $REGEX_URL $DOWNLOAD_DIR $REGEX_DIR
@@ -184,7 +184,7 @@
add_to_env $_READLINE_UDIR/bin PATH
if quiet ${LD} $READLINE_LDFLAGS -lreadline -o $TMP_UDIR/ofile
then
-echo readline already installed. skipping.
+echo readline already installed in $_READLINE_UDIR. skipping.
else
mkdir -p $_READLINE_UDIR
wget_unpacked $READLINE_BIN_URL $DOWNLOAD_DIR $READLINE_DIR
@@ -200,7 +200,7 @@
set_env_or_die $_ACTIVE_PERL_WFSDIR/ActivePerl/Perl/bin/perl
INTLTOOL_PERL
if quiet $INTLTOOL_PERL --help
then
-echo ActivePerl already installed. skipping.
+echo ActivePerl already installed IN $_ACTIVE_PERL_UDIR. skipping.
else
wget_unpacked $ACTIVE_PERL_URL $DOWNLOAD_DIR $ACTIVE_PERL_DIR
qpushd $_ACTIVE_PERL_UDIR
@@ -219,7 +219,7 @@
add_to_env -L$_AUTOTOOLS_UDIR/lib AUTOTOOLS_LDFLAGS
if quiet autoconf --help quiet automake --help
then
-echo autoconf/automake already installed. skipping.
+echo autoconf/automake already installed in $_AUTOTOOLS_UDIR.
skipping.
else
wget_unpacked $AUTOCONF_URL $DOWNLOAD_DIR $TMP_DIR
wget_unpacked $AUTOMAKE_URL $DOWNLOAD_DIR $TMP_DIR
@@ -268,7 +268,7 @@
add_to_env ${_GMP_UDIR}/bin PATH
if quiet ${LD} $GMP_LDFLAGS -lgmp -o $TMP_UDIR/ofile
then
-echo Gmp already installed. skipping.
+echo Gmp already installed in ${_GMP_UDIR}. skipping.
else
wget_unpacked $GMP_URL $DOWNLOAD_DIR $TMP_DIR
assert_one_dir $TMP_UDIR/gmp-*
@@ -296,7 +296,7 @@
add_to_env $_GUILE_UDIR/bin PATH
if quiet guile -c '(use-modules (srfi srfi-39))'
then
-echo guile already installed. skipping.
+echo guile and slib already installed in $_GUILE_UDIR. skipping.
else
smart_wget $GUILE_URL $DOWNLOAD_DIR
_GUILE_BALL=$LAST_FILE
@@ -370,7 +370,7 @@
add_to_env $_SVN_UDIR/bin PATH
if quiet $_SVN_UDIR/bin/svn --version
then
-echo subversion already installed. skipping.
+echo subversion already installed in $_SVN_UDIR. skipping.
else
wget_unpacked $SVN_URL $DOWNLOAD_DIR $TMP_DIR
assert_one_dir $TMP_UDIR/svn-win32-*
@@ -396,7 +396,7 @@
fi
if quiet ${LD} -L$_OPENSSL_UDIR/lib -leay32 -lssl32 -o $TMP_UDIR/ofile ;
then
-echo openssl already installed. skipping.
+echo openssl already installed in $_OPENSSL_UDIR. skipping.
else
smart_wget $OPENSSL_URL
Re: r20501 - gnucash/trunk/packaging/win32 - During win32 build, if a component is already installed, print the installation path
No, it didn't and probably should.
The next change I want to check in adds version number to the component
directories so we'll have /c/soft/readline-5.0-1 instead of /c/soft/readline,
for example. I needed this change to just check that it is looking in the
right
place when it thinks that a dependency already exists. As I've been trying to
get a new webkit build going, I find this really helps with keeping parallel
versions of dependencies separate. It will also have the benefit that if a
version of a dependency is updated in defaults.sh, it would go into a new
directory which will force that dependency to be downloaded and/or built and we
won't need to remember to just remove the directory. I guess the bad
side-effect is that obsolete versions of dependencies could build up.
Phil
-
I used to be a hypochondriac AND a kleptomaniac. So I took something for it.
From: Derek Atkins warl...@mit.edu
To: gnucash-devel@gnucash.org
Sent: Tue, March 29, 2011 11:19:42 AM
Subject: Re: r20501 - gnucash/trunk/packaging/win32 - During win32 build, if a
component is already installed, print the installation path
Phil,
Should this get back-ported to 2.4? You didn't mark it BP.
-derek
Phil Longstaff plongst...@code.gnucash.org writes:
Author: plongstaff
Date: 2011-03-28 21:17:00 -0400 (Mon, 28 Mar 2011)
New Revision: 20501
Trac: http://svn.gnucash.org/trac/changeset/20501
Modified:
gnucash/trunk/packaging/win32/install-impl.sh
Log:
During win32 build, if a component is already installed, print the
installation
path
Modified: gnucash/trunk/packaging/win32/install-impl.sh
===
--- gnucash/trunk/packaging/win32/install-impl.sh2011-03-28 18:51:22 UTC
(rev 20500)
+++ gnucash/trunk/packaging/win32/install-impl.sh2011-03-29 01:17:00 UTC
(rev 20501)
@@ -66,7 +66,7 @@
add_to_env $_WGET_UDIR/bin PATH
if quiet $_WGET_UDIR/wget --version || quiet wget --version
then
-echo already installed. skipping.
+echo already installed in $_WGET_UDIR/bin. skipping.
else
mkdir -p $_WGET_UDIR/bin
tar -xjpf $DOWNLOAD_UDIR/wget*.tar.bz2 -C $_WGET_UDIR
@@ -80,7 +80,7 @@
_MSYS_UDIR=`unix_path $MSYS_DIR`
if quiet ${_MSYS_UDIR}/bin/perl --help [ check_m4_version_ok ]
then
-echo msys dtk already installed. skipping.
+echo msys dtk already installed in ${_MSYS_UDIR}. skipping.
else
smart_wget $DTK_URL $DOWNLOAD_DIR
$LAST_FILE //SP- //SILENT //DIR=$MSYS_DIR
@@ -117,7 +117,7 @@
if quiet test_for_mingw
then
-echo mingw already installed.
+echo mingw already installed in $_MINGW_UDIR. skipping.
else
mkdir -p $_MINGW_UDIR
if [ $CROSS_COMPILE != yes ]; then
@@ -150,7 +150,7 @@
add_to_env $_UNZIP_UDIR/bin PATH
if quiet $_UNZIP_UDIR/bin/unzip --help || quiet unzip --help
then
-echo unzip already installed. skipping.
+echo unzip already installed in $_UNZIP_UDIR. skipping.
else
smart_wget $UNZIP_URL $DOWNLOAD_DIR
$LAST_FILE //SP- //SILENT //DIR=$UNZIP_DIR
@@ -167,7 +167,7 @@
add_to_env $_REGEX_UDIR/bin PATH
if quiet ${LD} $REGEX_LDFLAGS -o $TMP_UDIR/ofile
then
-echo regex already installed. skipping.
+echo regex already installed in $_REGEX_UDIR. skipping.
else
mkdir -p $_REGEX_UDIR
wget_unpacked $REGEX_URL $DOWNLOAD_DIR $REGEX_DIR
@@ -184,7 +184,7 @@
add_to_env $_READLINE_UDIR/bin PATH
if quiet ${LD} $READLINE_LDFLAGS -lreadline -o $TMP_UDIR/ofile
then
-echo readline already installed. skipping.
+echo readline already installed in $_READLINE_UDIR. skipping.
else
mkdir -p $_READLINE_UDIR
wget_unpacked $READLINE_BIN_URL $DOWNLOAD_DIR $READLINE_DIR
@@ -200,7 +200,7 @@
set_env_or_die $_ACTIVE_PERL_WFSDIR/ActivePerl/Perl/bin/perl
INTLTOOL_PERL
if quiet $INTLTOOL_PERL --help
then
-echo ActivePerl already installed. skipping.
+echo ActivePerl already installed IN $_ACTIVE_PERL_UDIR. skipping.
else
wget_unpacked $ACTIVE_PERL_URL $DOWNLOAD_DIR $ACTIVE_PERL_DIR
qpushd $_ACTIVE_PERL_UDIR
@@ -219,7 +219,7 @@
add_to_env -L$_AUTOTOOLS_UDIR/lib AUTOTOOLS_LDFLAGS
if quiet autoconf --help quiet automake --help
then
-echo autoconf/automake already installed. skipping.
+echo autoconf/automake already installed in $_AUTOTOOLS_UDIR.
skipping.
else
wget_unpacked $AUTOCONF_URL $DOWNLOAD_DIR $TMP_DIR
wget_unpacked $AUTOMAKE_URL $DOWNLOAD_DIR $TMP_DIR
@@ -268,7 +268,7 @@
add_to_env ${_GMP_UDIR}/bin PATH
if quiet ${LD} $GMP_LDFLAGS -lgmp -o $TMP_UDIR/ofile
then
-echo Gmp already installed. skipping
Re: r20501 - gnucash/trunk/packaging/win32 - During win32 build, if a component is already installed, print the installation path
Phil Longstaff plongst...@rogers.com writes: No, it didn't and probably should. I believe it should. The next change I want to check in adds version number to the component directories so we'll have /c/soft/readline-5.0-1 instead of /c/soft/readline, for example. I needed this change to just check that it is looking in the right place when it thinks that a dependency already exists. As I've been trying to get a new webkit build going, I find this really helps with keeping parallel versions of dependencies separate. It will also have the benefit that if a version of a dependency is updated in defaults.sh, it would go into a new directory which will force that dependency to be downloaded and/or built and we won't need to remember to just remove the directory. I guess the bad side-effect is that obsolete versions of dependencies could build up. I think there are plusses and minuses to this approach. It would certainly solve the problem of we want to update a dependency but the build server wont see it. On the other hand it might not gracefully handle the updating a dependency requires a clean rebuild issues. There are times when it's nice to be able to use your already-built dependencies. Then there are times when it would be nice to be able to use the new ones. I guess the down side is that we're at the mercy of the upstream provides to continue to publish their older versions of our dependencies. How often do our dependency download URLs go bad? * goes back to pondering this one * (FYI, I believe this change, if you make it, should NOT be back ported) Phil -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Installation manual
Hi, I would like to install GnuCash with SQLite 3.* on Windows. But I cannot find any installation documentation! Do you not have any? Can you help me please and let me know if you do have any installation documentation. Thank you John Johal ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r18495 - gnucash/trunk/packaging/win32 - Fix #586122 (follow-up to r18488) by using aqbanking/version.h from its installation path.
Christian,
Thank you for fixing this further. I didn't find the time to do it.
Geert
On Sunday 13 December 2009, Christian Stimming wrote:
Author: cstim
Date: 2009-12-13 16:16:25 -0500 (Sun, 13 Dec 2009)
New Revision: 18495
Trac: http://svn.gnucash.org/trac/changeset/18495
Modified:
gnucash/trunk/packaging/win32/dist.sh
gnucash/trunk/packaging/win32/gnucash.iss.in
Log:
Fix #586122 (follow-up to r18488) by using aqbanking/version.h from its
installation path.
Also look up the gwenhywfar so-name accordingly.
Modified: gnucash/trunk/packaging/win32/dist.sh
===
--- gnucash/trunk/packaging/win32/dist.sh 2009-12-13 19:22:12 UTC (rev
18494) +++ gnucash/trunk/packaging/win32/dist.sh 2009-12-13 21:16:25 UTC
(rev 18495) @@ -229,10 +229,12 @@
cp -a $_REPOS_UDIR/packaging/win32/install-fq-mods.cmd $DIST_UDIR/bin
_QTDIR_WIN=`echo $QTDIR | sed 's,^/\([A-Za-z]\)/,\1:/,g' `
-_AQBANKING_SO_EFFECTIVE=$(awk '/AQBANKING_SO_EFFECTIVE/ { print $3 }'
$TMP_UDIR/aqbanking-*/version.h ) +_AQBANKING_SO_EFFECTIVE=$(awk
'/AQBANKING_SO_EFFECTIVE/ { print $3 }'
${_AQBANKING_UDIR}/include/aqbanking/version.h ) +
_GWENHYWFAR_SO_EFFECTIVE=$(awk '/GWENHYWFAR_SO_EFFECTIVE/ { print $3 }'
${_AQBANKING_UDIR}/include/gwenhywfar3/gwenhywfar/version.h ) sed
$_BUILD_UDIR/packaging/win32/gnucash.iss \
$_GNUCASH_UDIR/gnucash.iss \
-e s...@-qtbindir-@#${_QTDIR_WIN}/bin#g \
+ -e s...@-gwenhywfar_so_effective-@#${_GWENHYWFAR_SO_EFFECTIVE}#g \
-e s...@-aqbanking_so_effective-@#${_AQBANKING_SO_EFFECTIVE}#g
}
Modified: gnucash/trunk/packaging/win32/gnucash.iss.in
===
--- gnucash/trunk/packaging/win32/gnucash.iss.in 2009-12-13 19:22:12 UTC
(rev 18494) +++ gnucash/trunk/packaging/win32/gnucash.iss.in 2009-12-13
21:16:25 UTC (rev 18495) @@ -129,7 +129,7 @@
Root: HKLM; Subkey: Software\Gwenhywfar\Paths; ValueType: none; Flags:
uninsdeletekeyifempty Root: HKLM; Subkey: Software\Gwenhywfar\Paths;
ValueType: string; ValueName: prefix; ValueData: {app}; Flags:
uninsdeletevalue Root: HKLM; Subkey: Software\Gwenhywfar\Paths;
ValueType: string; ValueName: libdir; ValueData: {app}\lib; Flags:
uninsdeletevalue -Root: HKLM; Subkey: Software\Gwenhywfar\Paths;
ValueType: string; ValueName: plugindir; ValueData:
{app}\lib\gwenhywfar\plugins\38; Flags: uninsdeletevalue +Root: HKLM;
Subkey: Software\Gwenhywfar\Paths; ValueType: string; ValueName:
plugindir; ValueData:
{app}\lib\gwenhywfar\plugi...@-gwenhywfar_so_effective-@; Flags:
uninsdeletevalue Root: HKLM; Subkey: Software\Gwenhywfar\Paths;
ValueType: string; ValueName: sysconfdir; ValueData: {app}\etc; Flags:
uninsdeletevalue Root: HKLM; Subkey: Software\Gwenhywfar\Paths;
ValueType: string; ValueName: localedir; ValueData: {app}\share\locale;
Flags: uninsdeletevalue
___
gnucash-changes mailing list
gnucash-chan...@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-changes
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Help Gnu cash installation
Sir, How can I install Gnu Cash in a Debian system? Please help me. -- Sreejith Koiloth ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Help Gnu cash installation
On Thursday 13 August 2009, Sreejith Koiloth wrote: Sir, How can I install Gnu Cash in a Debian system? Please help me. apt-get install gnucash ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Help Gnu cash installation
See: http://wiki.gnucash.org/wiki/Debian --- On Thu, 8/13/09, Sreejith Koiloth sreejithkoil...@gmail.com wrote: From: Sreejith Koiloth sreejithkoil...@gmail.com Subject: Help Gnu cash installation To: gnucash-u...@gnucash.org, gnucash-devel@gnucash.org Date: Thursday, August 13, 2009, 4:06 AM Sir, How can I install Gnu Cash in a Debian system? Please help me. -- Sreejith Koiloth ___ gnucash-user mailing list gnucash-u...@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-user - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Test of new mailman server installation.
This is a test of the new email list server. You can safely ignore this email. -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gnucash compilation and installation from svn: why a gnome druid [solved]
Well, I found why gnucash, anjuta and others crash! I found the answer on this web page: http://xlife.zuavra.net/index.php/52/ I just had to modify the paths like this: LD_PRELOAD=/usr/lib/libglade/2.0/libgnome.so /usr/lib/libglade/2.0/libbonobo.so gnucash idem with anjuta and others! So (all ?) gnucash runs when the good (of libglade 2.0) libgnome.so and libbonobo are loaded; not those in /usr/lib, but those in /usr/lib/libglade/2.0 ! Is libglade becoming obsolete ? deprecated ? Why gnucash and anjuta use so old libraries ? More, I readed here that gtkbuilder is better that libglade ? True ? source: http://www.micahcarrick.com/01-01-2008/gtk-glade-tutorial-part-3.html#more-53 I saw in the gnucash source that gnucash uses very few the header named gnome.h For now, my problem is: how to automate this : have the good libraries loaded at gnucash (and anjuta and others) startup! Thanks. signature.asc Description: Ceci est une partie de message numériquement signée ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gnucash compilation and installation from svn: why a gnome druid
and compiled I removed it and installed the 2.2.4 version ubuntu from synaptic: the same problems! These menus doe not work in the French version: Actions/Transactions_récurrentes/Remboursement_hypothèque/emprunt Fichier/Nouveau/Nouvelle_hiérarchie_de_comptes Fichier/Importer/Importer_QIF This is the approximative English translation and the problems: Actions/Scheduled_transactions/mortgage : Empty window, the buttons does not run File/New/New_account_hierarchy : In the druid, it is virgen, and the buttons for prev next do not run File/Import/Import_QIF: Only the cancel button runs! Thanks Le lundi 29 décembre 2008 à 17:17 +0100, Andeas Köhler a écrit : Hi Raphaël, you also did not say what operating system or distribution you use. I suppose that you have an incomplete installation of libgnome2, you need one with glade support. Do you see the file /usr/lib/libglade/2.0/libgnome.so? What is printed to the terminal when you run gnucash from there? Ciao, -- andi5 Raphaël Maville schrieb: I installed: GnuCash 2.2.7 Compilé le 2008-11-02 depuis r17597M The assistant windows appear empty with this text: [a gnome druid] But gnucash runs well. How to get the assistant ? ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gnucash compilation and installation from svn: why a gnome druid
and the problems: Actions/Scheduled_transactions/mortgage: Empty window, the buttons does not run File/New/New_account_hierarchy: In the druid, it is virgen, and the buttons for prev next do not run File/Import/Import_QIF : Only the cancel button runs! Thanks Le lundi 29 décembre 2008 à 17:17 +0100, Andeas Köhler a écrit : Hi Raphaël, you also did not say what operating system or distribution you use. I suppose that you have an incomplete installation of libgnome2, you need one with glade support. Do you see the file /usr/lib/libglade/2.0/libgnome.so? What is printed to the terminal when you run gnucash from there? Ciao, -- andi5 Raphaël Maville schrieb: I installed: GnuCash 2.2.7 Compilé le 2008-11-02 depuis r17597M The assistant windows appear empty with this text: [a gnome druid] But gnucash runs well. How to get the assistant ? ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel signature.asc Description: Ceci est une partie de message numériquement signée ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gnucash compilation and installation from svn: why a gnome druid
I said that not all the druid windows did not functions, but only some: the prouf: I use gnucash since two or three month; and a regret: it was still like that at the beginning: but I could use it, so... I use Linux 2.6.24-22-generic I686 GNU/Linux and Ubuntu Hardy Heron 8.04 /usr/lib/libglade/2.0/libgnome.so is on it, and I installed with synaptic all the libgnome ligglade libraries I could find: it is the same! Yesterday I removed the gnucash 2.2.7 I downloaded and compiled, and reinstalled the 2.2.4 for ubuntu, and it is the same. Here are the druid and secondary windows not running (via the menu): 1. File New New account hierarchy : the druid appears with the three bottom buttons: cancel, back, forward; only the cancel button runs, and does its job: close the druid. 2. File Import Qif Import : idem! 3. Actions Scheduled transactions Mortage and Loan druid : idem! The others druid and sub-windows seem to run well. I did not report this to bugzilla: should I? Thanks. PS: Well, I thought I had answered to this e-mail, but by night my ADSL connection is not great (dynamic disconnect-reconnect from the adsl operator, sometimes every 5 minutes), and I sent and then delete an answer yet! And all was on it... and lost! Le jeudi 01 janvier 2009 à 14:47 +0100, Andreas Köhler a écrit : Hi Raphaël, I am not sure whether you sent me a mail already, but there is none in the mailing list archives, so we still need the answer :-) Instead of libgnome I meant libgnomeui-0, which is the name of the Ubuntu package. Try running both of the following commands and check whether the package contains /usr/lib/libglade/2.0/libgnome.so. dpkg -L libgnomeui-0 | grep libglade ls -l /usr/lib/libglade/2.0/libgnome.so Once again, what is printed to the terminal when you run gnucash from there? What happens when you run it in English, e.g. via LANG= gnucash from the terminal? Anything about GnuCash in ~/.xsession-errors? Ciao, -- andi5 Raphaël Maville schrieb: Hi! First I mistake: not all the menus do not work: only some! I run gnucash under: Linux 2.6.24-22-generic i686 GNU/Linux Ubuntu 8.04 - Hardy Heron - sortie en avril 2008. libgnome is installed yet. I used the 2.2.7 version downloaded from gnucash svn and compiled I removed it and installed the 2.2.4 version ubuntu from synaptic: the same problems! These menus doe not work in the French version: Actions/Transactions_récurrentes/Remboursement_hypothèque/emprunt Fichier/Nouveau/Nouvelle_hiérarchie_de_comptes Fichier/Importer/Importer_QIF This is the approximative English translation and the problems: Actions/Scheduled_transactions/mortgage : Empty window, the buttons does not run File/New/New_account_hierarchy : In the druid, it is virgen, and the buttons for prev next do not run File/Import/Import_QIF : Only the cancel button runs! Thanks Le lundi 29 décembre 2008 à 17:17 +0100, Andeas Köhler a écrit : Hi Raphaël, you also did not say what operating system or distribution you use. I suppose that you have an incomplete installation of libgnome2, you need one with glade support. Do you see the file /usr/lib/libglade/2.0/libgnome.so? What is printed to the terminal when you run gnucash from there? Ciao, -- andi5 Raphaël Maville schrieb: I installed: GnuCash 2.2.7 Compilé le 2008-11-02 depuis r17597M The assistant windows appear empty with this text: [a gnome druid] But gnucash runs well. How to get the assistant ? ___ gnucash-user mailing list gnucash-u...@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-user - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. --- Orange vous informe que cet e-mail a ete controle par l'anti-virus mail. Aucun virus connu a ce jour par nos services n'a ete detecte. signature.asc Description: Ceci est une partie de message numériquement signée ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gnucash compilation and installation from svn: why a gnome druid
Hi Raphaël, I would prefer if you answered my questions first. Thanks. Ciao, -- andi5 Raphaël Maville schrieb: I said that not all the druid windows did not functions, but only some: the prouf: I use gnucash since two or three month; and a regret: it was still like that at the beginning: but I could use it, so... I use Linux 2.6.24-22-generic I686 GNU/Linux and Ubuntu Hardy Heron 8.04 /usr/lib/libglade/2.0/libgnome.so is on it, and I installed with synaptic all the libgnome ligglade libraries I could find: it is the same! Yesterday I removed the gnucash 2.2.7 I downloaded and compiled, and reinstalled the 2.2.4 for ubuntu, and it is the same. Here are the druid and secondary windows not running (via the menu): 1. File New New account hierarchy : the druid appears with the three bottom buttons: cancel, back, forward; only the cancel button runs, and does its job: close the druid. 2. File Import Qif Import : idem! 3. Actions Scheduled transactions Mortage and Loan druid : idem! The others druid and sub-windows seem to run well. I did not report this to bugzilla: should I? Thanks. PS: Well, I thought I had answered to this e-mail, but by night my ADSL connection is not great (dynamic disconnect-reconnect from the adsl operator, sometimes every 5 minutes), and I sent and then delete an answer yet! And all was on it... and lost! Le jeudi 01 janvier 2009 à 14:47 +0100, Andreas Köhler a écrit : Hi Raphaël, I am not sure whether you sent me a mail already, but there is none in the mailing list archives, so we still need the answer :-) Instead of libgnome I meant libgnomeui-0, which is the name of the Ubuntu package. Try running both of the following commands and check whether the package contains /usr/lib/libglade/2.0/libgnome.so. dpkg -L libgnomeui-0 | grep libglade ls -l /usr/lib/libglade/2.0/libgnome.so Once again, what is printed to the terminal when you run gnucash from there? What happens when you run it in English, e.g. via LANG= gnucash from the terminal? Anything about GnuCash in ~/.xsession-errors? Ciao, -- andi5 Raphaël Maville schrieb: Hi! First I mistake: not all the menus do not work: only some! I run gnucash under: Linux 2.6.24-22-generic i686 GNU/Linux Ubuntu 8.04 - Hardy Heron - sortie en avril 2008. libgnome is installed yet. I used the 2.2.7 version downloaded from gnucash svn and compiled I removed it and installed the 2.2.4 version ubuntu from synaptic: the same problems! These menus doe not work in the French version: Actions/Transactions_récurrentes/Remboursement_hypothèque/emprunt Fichier/Nouveau/Nouvelle_hiérarchie_de_comptes Fichier/Importer/Importer_QIF This is the approximative English translation and the problems: Actions/Scheduled_transactions/mortgage : Empty window, the buttons does not run File/New/New_account_hierarchy : In the druid, it is virgen, and the buttons for prev next do not run File/Import/Import_QIF : Only the cancel button runs! Thanks Le lundi 29 décembre 2008 à 17:17 +0100, Andeas Köhler a écrit : Hi Raphaël, you also did not say what operating system or distribution you use. I suppose that you have an incomplete installation of libgnome2, you need one with glade support. Do you see the file /usr/lib/libglade/2.0/libgnome.so? What is printed to the terminal when you run gnucash from there? Ciao, -- andi5 Raphaël Maville schrieb: I installed: GnuCash 2.2.7 Compilé le 2008-11-02 depuis r17597M The assistant windows appear empty with this text: [a gnome druid] But gnucash runs well. How to get the assistant ? ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gnucash compilation and installation from svn: why a gnome druid
Hi Raphaël, I am not sure whether you sent me a mail already, but there is none in the mailing list archives, so we still need the answer :-) Instead of libgnome I meant libgnomeui-0, which is the name of the Ubuntu package. Try running both of the following commands and check whether the package contains /usr/lib/libglade/2.0/libgnome.so. dpkg -L libgnomeui-0 | grep libglade ls -l /usr/lib/libglade/2.0/libgnome.so Once again, what is printed to the terminal when you run gnucash from there? What happens when you run it in English, e.g. via LANG= gnucash from the terminal? Anything about GnuCash in ~/.xsession-errors? Ciao, -- andi5 Raphaël Maville schrieb: Hi! First I mistake: not all the menus do not work: only some! I run gnucash under: Linux 2.6.24-22-generic i686 GNU/Linux Ubuntu 8.04 - Hardy Heron - sortie en avril 2008. libgnome is installed yet. I used the 2.2.7 version downloaded from gnucash svn and compiled I removed it and installed the 2.2.4 version ubuntu from synaptic: the same problems! These menus doe not work in the French version: Actions/Transactions_récurrentes/Remboursement_hypothèque/emprunt Fichier/Nouveau/Nouvelle_hiérarchie_de_comptes Fichier/Importer/Importer_QIF This is the approximative English translation and the problems: Actions/Scheduled_transactions/mortgage : Empty window, the buttons does not run File/New/New_account_hierarchy : In the druid, it is virgen, and the buttons for prev next do not run File/Import/Import_QIF: Only the cancel button runs! Thanks Le lundi 29 décembre 2008 à 17:17 +0100, Andeas Köhler a écrit : Hi Raphaël, you also did not say what operating system or distribution you use. I suppose that you have an incomplete installation of libgnome2, you need one with glade support. Do you see the file /usr/lib/libglade/2.0/libgnome.so? What is printed to the terminal when you run gnucash from there? Ciao, -- andi5 Raphaël Maville schrieb: I installed: GnuCash 2.2.7 Compilé le 2008-11-02 depuis r17597M The assistant windows appear empty with this text: [a gnome druid] But gnucash runs well. How to get the assistant ? ___ gnucash-user mailing list gnucash-u...@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-user - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gnucash compilation and installation from svn: why a gnome druid
Hi! First I mistake: not all the menus do not work: only some! I run gnucash under: Linux 2.6.24-22-generic i686 GNU/Linux Ubuntu 8.04 - Hardy Heron - sortie en avril 2008. libgnome is installed yet. I used the 2.2.7 version downloaded from gnucash svn and compiled I removed it and installed the 2.2.4 version ubuntu from synaptic: the same problems! These menus doe not work in the French version: Actions/Transactions_récurrentes/Remboursement_hypothèque/emprunt Fichier/Nouveau/Nouvelle_hiérarchie_de_comptes Fichier/Importer/Importer_QIF This is the approximative English translation and the problems: Actions/Scheduled_transactions/mortgage : Empty window, the buttons does not run File/New/New_account_hierarchy : In the druid, it is virgen, and the buttons for prev next do not run File/Import/Import_QIF : Only the cancel button runs! Thanks Le lundi 29 décembre 2008 à 17:17 +0100, Andeas Köhler a écrit : Hi Raphaël, you also did not say what operating system or distribution you use. I suppose that you have an incomplete installation of libgnome2, you need one with glade support. Do you see the file /usr/lib/libglade/2.0/libgnome.so? What is printed to the terminal when you run gnucash from there? Ciao, -- andi5 Raphaël Maville schrieb: I installed: GnuCash 2.2.7 Compilé le 2008-11-02 depuis r17597M The assistant windows appear empty with this text: [a gnome druid] But gnucash runs well. How to get the assistant ? ___ gnucash-user mailing list gnucash-u...@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-user - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. signature.asc Description: Ceci est une partie de message numériquement signée ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Source code installation - Windows Vista
Hi I am trying to install the source under vista. When running install.sh I get this error Extracting aqbanking-2.3.3.tar.gz ... done /c/soft/downloads/install.sh: lib*.la: No such file or directory Any idea what is causing this? I have installed QT manually under c/QT/4.4.3 then I changed the aqbanking variable to yes in the default.sh and added a custom.sh file with the line QTDIR=/c/Qt/4.4.3 I still get the error above and cant seem to make it to work Thanks Youssef ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r17672 - gnucash/trunk/src/business/business-reports - Remove duplicate report installation
Quoting Derek Atkins [EMAIL PROTECTED]: New Revision: 17672 Trac: http://svn.gnucash.org/trac/changeset/17672 Modified: gnucash/trunk/src/business/business-reports/Makefile.am Log: Remove duplicate report installation Reorder reports alphabetically for easy listing Out of curiosity: Which one was the duplicate report installation? In the changeset I only see the alphabetic reordering... :-) Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r17672 - gnucash/trunk/src/business/business-reports - Remove duplicate report installation
Quoting Christian Stimming [EMAIL PROTECTED]: Quoting Derek Atkins [EMAIL PROTECTED]: New Revision: 17672 Trac: http://svn.gnucash.org/trac/changeset/17672 Modified: gnucash/trunk/src/business/business-reports/Makefile.am Log: Remove duplicate report installation Reorder reports alphabetically for easy listing Out of curiosity: Which one was the duplicate report installation? In the changeset I only see the alphabetic reordering... :-) Well, when I did M-x sort-lines it looked like there were two copies of a few reports. Maybe my local merge was broken. Christian -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Installation Finanzsoftware
Hallo, möchte die GnuCash Vers. 2.2.4 auf meinem Rechner unter Ubuntu Vers. 7.10 installieren. Unter http://www.gnucash.org/de/docs.phtml habe ich unter das Programm unter Nur Quelltext (Europa): Herunterladen Quelltext und Windows-Paket Nur Quelltext (USA) Nur Quelltext (Europa) gnucash-2.2.4.tar.bz2 heruntergeladen und in meinem persönlichen Progammverzeichnis downloads .../GnuCash abgespeichert. Was muss ich tun, um die Software - wenn möglich - unter Anwendungen - Büro zum Laufen zu bringen? -- Mit freundlichen Grüßen Volker Fritz Ludwig-Festl-Str. 3 D-85604 Zorneding ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Installation Finanzsoftware
Hi, Gnucash-devel is an English list. If you want to ask in German you should use the gnucash-de list. Quoting Volker Fritz [EMAIL PROTECTED]: Hallo, möchte die GnuCash Vers. 2.2.4 auf meinem Rechner unter Ubuntu Vers. 7.10 installieren. I do not believe that Ubuntu has 2.2.4, but you can build it yourself. Unter http://www.gnucash.org/de/docs.phtml habe ich unter das Programm unter Nur Quelltext (Europa): Herunterladen Quelltext und Windows-Paket Nur Quelltext (USA) Nur Quelltext (Europa) gnucash-2.2.4.tar.bz2 heruntergeladen und in meinem persönlichen Progammverzeichnis downloads .../GnuCash abgespeichert. Was muss ich tun, um die Software - wenn möglich - unter Anwendungen - Büro zum Laufen zu bringen? This would be the gnucash source tree. You should: apt-get build-dep gnucash This will pull down and install all the build dependencies to build gnucash. Then you should be able to untar the source tree and build gnucash. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
installation
I can't figure out how to install this program. I downloaded it and found it was some achieved/zipped files and got them unzipped but can't seem to locate an install file. Any information would be greatly appreciated. Anna Jeanette Ash ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: installation
(This really belongs on gnucash-user, so I've CC'ed it there instead.) Anna Ash [EMAIL PROTECTED] writes: I can't figure out how to install this program. I downloaded it and found it was some achieved/zipped files and got them unzipped but can't seem to locate an install file. Any information would be greatly appreciated. I'm assuming you're referring to GnuCash-2.2.0. If you're on Windows, you'll want to download and run the executable at http://downloads.sourceforge.net/gnucash/gnucash-2.2.0-setup.exe. If you're on unix, you'll want to wait until your distribution/vendor offers a pre-built package of Gnucash 2.2, and install it using your distribution's package manager. I'm not sure what you downloaded, since you didn't identify it at all, but if it's the sources, then it should have an INSTALL at the top. If you have the sources, it's possible to compile the software yourself (on either unix or Windows) ... more information on that can be found at http://wiki.gnucash.org/wiki/Building. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpBFwfzQBENM.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: installation
Anna Ash wrote: I can't figure out how to install this program. I downloaded it and found it was some achieved/zipped files and got them unzipped but can't seem to locate an install file. Any information would be greatly appreciated. Anna Jeanette Ash Anna, I would bet you downloaded source files. Installing from source, though possible, is not for fainthearted. The file you need (you are running Windows, right?) is gnucash-2.2.0-setup.exe. http://downloads.sourceforge.net/gnucash/gnucash-2.2.0-setup.exe?modtime=1184428279big_mirror=1 Download to desktop, doubleclick, next, next. Done Wahur ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r15241 - gnucash/trunk/packaging/win32 - Add code for download/installation of Inno Setup Compiler, as suggested by hfelton.
Am Donnerstag, 21. Dezember 2006 19:18 schrieb Andreas Köhler:
Add code for download/installation of Inno Setup Compiler, as suggested
by hfelton.
Modified: gnucash/trunk/packaging/win32/dist.sh
===
--- gnucash/trunk/packaging/win32/dist.sh 2006-12-21 13:53:03 UTC (rev
15240)
+++ gnucash/trunk/packaging/win32/dist.sh 2006-12-21 14:10:41 UTC (rev
15241)
@@ -141,6 +141,10 @@
--install-schema-file $file /dev/null
echo done
done
+
+_INNO_UDIR=`unix_path $INNO_DIR`
+echo You can now run the Inno Setup Compiler for creating the
setup.exe:
+echo ${_INNO_UDIR}/iscc ${_GNUCASH_UDIR}/packaging/win32/gnucash.iss
}
prepare
Is there any reason not to call iscc directly?
No particular reason, except that 1. I'm not totally sure everyone who is
trying this has ISCC already installed, and 2. I'm hesistant to introduce
things that change the script in a rather unexpected change. Also, this takes
quite a lot of time: 2 minutes of ISCC, whereas dist.sh takes 30 seconds.
Now that it has been in SVN for a while, feel free to change this so that ISCC
is called directly.
Christian
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r15241 - gnucash/trunk/packaging/win32 - Add code for download/installation of Inno Setup Compiler, as suggested by hfelton.
Hi,
Author: cstim
Date: 2006-12-21 09:10:41 -0500 (Thu, 21 Dec 2006)
New Revision: 15241
Trac: http://svn.gnucash.org/trac/changeset/15241
Add code for download/installation of Inno Setup Compiler, as suggested by
hfelton.
Modified: gnucash/trunk/packaging/win32/dist.sh
===
--- gnucash/trunk/packaging/win32/dist.sh 2006-12-21 13:53:03 UTC (rev
15240)
+++ gnucash/trunk/packaging/win32/dist.sh 2006-12-21 14:10:41 UTC (rev
15241)
@@ -141,6 +141,10 @@
--install-schema-file $file /dev/null
echo done
done
+
+_INNO_UDIR=`unix_path $INNO_DIR`
+echo You can now run the Inno Setup Compiler for creating the
setup.exe:
+echo ${_INNO_UDIR}/iscc ${_GNUCASH_UDIR}/packaging/win32/gnucash.iss
}
prepare
Is there any reason not to call iscc directly?
-- andi5
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
gconf schema installation, $DESTDIR
David, I'm a bit unclear on how this should work, but I'm hoping we can find a solution before 1.9.2. With respect to the schema installation done in the Makefiles, it seems like we should make the gconftool-2 calls conditional on GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL, and insteadd call them in the package-management's post hook. Or does gconftool-2 check for the value of GCONF_DISABLE[...]? Also, we should make the mkdir calls prefix'ed with DESTDIR, as in: -mkdir -p $(DESTDIR)$(GCONF_SCHEMA_CONFIG_SOURCE_DIRONLY) Also, what's the policy for uninstalling schema? Is just removing the schema file enough? I don't see any --makefile-uninstall-rule in gconftool-2. -- ...jsled http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gconf schema installation, $DESTDIR
On Sat, 2006-03-04 at 08:16 -0500, Josh Sled wrote: David, I'm a bit unclear on how this should work, but I'm hoping we can find a solution before 1.9.2. With respect to the schema installation done in the Makefiles, it seems like we should make the gconftool-2 calls conditional on GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL, and insteadd call them in the package-management's post hook. Or does gconftool-2 check for the value of GCONF_DISABLE[...]? Apparently gconftool-2 does check. The install step when building an rpm does: export GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL=1 (fancy make install command here) unset GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL This results in only the schema files being installed, without the default key/value pairs also being created. Also, we should make the mkdir calls prefix'ed with DESTDIR, as in: -mkdir -p $(DESTDIR)$(GCONF_SCHEMA_CONFIG_SOURCE_DIRONLY) Sounds reasonable. Also, what's the policy for uninstalling schema? Is just removing the schema file enough? I don't see any --makefile-uninstall-rule in gconftool-2. You should remove both the schema and the default keys/value pairs installed by the makefile-install-rule. The makefile-uninstall-rule does exist and does this. David ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: installation paths, option definition
On Friday 02 September 2005 5:54 pm, Neil Williams wrote: On Friday 02 September 2005 5:29 pm, Derek Atkins wrote: No, but it's not recommended. OK, it's changed. It's still used for some internal roles (although that may change). No, I'm not convinced that passing configuration in a header file is necessarily the right method. The location of the library and the location of the backend config XML file is now part of the pkg-config and can be retrieved with: (example only) MY_LIB_DIR=`$PKG_CONFIG --variable=libdir package` MY_XML_DIR=`$PKG_CONFIG --variable=xmldir package` The name of the library and the name of the init function are expected to be hard-coded into whichever applications need to use them. 2. You propose to separate the configuration option definition from its documentation. I looked at putting this in the XML but it just isn't worth the effort. I think Christian's point is that you put the english text in the XML file then load the translations elsewhere. I still can't see how this can work. gettext AFAICT won't load the translations that way. All I can see to do is have duplicate strings in the C and XML - I'd rather not do that. If gettext needs the english text in a C file, there seems little point duplicating it in XML. Besides, the english text in the XML would never be read - all the documentation would come from the C file anyway. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpLQ2fEzRv2G.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: installation paths, option definition
Dear Neil, Am Samstag, 3. September 2005 13:44 schrieb Neil Williams: 1. You propose to pass installations paths by a header file. OK, it's changed. It's still used for some internal roles (although that may change). [...] The location of the library and the location of the backend config XML file is now part of the pkg-config and can be retrieved with: (example only) MY_LIB_DIR=`$PKG_CONFIG --variable=libdir package` MY_XML_DIR=`$PKG_CONFIG --variable=xmldir package` The name of the library and the name of the init function are expected to be hard-coded into whichever applications need to use them. Ok, that's much more standard-like. Thanks for that. Simple rule of thumb: If it's an installation directory that needs to be passed from one library to another, then pkg-config is the best way to do this currently. One simple reason is this: An application might want to use that directory in other places than C source code. If you pass it by a C header file, you enforce that it can be used by a C source file only. Whereas if you pass it by pkg-config, then ./configure of the application knows it and can use it whereever the application want to -- e.g. by config.h into C source code, or right in the Makefiles, or by a similar config.h-mechanism in other programming languages. Anyway, thanks for adapting that. 2. You propose to separate the configuration option definition from its documentation. I think Christian's point is that you put the english text in the XML file then load the translations elsewhere. I still can't see how this can work. gettext AFAICT won't load the translations that way. All I can see to do is have duplicate strings in the C and XML - I'd rather not do that. No, surely not -- I don't want anyone to create duplicated strings. Derek was right: I would prefer if the english text of the description and tooltip is in the XML file, just as the name and type of that option. ... Wait a second. When reading your original description again https://lists.gnucash.org/pipermail/gnucash-devel/2005-September/013608.html you hopefully don't mean that an option already is *defined twice*? From your souce code example I saw that you define an option by writing those lines into your XML file: option type=gint64 name=file_retention_days / but then in your function gnc_file_be_get_config(QofBackend *be) you create the KVP frame which represents the option by adding kvp_values one-by-one. The names are chosen by your #defines, i.e. they are string constants in the C file, and the types are chosen by the respective kvp_frame_set_xy functions. In other words, the creation of your kvp_frame has to manually duplicate the things that are written in the XML file. Did I understand this correctly? That is, errr, probably not so good. Can you please elaborate how you intend to avoid inconsistencies between the XML file and the C source? If gettext needs the english text in a C file, there seems little point duplicating it in XML. As for the gettext/translation question: Eventually, translating a string by gettext only means that you pass *one* const char* into the gettext() function and you get *another one* const char* returned. That's all you need to know. Sorry, I don't have more time now, but I can code up an example how that would look like later. Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: automake and ./configure (was: installation paths, option definition)
Just to finish that other automake/configure discussion:
Am Freitag, 2. September 2005 18:19 schrieb Neil Williams:
(And just one nitpicking remark: The auto-generation of a header from a
header.in file is done by ./configure, not by automake -- automake
basically only creates a Makefile.in from a Makefile.am, but the
processing of the *.in files is always done by ./configure.)
Not in this case, nor in lots of cases within GnuCash. We use a Guile
convention in lots of areas that does no substitution during configure,
only in the Makefile.am using a customised sed routine.
qsf-dir.h: qsf-dir.h.in
rm -f [EMAIL PROTECTED]
sed $ [EMAIL PROTECTED] \
-e 's:@-QSF_SCHEMA_DIR-@:${QSF_SCHEMA_DIR}:g'
mv [EMAIL PROTECTED] $@
That has been in place for schema validation for some months and also
passes an installation path by a header file. No problems with that one.
It's actually more flexible because the output can be updated without a
complete ./autogen.sh.
Ahh, okay, didn't know that. However, it is still not automake that will
generate the file qsf-dir.h. Instead, you now added a manual creation rule
to the Makefile.am which will appear unchanged in the Makefile. This creation
rule will then be executed when you run make. So what happens here is that
make will create the qsf-dir.h according to this manuale creation rule
which is defined in the Makefile.am. It is not automake that creates your
header but make.
You can reach exactly the same effect but without the manual creation rule if
you do the following steps:
1. Make sure all your desired substitution variables (e.g. QSF_SCHEMA_DIR) are
listed in the configure.in file as AC_SUBST [e.g. AC_SUBST(QSF_SCHEMA_DIR) ]
2. In your file qsf-dir.h.in, list these variables with surrounding @...@ but
not @-...-@ (e.g. #define blabla @QSF_SCHEMA_DIR@)
3. Add the input file in your configure.in file to the long list in AC_OUTPUT
(e.g. src/bla/bla/qsf-dir.h.in)
4. Add the resulting *output* file in that directory's Makefile.am to any
variable that ensures that this file is distributed, e.g.
noinst_HEADERS=qsf-dir.h and probably also BUILT_SOURCES=qsf-dir.h
This way, you gain the following: 1. You don't need to add the multi-line
manual creation rule to the Makefile.am anymore, and 2. ./configure will make
sure that you have all AC_SUBST variables available. And 3. the rule won't
fail if sed happens to be called in some weird unusual way which we don't
know but ./configure on that platform will know.
I don't quite understand why the manual rule was added in the first place.
Maybe there was a reason, maybe not. In any case such installation paths
change if and only if ./configure has been run, so having the resulting path
created only by ./configure is just the exact right thing to do. The file
gnucash.keys is surely one that can direcly be added to configure.in. And
unless you have a very specific reason to go for a manual rule, you should
simply add those files as AC_OUTPUT to configure.in.
Christian
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: qof/qsf/gnucash backend clarification (was: installation paths, option definition)
Am Freitag, 2. September 2005 18:19 schrieb Neil Williams: Err... can you draw a picture which part depends on which part here, and where Gnucash GUI, GNC backend, QSF, and QOF all fit into that picture? The outline picture is here: http://www.data-freedom.org/explain.html#example The only difference is that Programs A and B actually use the same backend (which makes it kinda hard to draw). A1 == B1 because objects A == objects B. However, ProgramA != ProgramB. PilotQOF calls libqof which provides QSF as no other backend is defined. Gnucash GUI calls the gnc file backend and adds the QSF backend. Much as it has always done. CashUtil does the same. Okay so far. I'd just like to ask you for some name clarification here: What you call gnucash backend used to be called gnucash XML file module, right? Then please give it a name that makes this clear, because the gnucash code from src/engine (called gnucash engine) is also totally GUI-independent but from what I understand is not part of what you call gnucash backend. When gnucash uses libqof as object framework then there is still a lot of non-GUI modules in the remaining gnucash application. You should therefore be quite careful about what you call what. In particular, which part depends on which one *at compile time*? That is not a problem, but just a bit confusion on my side. GnuCash depends on QSF via a dependency on QOF. It also depends on libcashobjects.la and libgnc-backend-file.la via the new shared package. *Cough* A dependency on libxyz.la by definition is a dependency at runtime, not at compile time. I asked particularly about the dependency at compile time, more precisely: Which package's headers have to be available when compiling the other package? That is the interesting part for the compile time dependency. From what I gathered: The gnucash-file-backend-of-libqof depends on libqof headers; the gnucash-application-with-gui-and-other-stuff depends on libqof headers. Is this correct? Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: automake and ./configure (was: installation paths, option definition)
Am Samstag, 3. September 2005 23:02 schrieb Neil Williams: On Saturday 03 September 2005 9:39 pm, you wrote: Just to finish that other automake/configure discussion: True. The one advantage is that it builds under a make - it does not require another ./autogen.sh - it can be a significant advantage during development of the associated files because you then only make that specific file. autogen takes FAR longer. Not true. Don't you use --enable-maintainer-mode? If you don't, you should. It will make these generations happen exactly when you expect them, and not only when running ./autogen. By the way, running ./configure is just as fine, as long as you don't changed any directories. 4. Add the resulting *output* file in that directory's Makefile.am to any variable that ensures that this file is distributed, e.g. noinst_HEADERS=qsf-dir.h and probably also BUILT_SOURCES=qsf-dir.h You lose the ability to re-create the file with 'make'. No. --enable-maintainer-mode will do exactly that. I don't quite understand why the manual rule was added in the first place. Because it's powerful during development - FAR more useful than putting it AC_OUTPUT. No. The other way round. Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: qof/qsf/gnucash backend clarification (was: installation paths, option definition)
On Saturday 03 September 2005 10:00 pm, Christian Stimming wrote: Gnucash GUI calls the gnc file backend and adds the QSF backend. Much as it has always done. CashUtil does the same. Okay so far. I'd just like to ask you for some name clarification here: What you call gnucash backend used to be called gnucash XML file module, right? Almost. GnuCash File Backend v2, v1 and binary. src/backend/file with src/business/business-core/file included. In effect, it is the gnucash file backend *as it is at runtime* once the business module is loaded. I'm transferring the linkage to build time instead of runtime - then putting all that code in a library that can be loaded as one (at runtime) using a different load method! Then please give it a name that makes this clear, libgnc-backend-file.la - it's actually more accurate than it looks because it includes ALL the file backend code (i.e. not just XML) from the current GnuCash tree AND it includes ALL the handlers for that backend - binary and XML. because the gnucash code from src/engine (called gnucash engine) is also totally GUI-independent but from what I understand is not part of what you call gnucash backend. True. src/engine confuses things because that directory holds at least TWO distinct kinds of files: QOF files and object files. Both sets of files are GUI-independent but serve quite different functions. Object files also exist elsewhere - namely in business-core. These are also GUI-independent. So I talk of libcashobjects.la and libgnc-backend-file.la. If you get a chance to download CashUtil the distinctions might be clearer. cashutil/src/objects contains objects from /src/engine and business-core cashutil/src/backend contains files from backend/file and business-core/file. When gnucash uses libqof as object framework then there is still a lot of non-GUI modules in the remaining gnucash application. When libcashobjects.la and libgnc-backend-file.la are in their own package the amount of non-GUI code is much reduced. AFAICT, it may be just import/export, and Budgets. More will inevitably follow as logic currently implemented in the GUI must eventually be abstracted into a form that can be shared with CashUtil. e.g. when creating an account and the dialog insists on a parent etc. You should therefore be quite careful about what you call what. I'll try to add the file backend listings to the rest of the tables here: http://www.linux.codehelp.co.uk/cashutil/gnucash.html All files listed in the cashutil/src/objects table (on the right) are part of libcashobjects.la Their equivalent files from backend/file and business-core/file plus the Sixtp, binary handlers and associated files - these form libgnc-backend-file.la As time goes on and more ancillary logic is removed from the GUI and into the package shared with CashUtil, I'll endeavour to keep the listing updated. Which package's headers have to be available when compiling the other package? That is the interesting part for the compile time dependency. The other package - consisting of libcashobjects.la and libgnc-backend-file.la depends on libqof1, libglib-2.0, libxml2. Then I build the cashutil program on top of those and soon the GnuCash GUI too. CashUtil depends on the 'package' containing libcashobjects.la and libgnc-backend-file.la - that brings in libqof1, libxml2 and libglib-2.0. It also uses readline, popt and gettext. PilotQOF will only depend on libqof1, readline, popt and gettext. GnuCash GUI will depend on the package created from libcashobjects.la and libgnc-backend-file.la as well as libqof1. From what I gathered: The gnucash-file-backend-of-libqof The file backend is not for QOF, it's for CashUtil. QOF is remaining strictly non-financial. It really doesn't know the difference between an Account and a watermelon to revisit an older thread! :-) depends on libqof headers; the gnucash-application-with-gui-and-other-stuff depends on libqof headers. Is this correct? Yes, albeit incomplete. OK, at compile time: libgnc-backend-file.la requires libqof1 (for the foreach etc.), glib and libxml2. It also depends on libcashobjects.la (which is why the two must go into a package together). libcashobjects.la (the objects from engine and business-core) depends on libqof1 and glib. libqof1 itself only depends on libxml2 (= 2.5.10) and libglib-2.0 and includes QSF. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpVCpAnHOlmj.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: automake and ./configure (was: installation paths, option definition)
On Saturday 03 September 2005 10:42 pm, Christian Stimming wrote: True. The one advantage is that it builds under a make - it does not require another ./autogen.sh - it can be a significant advantage during development of the associated files because you then only make that specific file. autogen takes FAR longer. Not true. Don't you use --enable-maintainer-mode? Yes, autogen.sh enables it every time. 4. Add the resulting *output* file in that directory's Makefile.am to any variable that ensures that this file is distributed, e.g. noinst_HEADERS=qsf-dir.h and probably also BUILT_SOURCES=qsf-dir.h You lose the ability to re-create the file with 'make'. No. --enable-maintainer-mode will do exactly that. Hmm. Anyway, it's changed now. I don't quite understand why the manual rule was added in the first place. Because it's powerful during development - FAR more useful than putting it AC_OUTPUT. No. The other way round. That's not how it's seemed in the past - ne'er mind. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpv7652EKhFA.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: installation paths, option definition (was: QofBackend changes in next commit)
Errr... sorry, Neil, but you're proposing some quite substantial changes here, and maybe it's only me, but some of these changes make me feel a bit uneasy. In particular, two parts of your proposed multi-part changes seem to me a bit problematic. And as they IMHO might be quite hard to change once they have been introduced, I would rather ask whether you can defer these two parts of your proposed commit to some later time and spent a bit more time on discussing these. In particular: 1. You propose to pass installations paths by a header file. 2. You propose to separate the configuration option definition from its documentation. (And just one nitpicking remark: The auto-generation of a header from a header.in file is done by ./configure, not by automake -- automake basically only creates a Makefile.in from a Makefile.am, but the processing of the *.in files is always done by ./configure.) As for #1, that was: Neil Williams wrote: On my system, this header defines (for cashutil): #define GNC_LIB_DIR /opt/garfield/cashutil/lib #define GNC_XML_DIR /opt/garfield/cashutil/share/xml/cashutil #define GNC_LIB_NAME libgnc-backend-file.la #define GNC_LIB_INIT gnc_provider_init Passing installation paths from one library/application to another by this method is actually not-so-common or rather unorthodox. The usual way of passing such installation paths currently is by pkg-config, where the library will define variables with the paths in its *.pc file. The application which wants to access these paths will have some code in its configure.in script which will retrieve these paths via pkg-config at ./configure time. That code in turn will define C constants which are either put into the config.h of the application or will directly be used by passing -D arguments to gcc, but that is totally up to the application. I must admit that I can't tell the exact reason right now *why* these paths should better be passed via pkg-config and ./configure (maybe Derek knows better). But that is pretty much the standard way of passing such things, whereas defining them as C constants in a header file is quite non-standard. I would rather prefer to stick with the standard way and try to avoid to invent a non-standard way of passing such arguments. GnuCash will need to know where the GNC backend is installed (as it will be shared with cashutil) and will also pick up the location of QSF via #include qof.h. So GnuCash uses two such header files, gncla-dir.h (which automake generates from src/backend/gncla-dir.h.in) and qofla-dir.h (from qof.h). In principle that is fine. I'm just a bit confused: GnuCash needs a GNC backend? Err... can you draw a picture which part depends on which part here, and where Gnucash GUI, GNC backend, QSF, and QOF all fit into that picture? In particular, which part depends on which one *at compile time*? That is not a problem, but just a bit confusion on my side. As for #2: The configuration options can be modified without recompiling code for a generic option dialog because once you have the location of the XML file it can be loaded and used to parse the KvpFrame. ?xml version=1.0 encoding=UTF-8? qofconfig xmlns=http://qof.sourceforge.net/; backend name=GnuCash Backend Version 2 option type=gint64 name=file_retention_days / option type=boolean name=file_compression / /backend /qofconfig This proposal means that the definition of an option will be separated from its documentation. I think this should rather be avoided. It seems to me that the translation question (which is totally orthogonal to the definition and documentation place) distracted you here from a clean design. I would strongly suggest that *if* you want to define the options inside the XML file, *then* you should include the description and tooltip right in that XML definition as well. Otherwise either one gets forgotten or confused with something else or whatnot. In your current proposal you would split the definition of one option into several locations. IMHO this is simply not necessary. You gain much more code clarity if the definition is contained in one clear location. That's one of the places where the scheme files were actually a very nice feature of gnucash. Note again that the translation question is totally orthogonal to this definition location. There are several possibilities on how to organize the translation if a UI-string is inside an XML file, but that would distract from the definition location here, so I'd explain that another day. But that's really not complicated. What's much more important is that the original definition of interfaces is clean and concise, and from what I gathered these options are precisely a part of the backend interface. In summary: Is it possible to distinguish these two issues from the rest of your next commit proposal? From what I gathered, the rest of your work is well thought and can be incorporated
Re: installation paths, option definition (was: QofBackend changes in next commit)
On Friday 02 September 2005 3:22 pm, Christian Stimming wrote:
1. You propose to pass installations paths by a header file.
This is not a new mechanism.
2. You propose to separate the configuration option definition from its
documentation.
? The 'documentation' is where it is because it's translated.
I looked at putting this in the XML but it just isn't worth the effort.
(And just one nitpicking remark: The auto-generation of a header from a
header.in file is done by ./configure, not by automake -- automake
basically only creates a Makefile.in from a Makefile.am, but the
processing of the *.in files is always done by ./configure.)
Not in this case, nor in lots of cases within GnuCash. We use a Guile
convention in lots of areas that does no substitution during configure, only
in the Makefile.am using a customised sed routine.
qsf-dir.h: qsf-dir.h.in
rm -f [EMAIL PROTECTED]
sed $ [EMAIL PROTECTED] \
-e 's:@-QSF_SCHEMA_DIR-@:${QSF_SCHEMA_DIR}:g'
mv [EMAIL PROTECTED] $@
That has been in place for schema validation for some months and also passes
an installation path by a header file. No problems with that one. It's
actually more flexible because the output can be updated without a
complete ./autogen.sh.
Try grepping for sed in Makefile.am's all over the source tree.
$ vi gnome/Makefile.am
## We borrow guile's convention and use @-...-@ as the substitution
## brackets here, instead of the usual @[EMAIL PROTECTED] This prevents
autoconf
## from substituting the values directly into the left-hand sides of
## the sed substitutions.
gnucash.keys: gnucash.keys.in ${top_builddir}/config.status
rm -f [EMAIL PROTECTED]
sed $ [EMAIL PROTECTED] \
-e 's:@-icondir-@:${appicondir}:g'
chmod +x [EMAIL PROTECTED]
mv [EMAIL PROTECTED] $@
I guess the only difference is that this header is seeking to be installed.
As for #1, that was:
Neil Williams wrote:
On my system, this header defines (for cashutil):
#define GNC_LIB_DIR /opt/garfield/cashutil/lib
#define GNC_XML_DIR /opt/garfield/cashutil/share/xml/cashutil
#define GNC_LIB_NAME libgnc-backend-file.la
#define GNC_LIB_INIT gnc_provider_init
Passing installation paths from one library/application to another by
this method is actually not-so-common or rather unorthodox. The usual
way of passing such installation paths currently is by pkg-config, where
the library will define variables with the paths in its *.pc file.
OK, I can do that. However, it's just duplicating the existing method which
will still remain to provide the library name and init function name. I see
no reason to put that in qof-1.pc
GnuCash will need to know where the GNC backend is installed (as it will
be shared with cashutil) and will also pick up the location of QSF via
#include qof.h. So GnuCash uses two such header files, gncla-dir.h
(which automake generates from src/backend/gncla-dir.h.in) and
qofla-dir.h (from qof.h).
In principle that is fine. I'm just a bit confused: GnuCash needs a GNC
backend?
Yes, because this backend is to be shared with CashUtil which is installable
without GnuCash. It could, conceivably, be installed outside the GnuCash
package directories - it's probably best that it is so that CashUtil
installation doesn't need to mess around in a GnuCash installation. They both
need libcashobjects.la and libgnc-backend-file.la which can be installed in
some shared directory under the control of a new package. Straight-forward
dependencies at the package level (apt-get).
GnuCash has always loaded the gnc file backend as a separate entity, it's just
it's being prepared to be shared with CashUtil and may not be in the GnuCash
installation directories for much longer. (i.e. on the user's system).
Err... can you draw a picture which part depends on which part
here, and where Gnucash GUI, GNC backend, QSF, and QOF all fit into
that picture?
The outline picture is here:
http://www.data-freedom.org/explain.html#example
The only difference is that Programs A and B actually use the same backend
(which makes it kinda hard to draw). A1 == B1 because objects A == objects B.
However, ProgramA != ProgramB.
PilotQOF calls libqof which provides QSF as no other backend is defined.
Gnucash GUI calls the gnc file backend and adds the QSF backend. Much as it
has always done. CashUtil does the same. Both GnuCash and CashUtil load the
objects and ancillary logic from libcashobjects.la which may or may not be
installed in a GnuCash installation directory.
In particular, which part depends on which one *at compile
time*? That is not a problem, but just a bit confusion on my side.
GnuCash depends on QSF via a dependency on QOF. It also depends on
libcashobjects.la and libgnc-backend-file.la via the new shared package. i.e.
the cashobjects and the gnc file backend are being prepared for a separate
installation from GnuCash - a CashUtil
Re: installation paths, option definition (was: QofBackend changes in next commit)
On Friday 02 September 2005 5:29 pm, Derek Atkins wrote: This is not a new mechanism. No, but it's not recommended. If you had built CashUtil as part of the GnuCash source tree then I'd consider it more acceptable (because it's all part of one source tree package). But being external. No, I'm not convinced that passing configuration in a header file is necessarily the right method. Note that 'config.h' is *NOT* installed! So should the name of the library and the name of the init function be in qof-1.pc or should those who want that information put it into their files themselves? After all, it's hardly configuration - the filename isn't likely to change and the function name is part of the API. I don't mind putting the directory in qof-1.pc (and something similar for libgnc-backend-file.la so that CashUtil can find it). What about the QSF XML schema location? Should that go in qof-1.pc too? That is also installed by QOF (using a .h) currently. 2. You propose to separate the configuration option definition from its documentation. ? The 'documentation' is where it is because it's translated. I looked at putting this in the XML but it just isn't worth the effort. I think Christian's point is that you put the english text in the XML file Ah! Didn't realise that. , but then load the translations elsewhere. How does that work with gettext? Doesn't gettext have to have somewhere in the C file to place the translation? That way the definition and the description are always kept together. You don't use XML's language support, but you do use XML to keep the documentation for the options. The process at runtime would be: load the XML read the description out of XML translate the description using the translation files So what reference is in the translation files and where does gettext put the translated strings? Yes, because this backend is to be shared with CashUtil which is installable without GnuCash. It could, conceivably, be installed outside the GnuCash package directories - it's probably best that it is so that CashUtil installation doesn't need to mess around in a GnuCash installation. They both need libcashobjects.la and libgnc-backend-file.la which can be installed in some shared directory under the control of a new package. Straight-forward dependencies at the package level (apt-get). Neil, you really need to differentiate between build/source requirements and runtime/packaging requirements. You seem to continually drive development based on the latter, which is like the tail wagging the dog. I am conscious of the runtime/packaging requirements, yes - after all, I need to be able to package this myself eventually. The code does need to support the eventual packages and be shared with CashUtil - I guess I'm not sure where you'd put the dividing line. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpAd1jIE3TUx.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Debian installation
The problem is that gnucash was accidentally compiled against libgwrapguile0 instead of libgwrapguile1. Then, just after gnucash 1.6.0 was added to the distribution, libgwrapguile0 was removed [...] If anyone would like a copy of the old libgwrapguile0 .deb, you can grab from http://people.debian.org/~treacy/libgwrapguile0_0.9.12-3_i386.deb That did the trick for me - I am now among the elite who have gnucash up and running. Note that I had grabbed a libgwrapguile0 deb from gnucash.org, but it tossed up all kinds of other dependency problems. Your version dropped in much more nicely. Thanks, jon Jonathan Corbet Executive editor, LWN.net [EMAIL PROTECTED] ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Debian installation
So...I'm still trying to come up with a working gnucash 1.6. Still no joy in mudville. I've even gone so far as to put the vaunted Debian unstable on a system and try the apt-get command that I was so smugly told would bring me instant gnucash nirvana. No such luck. I get a gripe that gnucash depends on libgwrapguile0 = 0.9.1, which is not installable. Anybody know a way around this? Thanks, jon Jonathan Corbet Executive editor, LWN.net [EMAIL PROTECTED] ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Debian installation
On Mon, 18 Jun 2001 17:47:42 -0600, Jonathan Corbet [EMAIL PROTECTED] said: Jonathan I've even gone so far as to put the vaunted Debian unstable Jonathan on a system and try the apt-get command that I was so smugly Jonathan told would bring me instant gnucash nirvana. No such luck. Jonathan I get a gripe that gnucash depends on libgwrapguile0 = Jonathan 0.9.1, which is not installable. Anybody know a way around Jonathan this? who told you smugly? I told you matter-of-factly. :-) bash-2.05$ dpkg -l | grep libgwrap ii libgwrapguile0 0.9.12-3 g-warp: Tool for exporting C libraries into ii libgwrapguile1 1.1.10-3 g-warp: Tool for exporting C libraries into on my system. what does that give on yours? Also, sometimes with debian, I have had to do 'apt-get install packagenamewhichwasgivingmeproblems' all alone, and then 'apt-get install bigmammapackagename' which would work. I know it shouldn't work that way, but that helped me. rob ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Debian installation
On Mon, Jun 18, 2001 at 05:47:42PM -0600, Jonathan Corbet wrote: So...I'm still trying to come up with a working gnucash 1.6. Still no joy in mudville. I've even gone so far as to put the vaunted Debian unstable on a system and try the apt-get command that I was so smugly told would bring me instant gnucash nirvana. No such luck. I get a gripe that gnucash depends on libgwrapguile0 = 0.9.1, which is not installable. Anybody know a way around this? The problem is that gnucash was accidentally compiled against libgwrapguile0 instead of libgwrapguile1. Then, just after gnucash 1.6.0 was added to the distribution, libgwrapguile0 was removed (due to it's source not being available. I'm guessing the addition of libgwrapguile1 caused this). I have reported the problem to the wrapguile maintainer (who also happens to be the gnucash packager). I expect it will be fixed either tomorrow or the next day. If anyone would like a copy of the old libgwrapguile0 .deb, you can grab from http://people.debian.org/~treacy/libgwrapguile0_0.9.12-3_i386.deb So, while I feel Debian has a better developed dependency setup than other distributions, we are only human and make mistakes. :) -- James (Jay) Treacy [EMAIL PROTECTED] ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Problem after installation
[EMAIL PROTECTED] writes: I am facing a similar situation as Markus. I was using version 1.4.3 while Suse 7.0 was installed. Recently I upgraded to Suse 7.1, gnucash 1.4.3 still worked fine. Problems started when I discovered that later versions of gnucash were available. In the beginning I was not aware that one was already on the Suse CDs. I have to confess that I can no longer keep track of the the things I tried - several RPMs, different versions of gwrap and guile, I even tried to compile stuff. I currently again see 'undefined symbol: qt_error' from libguile. However I can see that libqthreads exists on my system. A version of guile 1.4 I could not find for Suse 7.1, so I downloaded the source, but am not able to run make without errors. One problem you may have is that g-wrap must be compiled against the *same* version of guile as gnucash. If possible, try and get your guile and g-wrap from the same source. If SuSE includes a version of g-wrap, guile and gnucash on your CD, stick with that. Can I put out another request to our user community to build a set of SuSE 7.x RPM's of gnucash and g-wrap, and possibly even send them to Dave for inclusion on the FTP site? Robert Merkel [EMAIL PROTECTED] telsa I left my client on #gtk+ overnight and there was nothing in scrollback at all except quit/rejoins. bighead telsa: well its been that for, I think 3 days now (ever since started coming back on IRC) telsa Clearly they are busy implementing telepathy, and dog-fooding it. :) ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Installation problems GnuCash1.4.9.tgz on SuSE 6.4 Solved/Inf
On Thu, 18 Jan 2001 12:00:01 -0600 (CST), [EMAIL PROTECTED] said: linas Dave, I guess your the maintainer ... is there an easy way of linas setting up a 'make realclean' so that config.cache is erased linas and autogen.sh get rerun automagically? 'make clean' is not linas enough after installing/upgrading lbraries, linas --linas linas It's been rumoured that Meer van Houtum, P.G. van der said: Then reinstall guile1.4 and g-wrap0.9.8 (be sure to make clean before install) actually, you will want to rm config.cache and then ./autogen.sh in the gnucash dir; otherwise, you configure will remember the old libraries/commands. Sorry, before compiling I am used to do a make clean. The make clean for the gnucash dir did not enter in the notes expplicitly but should be there. To get a completely rebuilt system you want to make distclean ./configure options make Normal gnu software methodology. autogen.sh exists because you don't want auto generated files (Makefile.in's, configure, config.h.in, etc etc) in CVS. It produces these files. In fact you should be able to change configure.in and Makefile.am's and have make regenerate things as well because automake adds rules to do this (though sometimes this doesn't work as well as it seems it should or at least that's my impression). Jim -- @James LewisMoss [EMAIL PROTECTED] | Blessed Be! @http://jimdres.home.mindspring.com | Linux is kewl! @"Argue for your limitations and sure enough, they're yours." Bach ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Installation problems GnuCash1.4.9.tgz on SuSE 6.4 Solved/Inf
Dave, I guess your the maintainer ... is there an easy way of setting up a 'make realclean' so that config.cache is erased and autogen.sh get rerun automagically? 'make clean' is not enough after installing/upgrading lbraries, --linas It's been rumoured that Meer van Houtum, P.G. van der said: Then reinstall guile1.4 and g-wrap0.9.8 (be sure to make clean before install) actually, you will want to rm config.cache and then ./autogen.sh in the gnucash dir; otherwise, you configure will remember the old libraries/commands. Sorry, before compiling I am used to do a make clean. The make clean for the gnucash dir did not enter in the notes expplicitly but should be there. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: installation of gnucash
Am Sam, 15 Jul 2000 schrieb Robert and Dave: Poldi Winkler writes: Hello, Shall I forget gnucash in the moment or do you have the solution? Try running (as root) guile -c "(use-modules (ice-9 slib)) (require 'new-catalog)" dave Did you try putting in a symlink (ie, as root, cd /usr/share/guile/slib ln -s mklibcat.scm mklibcat Hello Robert and Dave, I have made the link and the first problem is over. But then I got the message: gnucash ERROR: In procedure open-file: ERROR: Keine Berechtigung: "/usr/share/guile/slibcat" gnucash: [W] "failure loading ""/usr/share/gnucash/scm/c-interface.scm" ERROR: In procedure open-file: ERROR: Keine Berechtigung: "/usr/share/guile/slibcat" gnucash: [W] "failure loading ""/usr/share/gnucash/scm/prefs.scm" ERROR: In procedure open-file: ERROR: Keine Berechtigung: "/usr/share/guile/slibcat" gnucash: [W] "failure loading ""/usr/share/gnucash/scm/srfi/srfi-8.guile.scm" ERROR: In procedure open-file: ERROR: Keine Berechtigung: "/usr/share/guile/slibcat" gnucash: [W] "failure loading ""/usr/share/gnucash/scm/text-export.scm" ERROR: In procedure open-file: ERROR: Keine Berechtigung: "/usr/share/guile/slibcat" gnucash: [W] "failure loading ""/usr/share/gnucash/scm/report.scm" ERROR: In procedure open-file: ERROR: Keine Berechtigung: "/usr/share/guile/slibcat" gnucash: [W] "failure loading ""/usr/share/gnucash/scm/report/average-balance.scm" ERROR: In procedure open-file: ERROR: Keine Berechtigung: "/usr/share/guile/slibcat" gnucash: [W] "failure loading ""/usr/share/gnucash/scm/text-export.scm" ERROR: Unbound variable: html-table-row gnucash: [W] "failure loading ""/usr/share/gnucash/scm/report/balance-and-pnl.scm" ERROR: Unbound variable: gnc:make-string-database gnucash: [W] "failure loading ""/usr/share/gnucash/scm/report/folio.scm" ERROR: Unbound variable: gnc:make-string-database gnucash: [W] "failure loading ""/usr/share/gnucash/scm/report/hello-world.scm" ERROR: Unbound variable: gnc:make-string-database gnucash: [W] "failure loading ""/usr/share/gnucash/scm/report/transaction-report.scm" /usr/share/gnucash/scm/path.scm:101:35: While evaluating arguments to gnc:config-var-value-get in expression (gnc:config-var-value-get gnc:*config-dir*): /usr/share/gnucash/scm/path.scm:101:35: Unbound variable: gnc:*config-dir* I have no slibcat. After I have run guile -c "(use-modules (ice-9 slib)) (require 'new-catalog)" I could open gnucash. a great wonder! But I think it is really to complicated for an amateur. But anyway - thanks for the help. Poldi ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: installation of gnucash
Poldi Winkler writes: Hello, Shall I forget gnucash in the moment or do you have the solution? I have found in /usr/share/guile/slib/mklibcat.scm and not mklibcat, but all the other files are in /usr/share/gnucash/scm. Try running (as root) guile -c "(use-modules (ice-9 slib)) (require 'new-catalog)" dave ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: installation of gnucash
Poldi Winkler writes: After I have run guile -c "(use-modules (ice-9 slib)) (require 'new-catalog)" I could open gnucash. a great wonder! But I think it is really to complicated for an amateur. But anyway - thanks for the help. Poldi This one isn't our fault, AFAIK. I believe it's a problem with the way guile and slib are set up by the distributors. Robert Merkel [EMAIL PROTECTED] ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
installation of gnucash
Hello, it's a very hard job to install gnucash! I have used the SuSE-rpm-File from Stephan and was very happy when I have solved all the dependences (I hope so!). The last topic was slib. Then I have started gnucash and I got the following message: gnucash ERROR: In procedure open-file: ERROR: Datei oder Verzeichnis nicht gefunden: "/usr/share/guile/slib/mklibcat" gnucash: [W] "failure loading ""/usr/share/gnucash/scm/c-interface.scm" ERROR: In procedure open-file: ERROR: Datei oder Verzeichnis nicht gefunden: "/usr/share/guile/slib/mklibcat" gnucash: [W] "failure loading ""/usr/share/gnucash/scm/prefs.scm" ERROR: In procedure open-file: ERROR: Datei oder Verzeichnis nicht gefunden: "/usr/share/guile/slib/mklibcat" gnucash: [W] "failure loading ""/usr/share/gnucash/scm/srfi/srfi-8.guile.scm" ERROR: In procedure open-file: ERROR: Datei oder Verzeichnis nicht gefunden: "/usr/share/guile/slib/mklibcat" gnucash: [W] "failure loading ""/usr/share/gnucash/scm/text-export.scm" ERROR: In procedure open-file: ERROR: Datei oder Verzeichnis nicht gefunden: "/usr/share/guile/slib/mklibcat" gnucash: [W] "failure loading ""/usr/share/gnucash/scm/report.scm" ERROR: In procedure open-file: ERROR: Datei oder Verzeichnis nicht gefunden: "/usr/share/guile/slib/mklibcat" gnucash: [W] "failure loading ""/usr/share/gnucash/scm/report/average-balance.scm" ERROR: In procedure open-file: ERROR: Datei oder Verzeichnis nicht gefunden: "/usr/share/guile/slib/mklibcat" gnucash: [W] "failure loading ""/usr/share/gnucash/scm/text-export.scm" ERROR: Unbound variable: html-table-row gnucash: [W] "failure loading ""/usr/share/gnucash/scm/report/balance-and-pnl.scm" ERROR: Unbound variable: gnc:make-string-database gnucash: [W] "failure loading ""/usr/share/gnucash/scm/report/folio.scm" ERROR: Unbound variable: gnc:make-string-database gnucash: [W] "failure loading ""/usr/share/gnucash/scm/report/hello-world.scm" ERROR: Unbound variable: gnc:make-string-database gnucash: [W] "failure loading ""/usr/share/gnucash/scm/report/transaction-report.scm" /usr/share/gnucash/scm/path.scm:101:35: While evaluating arguments to gnc:config-var-value-get in expression (gnc:config-var-value-get gnc:*config-dir*): /usr/share/gnucash/scm/path.scm:101:35: Unbound variable: gnc:*config-dir* Shall I forget gnucash in the moment or do you have the solution? I have found in /usr/share/guile/slib/mklibcat.scm and not mklibcat, but all the other files are in /usr/share/gnucash/scm. Thanks in advance Poldi ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
installation of gnucash
Poldi Winkler writes: Hello, it's a very hard job to install gnucash! I have used the SuSE-rpm-File from Stephan and was very happy when I have solved all the dependences (I hope so!). The last topic was slib. Then I have started gnucash and I got the following message: gnucash ERROR: In procedure open-file: ERROR: Datei oder Verzeichnis nicht gefunden: "/usr/share/guile/slib/mklibcat" gnucash: [W] "failure loading ""/usr/share/gnucash/scm/c-interface.scm" ERROR: In procedure open-file: ERROR: Datei oder Verzeichnis nicht gefunden: "/usr/share/guile/slib/mklibcat" gnucash: [W] "failure loading ""/usr/share/gnucash/scm/prefs.scm" ERROR: In procedure open-file: ERROR: Datei oder Verzeichnis nicht gefunden: "/usr/share/guile/slib/mklibcat" gnucash: [W] "failure loading ""/usr/share/gnucash/scm/srfi/srfi-8.guile.scm" ERROR: In procedure open-file: ERROR: Datei oder Verzeichnis nicht gefunden: "/usr/share/guile/slib/mklibcat" gnucash: [W] "failure loading ""/usr/share/gnucash/scm/text-export.scm" ERROR: In procedure open-file: ERROR: Datei oder Verzeichnis nicht gefunden: "/usr/share/guile/slib/mklibcat" gnucash: [W] "failure loading ""/usr/share/gnucash/scm/report.scm" ERROR: In procedure open-file: ERROR: Datei oder Verzeichnis nicht gefunden: "/usr/share/guile/slib/mklibcat" gnucash: [W] "failure loading ""/usr/share/gnucash/scm/report/average-balance.scm" ERROR: In procedure open-file: ERROR: Datei oder Verzeichnis nicht gefunden: "/usr/share/guile/slib/mklibcat" gnucash: [W] "failure loading ""/usr/share/gnucash/scm/text-export.scm" ERROR: Unbound variable: html-table-row gnucash: [W] "failure loading ""/usr/share/gnucash/scm/report/balance-and-pnl.scm" ERROR: Unbound variable: gnc:make-string-database gnucash: [W] "failure loading ""/usr/share/gnucash/scm/report/folio.scm" ERROR: Unbound variable: gnc:make-string-database gnucash: [W] "failure loading ""/usr/share/gnucash/scm/report/hello-world.scm" ERROR: Unbound variable: gnc:make-string-database gnucash: [W] "failure loading ""/usr/share/gnucash/scm/report/transaction-report.scm" /usr/share/gnucash/scm/path.scm:101:35: While evaluating arguments to gnc:config-var-value-get in expression (gnc:config-var-value-get gnc:*config-dir*): /usr/share/gnucash/scm/path.scm:101:35: Unbound variable: gnc:*config-dir* Shall I forget gnucash in the moment or do you have the solution? I have found in /usr/share/guile/slib/mklibcat.scm and not mklibcat, but all the other files are in /usr/share/gnucash/scm. Did you try putting in a symlink (ie, as root, cd /usr/share/guile/slib ln -s mklibcat.scm mklibcat ) Could you please report back if this helps? Robert Merkel [EMAIL PROTECTED] ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
binary rpm installation location
I struggled with gnucash 1.2.5-1 binary rpm on RedHat 6.0 before, and I'm back to try again. I had uncertainties about the installation. When I attempt it, I'm first told that jcollins account can't be found, and so the installation is done for root. I want a user to use the program; can this message just be ignored? I install as user requires changing permissions on a large number of other files, which I'd just as soon not do. Yet, when root installs, it, user can start and program. But, because the program does not seem to run correctly when installed, I wonder if root installation is correct. The problems I experience are a) the new account I create does not show up in the gnucash window, but must be opened by File-OpenFile, which in turn reveals a set of saves. I'm not sure which of these I need to open. I assume the account name should appear in the window when gnucash starts. b) When it comes to reconciliation with bank statements, the directions say to start by opening the Reconcile Window and THEN check off the transactions. This order makes no sense to me. Besides, the initial balance is zero (I am forced to set initial balance by entering a deposit rather than a balance under Opening Balance transaction description, because the balance field is not active). Also, in the Reconcile Window, the ending balance field, where the directions say to enter the bank statement ending balance, is not active either. So I'm not sure of my installation procedure. Is there a FAQ to answer simple beginner questions, such as when data must be saved, should it be done with file having a *xac extension? In reconciling an account, what do the "n" and "c" abbreviations stand for? Haines Brown -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Xacc Installation
I am trying to install Xacc. I had a lot of trouble in the beginning getting Lesstif and Xbae installed. When I would run make depend the compile would fail saying that it needed files from a '/usr/include/Xbae' directory (it also had others to search in). I ran a find on the machine, and found the same files under the Xacc tree - so I put them where the 'make depend' was looking for them. Now when I run make, it drops out on an Error 1, then 2 Error 2's stating that "initializer element is not constant" Anyone have any ideas? If you need more info tell me. Chris Brunner "Strike any user to continue" -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Installation on Slackware 7
Hi, I'm trying to install gnucash on a Slackware 7.0 system, and I know it uses LessTif (which I installed from the setup). I also installed SWIG, Nana, guile, and XmHTML. The configure works fine. When I try to compile I get the following msg: obj/motif/HelpWindow.o: In function `htmlWindow': /usr/local/src/gnucash-1.2.5/src/motif/HelpWindow.c:357: undefined reference to `_XmHTMLStrings' /usr/local/src/gnucash-1.2.5/src/motif/HelpWindow.c:357: undefined reference to `_XmHTMLStrings' /usr/local/src/gnucash-1.2.5/src/motif/HelpWindow.c:357: undefined reference to `xmHTMLWidgetClass' /usr/local/src/gnucash-1.2.5/src/motif/HelpWindow.c:375: undefined reference to `_XmHTMLStrings' /usr/local/src/gnucash-1.2.5/src/motif/HelpWindow.c:376: undefined reference to `_XmHTMLStrings' obj/motif/HelpWindow.o: In function `frameCB': /usr/local/src/gnucash-1.2.5/src/motif/HelpWindow.c:493: undefined reference to `_XmHTMLStrings' /usr/local/src/gnucash-1.2.5/src/motif/HelpWindow.c:510: undefined reference to `_XmHTMLStrings' obj/motif/HelpWindow.o: In function `htmlAnchorCB': /usr/local/src/gnucash-1.2.5/src/motif/HelpWindow.c:625: undefined reference to `XmHTMLAnchorScrollToName' obj/motif/HelpWindow.o: In function `xaccJumpToLabel': /usr/local/src/gnucash-1.2.5/src/motif/HelpWindow.c:685: undefined reference to `XmHTMLTextSetString' /usr/local/src/gnucash-1.2.5/src/motif/HelpWindow.c:687: undefined reference to `XmHTMLAnchorScrollToName' /usr/local/src/gnucash-1.2.5/src/motif/HelpWindow.c:689: undefined reference to `XmHTMLTextScrollToLine' obj/motif/HelpWindow.o: In function `htmlReadImageProc': /usr/local/src/gnucash-1.2.5/src/motif/HelpWindow.c:716: undefined reference to `XmHTMLImageDefaultProc' collect2: ld returned 1 exit status make[3]: *** [../../gnucash.motif] Error 1 make[3]: Leaving directory `/usr/local/src/gnucash-1.2.5/src/motif' make[2]: *** [motif] Error 2 make[2]: Leaving directory `/usr/local/src/gnucash-1.2.5/src' make[1]: *** [build-flavor] Error 2 make[1]: Leaving directory `/usr/local/src/gnucash-1.2.5' make: *** [motif] Error 2 I placed a link in the X11 directory to the XmHTML headers. I'm not sure if that was correct. Is there anything special I need to set to compile it for Lesstif? I've been trying to figure this one out, but I can't seem to get past the motif part. I'm sort of stuck. Any help would be appreciated. Thanks. Budman Linux. Because. -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Installation helps
I finally got GNUCash 1.2.5 working under SUSE 6.3. I actually built it from sources, but had to do a few other things not necessarily related to the sources build. For starters, I think you can address the error by running GNUCash as root the first time. The slib libraries need to build some sort of configuration file in the directory where you have slib installed. You need to have write permission to the directory to initially create the file. Once created I have not experienced any issues just running it as a user. The other thing I ran into was that you need to use lesstif 0.88.1. SUSE 6.3 installs lesstif 0.89.?. I tried installing the latest-and-greatest lesstif and still got problems (you cannot create a new file -- you can edit and save existing files, just not create new ones). There seems to be some other small problems related to this too. I had to uninstall lesstif, get the source from the GNUCash web site, and build the old version. Works pretty good now. Hope that helps. Dayne Jim Miller wrote: I am trying to install gnucash 1.2.5 on SuSE 6.3 and having problems. I have tried the binary and src distributions without luck. Src. I get an error on Make motif - aclocal: configure.in: 33: macro 'AM_PROG_LIBTOOL' not found in library that seems to be the error in the group. On the binary when I run gnucash Failure loading prefs.scm text-export.scm While evaluation arguments to gnc:config-var-value-get in expression (gnc:config-var-value-get gnc:*config-dir*): /usr/shar/gnucash/scm/path.scm:64:35: Unbound variable: gnc:*config-dir* Thanks! -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED] -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Installation helps
Dayne Medlyn writes: I finally got GNUCash 1.2.5 working under SUSE 6.3. I actually built it from sources, but had to do a few other things not necessarily related to the sources build. For starters, I think you can address the error by running GNUCash as root the first time. The slib libraries need to build some sort of configuration file in the directory where you have slib installed. You need to have write permission to the directory to initially create the file. Once created I have not experienced any issues just running it as a user. The other thing I ran into was that you need to use lesstif 0.88.1. SUSE 6.3 installs lesstif 0.89.?. I tried installing the latest-and-greatest lesstif and still got problems (you cannot create a new file -- you can edit and save existing files, just not create new ones). There seems to be some other small problems related to this too. I had to uninstall lesstif, get the source from the GNUCash web site, and build the old version. Works pretty good now. Somebody has developed a patch to fix this, and allow lesstif 0.89 to be used. Hopefully a 1.2.6 with the patch (and a couple of other minor fixes to lesstif stuff) can be released soon. -- --- Robert Merkel [EMAIL PROTECTED] Humanity has advanced, when it has advanced, not because it has been sober, responsible, and cautious, but because it has been playful, rebellious, and immature. -- Tom Robbins --- -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Installation helps
I am trying to install gnucash 1.2.5 on SuSE 6.3 and having problems. I have tried the binary and src distributions without luck. Src. I get an error on Make motif - aclocal: configure.in: 33: macro 'AM_PROG_LIBTOOL' not found in library that seems to be the error in the group. On the binary when I run gnucash Failure loading prefs.scm text-export.scm While evaluation arguments to gnc:config-var-value-get in expression (gnc:config-var-value-get gnc:*config-dir*): /usr/shar/gnucash/scm/path.scm:64:35: Unbound variable: gnc:*config-dir* Thanks! -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Installation problems
Hi. Sorry to bother you again, but there seems to some problems still As you wil see below, I had some problems with lesstif. More specific the libXm.so.1. It turned out that I had installed the lesstif-0.88.1-3, but even though I could see that it contained the libXm.so.1 file it didn't install it. Not even if I used the --allfiles parameter. Well, I then tried to use the lesstif-0.87.0-1, which according to the informations on rufus should contain the libXm.so.1. Now using this version of lesstif, I got gnucash to start!!! But as predicted in the readme file in gnucash it almost immediately crashed. Then I tried to do an upgrade to lesstif-0.88.1-3, but it removed the libXm.so.1 again. Now I tried to go to the lesstif homepage, where I found lesstif-0.88.1-1.i386.rpm. A "normal" installation of this didn't get me the libXm.so.1, but when forcing it with --allfiles I finally managed. But but but... It is to put it mildly, very unstable.. It's a bit difficult to point out specificcaly what is wrong, but one example could be that I tried to create an account a minute ago. I give the account a name, a description, a currency (I write DKK as I am from Denmark and use Danish Crowns (Kroner)), I write a little note, and finnaly put an amount in th account. So far so good. But when I tried to create another account, gnucash went down immediately with the message: Segmentation fault (core dump) Same thing happens when I have managed to create two account and tries to save the file.. And then... suddenly I can do a lot of things.. Create account, activate the report section (Which is filled with something that looks rather developimg?), but when I try to save the file, I get the message that the file doen't contain anything, which it off course does, as I have just created two account a put in some numbers in both... Does anyone have an idea of what is wrong now? And if yes, how can I get further? Thank you i advance Kind regards Søren Vedsted Dave Peticolas wrote: fyi, nana is also available as an rpm. Coluld you please tell me where? I'm afraid I've lost the location, sorry. Have you tried the nana homepage? Yes I did, but as far as remember I didn't find anything... gnucash: error in loadingshared libraries: libXm.so.1: cannot open shared object file: No such file or directory Is this something with lesstif? In that case isn't it an earlier version? I though that you could use the newer versions of lesstif with gnucash 1.2.3? Those are definitely the lesstif libraries it's not finding. What version of lesstif do you have? I'm running 0.88.1. You installed lesstif from rpm, right? Yes I did. See above. dave -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Installation problems
-- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
