Source directory restructuring complete

[John Ralls]

> On Aug 17, 2017, at 9:37 AM, Geert Janssens <geert.gnucash at kobaltwit.be> wrote:
> 
> On woensdag 16 augustus 2017 23:20:00 CEST John Ralls wrote:
>>> On Aug 16, 2017, at 11:12 PM, Aaron Laws <dartme18 at gmail.com> wrote:
>>> 
>>> On Wed, Aug 16, 2017 at 4:52 PM, John Ralls <jralls at ceridwen.fremont.ca.us
>>> <mailto:jralls at ceridwen.fremont.ca.us>>> 
>>> wrote:
>>>> Later, when trying to run GnuCash I found that
>>>> libgncmod-backend-dbi.dylib
>>>> didn't load because the directory being passed in was "dbi" instead of
>>>> "gnucash".
>>>> --- a/libgnucash/engine/gnc-engine.c
>>>> +++ b/libgnucash/engine/gnc-engine.c
>>>> @@ -74,9 +74,9 @@ gnc_engine_init_part2()
>>>> 
>>>>    } libs[] =
>>>>    {
>>>> 
>>>> #if defined( HAVE_DBI_DBI_H )
>>>> -        { "dbi", "gncmod-backend-dbi", TRUE },
>>>> +        { "gnucash", "gncmod-backend-dbi", TRUE },
>>>> #endif
>>>> -        { "xml", "gncmod-backend-xml", TRUE },
>>>> +        { "gnucash", "gncmod-backend-xml", TRUE },
>>>> 
>>>>        { NULL, FALSE }
>>>> 
>>>>    }, *lib;
>>>> 
>>>> fixes the problem and I think it will affect only Mac builds, but can
>>>> someone check it on Linux to make sure before I commit it?
>>>> 
>>>> Regards,
>>>> John Ralls
>>> 
>>> This looks fine on Arch Linux building from scratch using cmake and ninja
>>> check.
>> 
>> Cool, Thanks.
>> 
> This puzzles me.
> 
> The relative directory being passed in is normally only used for an autotools 
> based build. For cmake based builds the path is automatically set to $
> {builddir}/lib/gnucash on anything but Windows, where it becomes ${builddir}/
> bin. The directory passed in should be ignored in case of a cmake based build.
> (See libgnucash/engine/qof-backend.cpp:96, function get_default_module_dir)
> 
> ISTR you are building with cmake/ninja, so how is is possible your builds are 
> affected by this relative directory ? Is your environment not setting 
> CMAKE_BUILD or is #ifdef CMAKE_BUILD false on your system ? A gcc vs clang 
> thing perhaps ?
> 
> As far as I can see I'm using the same tests and conditions as were used 
> before in gnc-engine, that's why I'm so surprised as it worked before. For a 
> comparison, the change happened in commit
> https://github.com/Gnucash/gnucash/commit/708a9a47756fb7 <https://github.com/Gnucash/gnucash/commit/708a9a47756fb7>
> 
> In any case the above change is effectively breaking the autotools build on 
> linux so we need to look further.

Nope, the problem is at https://github.com/Gnucash/gnucash/blob/master/libgnucash/engine/qof-backend.cpp#L141: <https://github.com/Gnucash/gnucash/blob/master/libgnucash/engine/qof-backend.cpp#L141:>
/* Darwin modules can have either .so or .dylib for a suffix */
    if (!g_file_test (fullpath, G_FILE_TEST_EXISTS) &&
        g_strcmp0 (G_MODULE_SUFFIX, "so") == 0)
    {
        auto modname = g_strdup_printf ("lib%s.dylib", module_name);
        g_free (fullpath);
        fullpath = g_build_filename (directory, modname, NULL);
        g_free (modname);
    }
    auto backend = g_module_open (fullpath, G_MODULE_BIND_LAZY);

follpath was "dbi/libgncmod-backend-dbi.dylib which exists only in an autotools build and only before installation. Having directory="gnucash" is correct after installation and always in a Cmake build. This will probably break tests on an autotools build on Macs. I may decide I don't care and that only CMake is supported there.

Regards,
John Ralls