Unable to make dist after recent changes

[Geert Janssens]

On donderdag 1 december 2011, John Ralls wrote:
> On Dec 1, 2011, at 1:56 PM, Geert Janssens wrote:
> > On donderdag 1 december 2011, John Ralls wrote:
> >> On Nov 30, 2011, at 5:05 PM, John Ralls wrote:
> >>> On Nov 30, 2011, at 8:44 AM, Derek Atkins wrote:
> >>>> John Ralls <jralls at ceridwen.us> writes:
> >>>>> I've just committed the requisite fixes, and distcheck now works on
> >>>>> my Mac. But there's an older problem that causes make check to fail
> >>>>> on Debian Squeeze and Fedora 12 if Gnucash hasn't been installed.
> >>>>> Since distcheck does exactly that, it fails too. I'm bisecting to
> >>>>> try and figure out what is the quick fix (after banging on it for
> >>>>> three days *didn't* solve the problem).
> >>>>> 
> >>>>> The actual problem is the way we retrieve some modules, using
> >>>>> gnc_path_get_stdreportdir() (for standard reports) and
> >>>>> gnc_path_get_pkglibdir() (for the engine backends). Neither of those
> >>>>> as written will work with uninstalled libraries, so the tests
> >>>>> fail. But that change went in early last year, and the tests didn't
> >>>>> start failing until a changeset from some time this spring.
> >>>> 
> >>>> Perhaps the TEST_ENVIRONMENT is not set correctly to point to the
> >>>> correct build directories?
> >>> 
> >>> No, the path utilities don't pay any attention to the environment. I'm
> >>> working on changing that.
> >> 
> >> In fact, it looks like the report tests broke when Geert *fixed* the
> >> test environments, because it wasn't actually trying to run the tests,
> >> just giving up and passing because it couldn't find the modules. Geert
> >> didn't see the error, of course, because he had run "make install" at
> >> some point, so the test was able to find the reports and the backends.
> > 
> > Interesting, so my fixes actually revealed a bug in the module testing
> > code.
> > 
> > If I find some time, I will run this experiment on Fedora 15 as well and
> > see what happens.
> > 
> > There was a part in the test Makefiles I wasn't sure about that may be
> > related: the GNC_TEST_DEPS contains a number --library-dir lines. Should
> > these point to all build directories with required modules ? I thought
> > this was superfluous because the module loading code adds all
> > gnc-module-dir paths to LD_LIBRARY_PATH already. But I haven't looked
> > into this in much detail.
> 
> That might be an OSX adaptation, where LD_LIBRARY_PATH is for finding
> loadable modules (i.e., dlopen()) and DYLD_LIBRARY_PATH is for finding
> shared libraries. Without the --library-dir lines, OSX can't find the
> shared libraries needed by the modules, so they don't load.
> 
> Having written the fix for loading the backends, I'm working through the
> tests getting everything that was barfing for being unable to load modules
> and passing anyway to pass correctly. After I've got everything working
> for the engine problem, I'll get the standard-report problem, and then go
> look for other things that have the problem. One issue is that failing to
> load a module at most prints an error message but still allows the test to
> pass. We need exceptions... :-(
> 
> On that vein, I'd really like to get to the bottom of the duplicate symbols
> in sw_engine and gnucash engine spew, but what sw_engine is and where it
> comes from eludes me.
> 
Yes, I hit that one too and intially removed the duplicate symbols in the 
engine.i file. With that change the tests work fine, but reports crash. So I 
reverted that part of the patch in r21589 and Mike Evans reverted the 
equivalent change for sw_app_utils in r21625. I haven't had time since to look 
into this again.

I did more or less figure out at that time what sw_engine is. The way I 
understand it currently is that sw_engine is the guile interface to the swig 
generated engine wrapper. It is a (quile) module that gets created by swig 
based on the engine.i file. Everything you define in engine.i will end up 
being exported via module sw_engine (I guess).

The warnings all deal with symbols that are wrapped in engine.i (they come 
from gnc-engine.h which is %included in engine.i) and are also exported in 
engine.scm.

For some reason the tests consider this a duplicate symbol definition, but the 
reports require the export statements or will fail to work. That's as far as I 
got. I don't know why this is though, because at first sight, the sw_engine 
module is loaded by default when gncmod_engine is loaded (see gncmod-
engine.c). And yet the tests complain about duplicate symbols, while the main 
program doesn't.

Geert