Unable to make dist after recent changes

[John Ralls]

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.

Regards,
John Ralls