GNOME Bugzilla – Bug 612604
make results change depending on previous builds -- possibly related to guile-strings.c
Last modified: 2018-06-29 22:36:47 UTC
* Build a known "good" version using a build directory * Confirm that it is "good" * Check out another version, known to be "bad" * Using the same build directory * configure * make clean * make * make install * "bad" version does not exhibit "bad" behavior (NOT expected) * Create a new build directory * configure * make clean * make * make install * "bad" version is "bad" (as expected)
Need MUCH more information here, but I'll just point out that some things (like SWIG) are NOT rerun at every build.. So unless you perform a "maintainer-clean" between runs it's possible that you're using old stale build state. "make clean" is not sufficient.
Git archive for testing at http://wildside.wagsky.com/gnucash/bug-612604/minimal-git-archive.tbz Archive contains two versions, based on SVN r18877 The versions have been tagged * edd8b26 * df0f85d to correspond with emails to the gnucash-devel mailing list. The tag edd8b26, when built, should result in a version that will render the splash screen and the basic UI, for $ /path/to/gnucash --nofile The tag df0f85d, when built in a clean build directory, should "break" with Backtrace: In current input: 1: 0* (set! OPTION-SECTION-ACCOUNTS (OPTION-SECTION-ACCOUNTS)) <unnamed port>:1:1: In expression (set! OPTION-SECTION-ACCOUNTS (OPTION-SECTION-ACCOUNTS)): <unnamed port>:1:1: Unbound variable: OPTION-SECTION-ACCOUNTS However, if edd8b26 is built, then df0f85d is built, the df0f85d result does not exhibit the failure. If df0f85d is built in an empty directory, off the exact same source directory, it fails (as expected). http://wildside.wagsky.com/gnucash/bug-612604/dpkg-l.2010-03-11 contains the output of $dpkg -l which identifies the components of the Ubuntu 9.10 build environment. Linux fx 2.6.31-20-generic #57-Ubuntu SMP Mon Feb 8 09:05:19 UTC 2010 i686 GNU/Linux http://wildside.wagsky.com/gnucash/bug-612604/show-gnucash-build-problems-annotated.log.bz2 is the output of 'script' demonstrating all three cases Hand-edited out of the script are the steps: # create a directory and extract the archive ~ $ mkdir minimal-git-archive ~ $ cd minimal-git-archive/ ~/minimal-git-archive $ tar xf /var/tmp/minimal-git-archive.tbz # checkout edd8b26, autogen ~/minimal-git-archive $ git checkout edd8b26 ~/minimal-git-archive $ mkdir ../build1 ~/minimal-git-archive $ ./autogen.sh ~/minimal-git-archive $ cd ../build1 # configure, make, make install, try it (succeeds, as expected) ~/build1 $ ../minimal-git-archive/configure --enable-ofx --enable-aqbanking --prefix=/opt/gnucash --with-html-engine=webkit ~/build1 $ make ~/build1 $ make install ~/build1 $ /opt/gnucash/bin/gnucash --nofile # checkout df0f85d ~/build1 $ cd ../minimal-git-archive/ ~/minimal-git-archive $ git checkout df0f85d ~/minimal-git-archive $ cd ../build1 # configure, make clean, make, make install, try it (succeeds, which is "wrong") ~/build1 $ ../minimal-git-archive/configure --enable-ofx --enable-aqbanking --prefix=/opt/gnucash --with-html-engine=webkit ~/build1 $ make clean ~/build1 $ make ~/build1 $ make install ~/build1 $ /opt/gnucash/bin/gnucash --nofile # Create a fresh build directory and re-try with same source # try it and it "properly fails" ~/build1 $ mkdir ../build2 ~/build1 $ cd ../build2 ~/build2 $ ../minimal-git-archive/configure --enable-ofx --enable-aqbanking --prefix=/opt/gnucash --with-html-engine=webkit ~/build2 $ make ~/build2 $ make install ~/build2 $ /opt/gnucash/bin/gnucash --nofile
jeff@fx:~/minimal-git-archive$ git diff edd8b26 df0f85d | cat diff --git a/src/libqof/qof/qofbookslots.h b/src/libqof/qof/qofbookslots.h index d01d10b..93287eb 100644 --- a/src/libqof/qof/qofbookslots.h +++ b/src/libqof/qof/qofbookslots.h @@ -19,6 +19,8 @@ * * \********************************************************************/ +#include <glib/gi18n.h> + /** @name Book parameter names * These define the names used for the slots used to store book level parameters. @@ -26,8 +28,44 @@ * Scheme code too. @{ */ -#define KVP_OPTION_PATH "options" -#define OPTION_SECTION_ACCOUNTS "Accounts" -#define OPTION_NAME_TRADING_ACCOUNTS "Trading Accounts" + + +/* + * See also SET_ENUM() in src/engine/engine.i + * + * SOME_DEFINED_NAME gets mapped into SOME-DEFINED-NAME by SWIG + * http://www.swig.org/Doc1.3/Guile.html#Guile_nn10 + */ + + +/* + * gnc:*kvp-option-path* is used to refer to the kvp frame + * in which book-level options are stored. + * It is tied to C in + * src/app-utils/app-utils.scm + * and is extensively used in + * src/app-utils/option-util.c + * src/gnome-utils/gnome-utils.scm + * src/business/business-reports/ + */ + +#define KVP_OPTION_PATH "options" + +/* + * Various option sections and options within those sections + * + * At least through 2.3.10, the key and the display string are tied, + * coupling the data with its representation in the UI + * and is not locale-independent (translated strings used as keys) + */ + +#define OPTION_SECTION_ACCOUNTS _("Accounts") +#define OPTION_NAME_TRADING_ACCOUNTS _("Trading Accounts") /** @} */ + +/* For the grep-happy: + * KVP-OPTION-PATH + * OPTION-SECTION-ACCOUNTS + * OPTION-NAME-TRADING-ACCOUNTS + */
If it is SWIG (or the like) not being run, would prefer a way to perform incremental make, perhaps with an option to make invocation.
Appears to be SWIG-related $ find ../minimal-git-archive/ -name '*.i' -exec touch '{}' \; is a work-around, though not a pretty one, as it modifies the source directory. Considering how to have make always run swig if a variable is set (and swig exists). Something along the lines of $ make -DGNC_FORCE_SWIG
As I said, "make maintainer-clean" is the official answer. SWIG is something that's only used by maintainers. It's not used within the tarball; the swig files are generated during dist and not rebuilt later. Building proper dependencies for swig would be.. challenging. I dont think there's a parser that will automatically compute them. Running it on every build would be overkill and cause too much rebuilding. So basically if you're moving stuff around in headers then you can force a swig recompile by, as you did, touching the .i files or running "maintainer-clean". Between SVN updates you should almost ALWAYS run maintainer-clean. Therefore, I am closing this as "not a bug" because there are already ways to do it; you're just not following guidelines (even though I admit that guideline might not be written anywhere in the SVN tree -- a patch to fix that would be accepted)
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=612604. Please update any external references or bookmarks.