RE: data file differences in 2.2
Derek Atkins wrote: Kevin HaleBoyes [EMAIL PROTECTED] writes: I did notice one other thing. 2.0 doesn't know about the ROOT account type so it changes the type to NO_TYPE. I'm wondering how 2.2 will respond to that? Haven't tried it yet. What version of 2.0.x are you using? I /think/ that 2.2 is smart enough to convert that back to a ROOT account. 2.0.5 I've been poking around the code to see if it would convert it back to a ROOT account but I get lost once it starts dealing with the QOF code. I did notice what seems to be a bit of redundant code: Around line 450 in gnc-account-xml-v2.c it calls gnc_book_get_root_account() and if it returns NULL then gnc_account_create_root() is called. But, if gnc_book_get_root_account() finds no root account then it creates one and returns it. K. This email communication and any files transmitted with it may contain confidential and or proprietary information and is provided for the use of the intended recipient only. Any review, retransmission or dissemination of this information by anyone other than the intended recipient is prohibited. If you receive this email in error, please contact the sender and delete this communication and any copies immediately. Thank you. http://www.encana.com ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
RE: data file differences in 2.2
Hale Boyes, Kevin wrote: Derek Atkins wrote: Kevin HaleBoyes [EMAIL PROTECTED] writes: I did notice one other thing. 2.0 doesn't know about the ROOT account type so it changes the type to NO_TYPE. I'm wondering how 2.2 will respond to that? Haven't tried it yet. What version of 2.0.x are you using? I /think/ that 2.2 is smart enough to convert that back to a ROOT account. 2.0.5 I've been poking around the code to see if it would convert it back to a ROOT account but I get lost once it starts dealing with the QOF code. Just to recap... I have a data file saved by GnuCash 2.0.5. I opened that file in 2.2.0 and saved. I then took that file and opened and saved it in 2.0.5 which causes the Root account type to be set to NO_TYPE. If this file is then opened in 2.2.0 again it will not recognize the Root account properly. So, the Root account shows up in the display. I didn't check but I suspect it also got re-parented to another Root account. So, I'd say that once you've saved your data file in 2.2.0 you should not go back to 2.0.5 and save there. This has nothing to do with the data file change noted in the release notes (around scheduled transactions). Kevin. This email communication and any files transmitted with it may contain confidential and or proprietary information and is provided for the use of the intended recipient only. Any review, retransmission or dissemination of this information by anyone other than the intended recipient is prohibited. If you receive this email in error, please contact the sender and delete this communication and any copies immediately. Thank you. http://www.encana.com ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
RE: SQL Backend?
Albert Lash wrote: Is the data model that is / was used for the SQL backend around anywhere? I don't know the answer to that question but there was a recent addition to contrib that has a PostgreSQL schema and a perl program for loading a gnucash datafile. K. This email communication and any files transmitted with it may contain confidential and or proprietary information and is provided for the use of the intended recipient only. Any review, retransmission or dissemination of this information by anyone other than the intended recipient is prohibited. If you receive this email in error, please contact the sender and delete this communication and any copies immediately. Thank you. http://www.encana.com ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
add .deps to svn:ignore in trunk/packaging/win32
I think we need to add .deps to the svn:ignore property in trunk/packaging/win32. At least I get this after building from SVN: $ svn st ? .deps Thanks, K. This email communication and any files transmitted with it may contain confidential and or proprietary information and is provided for the use of the intended recipient only. Any review, retransmission or dissemination of this information by anyone other than the intended recipient is prohibited. If you receive this email in error, please contact the sender and delete this communication and any copies immediately. Thank you. http://www.encana.com ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Adjust the development version message for the 2.2.0 release.
I've created bug 457812 and attached a patch. Thanks for the release! K. This email communication and any files transmitted with it may contain confidential and or proprietary information and is provided for the use of the intended recipient only. Any review, retransmission or dissemination of this information by anyone other than the intended recipient is prohibited. If you receive this email in error, please contact the sender and delete this communication and any copies immediately. Thank you. http://www.encana.com ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
small doc patch
$ cd gnucash-docs-trunk $ svn diff Index: guide/C/ch_capgain.xml === --- guide/C/ch_capgain.xml (revision 16247) +++ guide/C/ch_capgain.xml (working copy) @@ -59,7 +59,7 @@ titleEstimating Valuation/title paraAs mentioned in the introduction to this chapter, capital gains are -the profits received from the same of an asset. This section will describe +the profits received from the sale of an asset. This section will describe how to record capital gains in GnuCash./para paraThe accounting methods for handling asset appreciation differs This email communication and any files transmitted with it may contain confidential and or proprietary information and is provided for the use of the intended recipient only. Any review, retransmission or dissemination of this information by anyone other than the intended recipient is prohibited. If you receive this email in error, please contact the sender and delete this communication and any copies immediately. Thank you. http://www.encana.com ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
RE: strange behaviour in stock buy transaction
Moving this over from -user.
Des,
Setting LC_MONETARY to en_CA works for me as well. Thanks.
I've taken the patch from comment #7 and updated it to compile
in trunk. It works for me when I go through the steps I originally
posted.
I've requested a bugzilla account so I can add the updated
patch to the bug report if that is useful.
The patch looks only at the parent of the account. Can the parent
have a non-currency-type commodity in some cases? If that can happen
should we visit ancestors until we find one?
K.
Here is the patch so far. Is this the format I should use for the
attachment?
Index: src/register/ledger-core/split-register-load.c
===
--- src/register/ledger-core/split-register-load.c (revision 16043)
+++ src/register/ledger-core/split-register-load.c (working copy)
@@ -216,12 +216,26 @@
/* Determine the proper currency to use for this transaction.
* if default_account != NULL and default_account-commodity is
- * a currency, then use that. Otherwise use the default currency.
+ * a currency, then use that. Otherwise, use the commodity
+ * of the parent account if it is a currency.
+ * Otherwise use the default currency.
*/
if (default_account != NULL) {
gnc_commodity * commodity = xaccAccountGetCommodity
(default_account);
if (gnc_commodity_is_currency(commodity))
currency = commodity;
+ else
+ {
+/* Account commodity is not a currency, see if the parent
account
+ is a currency account and use it's currency if so. */
+Account *parent_account = gnc_account_get_parent (
default_account );
+if (parent_account)
+{
+ commodity = xaccAccountGetCommodity (parent_account);
+ if (gnc_commodity_is_currency(commodity))
+currency = commodity;
+}
+ }
}
gnc_suspend_gui_refresh ();
-Original Message-
From: Derek Atkins [mailto:[EMAIL PROTECTED]
Sent: Friday, May 04, 2007 7:23 AM
To: Hale Boyes, Kevin
Cc: [EMAIL PROTECTED]
Subject: Re: strange behaviour in stock buy transaction
Hale Boyes, Kevin [EMAIL PROTECTED] writes:
Is there any way to tell what locale I'm in?
echo $LANG
Would I be able to set me locale to en_CA and have it
work properly?
Yes.
I've read the bug report but there doesn't seem to be any
consensus on how this might be fixed. The patch presented in
comment #7 seems like it would work in my case but it is
different than comment #4 which also seems like a workable
solution.
I'm leaning towards the patch in #7. It's not the BEST
solution, but it's better than others. But it doesn't
solve the general problem of how you choose a currency
for any random register (e.g. General Ledger register or
a Search Results register).
Is there anything I can do to help us reach an agreement
on how to proceed? Once that has happened I'm willing
to work on a patch.
Umm.. Move over to -devel and propose a solution?
Kevin.
-derek
-Original Message-
From: Derek Atkins [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 03, 2007 12:40 PM
To: Hale Boyes, Kevin
Cc: [EMAIL PROTECTED]
Subject: Re: strange behaviour in stock buy transaction
Hi,
I bet you're in the C locale (or maybe en_US), so your locale currency
is USD, not CAD. So you're probably hitting this bug:
http://bugzilla.gnome.org/show_bug.cgi?id=116353
-derek
Quoting Hale Boyes, Kevin [EMAIL PROTECTED]:
I've been learning more about tracking stock purchases and sales
in GnuCash and have found something I don't understand.
First some setup:
- start GC with --nofile and then create a new file.
- choose CAD for currency.
- choose Common + Investment accounts with no opening balances.
- create new accounts under Brokerage Account
- type Cash named Cash.
- type Stock named SUNW (for which I created a new commodity
with fraction 1/100 on the NASDAQ.
- move $1000 into Checking Account from Equity:Opening Balances.
When I buy stock I tend to transfer money from my chequing account
into
my brokerage account. Then I buy the stock. The end price may not
use
up the full amount of cash that I transfered but that is fine as I
run
a positive cash balance in my brokerage account.
So, I transfered $400 from chequing to the new cash account under
Brokerage Account -- Assets:Investments:Brokerage Account:Cash.
Now the balance shown in that ledger is $400.
Then I buy some shares of SUNW. So, in the SUNW ledger I enter a
buy with the offset account being Assets:Investments:Brokerage
Account:Cash
and everything looks fine until I look back into the cash account.
The buy transaction is displayed but the amount fields are blank and
the balance has not been adjusted and still displays $400.
I expect the balance to have been adjusted for the money I just used
to buy the stock but maybe
RE: configure is failing for me
This has been solved before and a quick search turned up the solution. Sorry for the noise. K. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hale Boyes, Kevin Sent: Wednesday, May 02, 2007 3:17 PM To: gnucash-devel@gnucash.org Subject: configure is failing for me In trunk r16039 I get an error when I run configure. I have guile (and guile-devel) 1.8 installed on a fairly up-to-date FC6. Any thoughts? Thanks, K. ./configure --prefix=/opt/gnucash --enable-debug --enable-ofx checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking for perl... /usr/bin/perl checking for XML::Parser... ok checking for iconv... /usr/bin/iconv checking for msgfmt... /usr/bin/msgfmt checking for msgmerge... /usr/bin/msgmerge checking for xgettext... /usr/bin/xgettext Using config source xml:merged:/etc/gconf/gconf.xml.defaults for schema installation Using $(sysconfdir)/gconf/schemas as install directory for schema files checking how to run the C preprocessor... gcc -E checking for egrep... grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking build system type... i686-redhat-linux-gnu checking host system type... i686-redhat-linux-gnu checking locale.h usability... yes checking locale.h presence... yes checking for locale.h... yes checking for LC_MESSAGES... yes checking libintl.h usability... yes checking libintl.h presence... yes checking for libintl.h... yes checking for ngettext in libc... yes checking for dgettext in libc... yes checking for bind_textdomain_codeset... yes checking for msgfmt... /usr/bin/msgfmt checking for dcgettext... yes checking for gmsgfmt... /usr/bin/msgfmt checking for xgettext... /usr/bin/xgettext checking for catalogs to be installed... ca cs da de el en_GB es_NI es eu fr hu it ja nb ne nl pl pt_BR pt ro ru rw sk sv ta tr uk zh_CN zh_TW checking for a BSD-compatible install... /usr/bin/install -c checking for a sed that does not truncate output... /bin/sed checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... no checking for c++... no checking for gpp... no checking for aCC... no checking for CC... no checking for cxx... no checking for cc++... no checking for cl... no checking for FCC... no checking for KCC... no checking for RCC... no checking for xlC_r... no checking for xlC... no checking whether we are using the GNU C++ compiler... no checking whether g++ accepts -g... no checking dependency style of g++... none checking for g77... no checking for f77... no checking for xlf... no checking for frt... no checking for pgf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for f90... no checking for xlf90... no checking for pgf90... no checking for epcf90... no checking for f95... no checking for fort... no checking for xlf95... no checking for ifc... no checking for efc... no checking for pgf95... no checking for lf95... no checking for gfortran... no checking whether we are using the GNU Fortran 77 compiler... no checking whether accepts -g... no checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc static flag -static works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs
RE: windows build and MSYS exceptions
I'm running the build on a single CPU here so I have no idea about it being a race condition. Seems my latest build, over night, got a lot further than ever before so I'll just stick with the retry method. About the binary installer... I've been using gnucash for a number of years (on linux) and work as a developer so I've wanted to get a build version up and running. Unfortunately, I'm currently working in a windows environment so when I get a spare cycle during the day I have a go at the build. Also, by building my own copy on windows I can help test the build process and eventually test a running windows-based gnucash. Down the road, if I ever get there, there is a new features that I'd like to try to implement. My small way of contributing to a product that I rely on. Thanks, Kevin. -Original Message- From: Derek Atkins [mailto:[EMAIL PROTECTED] Sent: Thursday, April 19, 2007 8:37 AM To: Hale Boyes, Kevin Cc: gnucash-devel@gnucash.org Subject: Re: windows build and MSYS exceptions Hi, Hale Boyes, Kevin [EMAIL PROTECTED] writes: [snip] Then, if /bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I../generic-g -O2 -MT EntityManager.lo -MD -MP -MF .deps/EntityManager.Tpo -c -o EntityManager.lo EntityManager.cxx; \ then mv -f .deps/EntityManager.Tpo .deps/EntityManager.Plo; else rm -f .deps/EntityManager.Tpo; exit 1; fi 0 [main] sh 3256 open_stackdumpfile: Dumping stack trace to sh.exe.stackdump g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I../generic -g -O2 -MT EntityManager.lo -MD -MP -MF -c EntityManager.cxx -DDLL_EXPORT -DPIC -o .libs/EntityManager.o mv: cannot stat `.deps/EntityManager.Tpo': No such file or directory make[1]: *** [EntityManager.lo] Error 1 make[1]: Leaving directory `/d/gnucash-win32/tmp/OpenSP-1.5.2/lib' make: *** [all] Error 2 make: Leaving directory `/d/gnucash-win32/tmp/OpenSP-1.5.2/lib' This COULD be a race condition. On Win32 you cannot rename or unlink and open file, so sometimes if you have multiple CPUs the build can fail when the rename happens before the close(). If I restart install.sh it might fail at a different place in OpenSP or, as has previously happened, it will finish the compile and installation of this dependency and move on to the next. Then it might fail later. I've restarted the install about 5 times so far due to this problem. Yeah, when you hit this race condition, all you can really do is restart the build. I'm not sure if there's a global way to tell make to use only one thread, and even if there is I don't know if it would solve this race condition. [stack trace snipped] Huh. I have no idea what this stack trace is all about. I've never seen THAT before. MSYS-1.0.10 Build:2004-03-15 07:17 Exception: STATUS_ACCESS_VIOLATION at eip=71070C43 eax=7FFDE000 ebx= ecx= edx=0022DA08 esi= edi=0022D828 ebp=0022D3CC esp=0022D3A8 program=D:\gnucash-win32\msys\bin\sh.exe cs=001B ds=0023 es=0023 fs=003B gs= ss=0023 Stack trace: [snip] This certainly seems to be sh failing.. But I bet it's the make shell, probably as a result of the race condition. But it always seems to be a STATUS_ACCESS_VIOLATION. A look on google didn't really turn up anything, short of re-install windows, so I thought I ask here. Has anyone seen this or know what is going on? I'm afraid not. Any reason you don't just install the win32 binary installer? -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 This email communication and any files transmitted with it may contain confidential and or proprietary information and is provided for the use of the intended recipient only. Any review, retransmission or dissemination of this information by anyone other than the intended recipient is prohibited. If you receive this email in error, please contact the sender and delete this communication and any copies immediately. Thank you. http://www.encana.com ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
windows build failed
I'm running install.sh and it is consistently failing on Opensp. ### Opensp Extracting OpenSP-1.5.2.tar.gz ... done patching file `lib/Makefile.am' checking for a BSD-compatible install... /bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... no checking whether to enable maintainer-specific portions of Makefiles... no checking whether build environment is sane... yes checking for gcc... gcc checking for C compiler default output file name... a.exe checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... .exe checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking how to run the C preprocessor... gcc -E checking for g++... no checking for c++... no checking for gpp... no checking for aCC... no checking for CC... no checking for cxx... no checking for cc++... no checking for cl... no checking for FCC... no checking for KCC... no checking for RCC... no checking for xlC_r... no checking for xlC... no checking whether we are using the GNU C++ compiler... no checking whether g++ accepts -g... no checking dependency style of g++... none checking how to run the C++ preprocessor... /lib/cpp configure: error: C++ preprocessor /lib/cpp fails sanity check See `config.log' for more details. I'd include the config.log but it is long and probably not necessary. I'll just include the bits that _I_ think point to the problem. configure:3539: checking for C++ compiler version configure:3542: g++ --version /dev/null 5 ./configure: g++: command not found I guess I didn't install g++. I think that was supposed to happen during the MinGW install but I don't remember. Can I install g++ now so that the install can proceed or do I have to start over? Is it as simple as re-running the MinGW installer (manually running $GLOBAL_DIR/downloads/MinGW-5.1.0.exe)? If I may ask an unrelated question... How often are the daily IRC logs updated? Thanks for your help, Kevin. This email communication and any files transmitted with it may contain confidential and or proprietary information and is provided for the use of the intended recipient only. Any review, retransmission or dissemination of this information by anyone other than the intended recipient is prohibited. If you receive this email in error, please contact the sender and delete this communication and any copies immediately. Thank you. http://www.encana.com ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
RE: windows build failed
I was simply curious about the IRC logs. Nothing else. I'll try the g++ install. Thanks for your help, Kevin. -Original Message- From: Derek Atkins [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 18, 2007 12:12 PM To: Hale Boyes, Kevin Cc: gnucash-devel@gnucash.org Subject: Re: windows build failed Quoting Hale Boyes, Kevin [EMAIL PROTECTED]: [snip] checking for g++... no checking for c++... no checking for gpp... no checking for aCC... no checking for CC... no checking for cxx... no checking for cc++... no [snip] checking whether we are using the GNU C++ compiler... no checking whether g++ accepts -g... no checking dependency style of g++... none checking how to run the C++ preprocessor... /lib/cpp configure: error: C++ preprocessor /lib/cpp fails sanity check See `config.log' for more details. I'd include the config.log but it is long and probably not necessary. I'll just include the bits that _I_ think point to the problem. configure:3539: checking for C++ compiler version configure:3542: g++ --version /dev/null 5 ./configure: g++: command not found I guess I didn't install g++. I think that was supposed to happen during the MinGW install but I don't remember. Can I install g++ now so that the install can proceed or do I have to start over? Is it as simple as re-running the MinGW installer (manually running $GLOBAL_DIR/downloads/MinGW-5.1.0.exe)? Yep, that should work. And yes, you need to install g++. Unfortunately there's not really a good way to automate that. When you install g++ just make sure it gets installed into the right place. If I may ask an unrelated question... How often are the daily IRC logs updated? Um, should be nearly instantaneous. Why? I'm pretty sure it's just a script that runs tail -f on the logfile and outputs that into the HTML logs available online. Thanks for your help, Kevin. -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 This email communication and any files transmitted with it may contain confidential and or proprietary information and is provided for the use of the intended recipient only. Any review, retransmission or dissemination of this information by anyone other than the intended recipient is prohibited. If you receive this email in error, please contact the sender and delete this communication and any copies immediately. Thank you. http://www.encana.com ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
windows build and r15912
Maybe my scripting skill are a bit rusty but how is the new defaults/custom file loading going to work? The only value that I normally change is the GLOBAL_DIR setting. When I create the custom file, will it contain just the GLOBAL_DIR variable or do I need to copy the entire defaults file and change just the one variable? I'm guessing that I need to do the later because of all the variables that depend on the value of GLOBAL_DIR (like DOCS_DIR). They will be set before the custom file is sourced and their value won't change when I reset the value of GLOBAL_DIR. Hmm, I guess I'll have to be more careful than that. I won't want an exact copy of defaults as that would call all the add_step functions again. In an attempt to answer my own question... If I want to change the value of GLOBAL_DIR then I will put it and all the variable that depend on it into the custom file, but nothing else. It isn't enough to put just GLOBAL_DIR into custom. Is that correct? Thanks, Kevin. This email communication and any files transmitted with it may contain confidential and or proprietary information and is provided for the use of the intended recipient only. Any review, retransmission or dissemination of this information by anyone other than the intended recipient is prohibited. If you receive this email in error, please contact the sender and delete this communication and any copies immediately. Thank you. http://www.encana.com ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
RE: windows build and r15912
Great, I'll have a look when I see the commit message.
Kevin.
-Original Message-
From: Andreas Köhler [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 17, 2007 11:15 AM
To: Derek Atkins
Cc: Hale Boyes, Kevin ; gnucash-devel@gnucash.org
Subject: Re: windows build and r15912
Hi,
very good point, Kevin. Somehow I forgot about it.
Derek, that is almost exactly what I am going to implement now. The
head of defaults should explain it once I have it running and committed.
-- andi5
Derek Atkins schrieb:
Perhaps we should pull in custom.sh first, and then have
defaults.sh do something like:
[ -z ${GLOBAL_DIR:-} ] GLOBAL_DIR=default
.. and do this for all the variables to only set them if
they are not already set.
-derek
Hale Boyes, Kevin [EMAIL PROTECTED] writes:
Maybe my scripting skill are a bit rusty but how is the
new defaults/custom file loading going to work?
The only value that I normally change is the GLOBAL_DIR setting.
When I create the custom file, will it contain just the GLOBAL_DIR
variable or do I need to copy the entire defaults file and
change just the one variable?
I'm guessing that I need to do the later because of all the
variables that depend on the value of GLOBAL_DIR (like DOCS_DIR).
They will be set before the custom file is sourced and their
value won't change when I reset the value of GLOBAL_DIR.
Hmm, I guess I'll have to be more careful than that. I won't
want an exact copy of defaults as that would call all the add_step
functions again.
In an attempt to answer my own question... If I want to change the
value of GLOBAL_DIR then I will put it and all the variable that
depend on it into the custom file, but nothing else. It isn't enough
to put just GLOBAL_DIR into custom.
Is that correct?
Thanks,
Kevin.
This email communication and any files transmitted with it may contain
confidential and or proprietary information and is provided for the use of the
intended recipient only. Any review, retransmission or dissemination of this
information by anyone other than the intended recipient is prohibited. If you
receive this email in error, please contact the sender and delete this
communication and any copies immediately. Thank you.
http://www.encana.com
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
RE: windows build and r15912
This looks pretty good. I put my single override in custom and
it seems to be working well. I'm just running install.sh now
(it takes a while on my machine). The addition of the sample
custom script at the top of defaults is very helpful.
Thanks,
K.
-Original Message-
From: Andreas Köhler [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 17, 2007 1:51 PM
To: Hale Boyes, Kevin
Cc: Derek Atkins; gnucash-devel@gnucash.org
Subject: Re: windows build and r15912
Hi,
see r15918. I hope it works for you, please drop me a note about your
observations :)
-- andi5
Hale Boyes, Kevin schrieb:
Great, I'll have a look when I see the commit message.
Kevin.
-Original Message-
From: Andreas Köhler [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 17, 2007 11:15 AM
To: Derek Atkins
Cc: Hale Boyes, Kevin ; gnucash-devel@gnucash.org
Subject: Re: windows build and r15912
Hi,
very good point, Kevin. Somehow I forgot about it.
Derek, that is almost exactly what I am going to implement now. The
head of defaults should explain it once I have it running and committed.
-- andi5
Derek Atkins schrieb:
Perhaps we should pull in custom.sh first, and then have
defaults.sh do something like:
[ -z ${GLOBAL_DIR:-} ] GLOBAL_DIR=default
.. and do this for all the variables to only set them if
they are not already set.
[...]
This email communication and any files transmitted with it may contain
confidential and or proprietary information and is provided for the use of the
intended recipient only. Any review, retransmission or dissemination of this
information by anyone other than the intended recipient is prohibited. If you
receive this email in error, please contact the sender and delete this
communication and any copies immediately. Thank you.
http://www.encana.com
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
