Re: [Bug-apl] SVN 839 doesn't compile

[Juergen Sauermann]

Hi,

in principle you can load shared libraries already via the native function interface (which is a wrapper
around dlopen() and friends). A somewhat cleaner way would be to have some new ⎕SQL function
numbers for loading shared libraries. A ⎕SQL function number for listing the existing SQL providers
would also be useful.

A possible disadvantage is that your workspaces become less portable. We already had problems with
)SAVEd workspaces (but not with )DUMPed workspaces) that contained native functions. One of the
reasons why I made ⎕SQL a system function was that I wanted to reduce the number of native functions
in order to reduce the number of possible problems related to )SAVEd workspaces. There are also
other problems (like versioning, providing the shared libraries for different platforms, Microsoft Windows,
etc.) related to dynamically loaded code.

In summary, I would say that dynamically loading SQL providers is feasible (and I would not generally object
to including it into GNU APL if somebody implements it), but the advantage for the user is relatively small (it saves a
one-time recompile of GNU APL after a new SQL provider was added to a machine) and will almost certainly
create quite a few problems.

/// Jürgen

On 01/12/2017 01:11 PM, Elias Mårtenson wrote:

I think we need a way to dynamically load SQL libraries. Otherwise we're going to either have precompiled binaries without SQL support, or the need to have multiple packages.

If we support dynamically loading the SQL libraries, then the Debian package could be built with support for both backends, but there would be no need to actually depends on them for running GNU APL.

Regards,

Elias

On 12 January 2017 at 19:50, Juergen Sauermann <address@hidden> wrote:

Hi Hacper,

thanks, fixed in SVN 847. I moved the -I sql out of the conditionals because ⎕SQL needs them
even if no SQL provider like sqlite or postgresql was detected.

libsql3 -dev is not in debian/control because GNU APL should also build without any SQL provider.

/// Jürgen

On 01/12/2017 02:20 AM, Kacper Gutowski wrote:

Actually, I have observed the same thing on a clean checkout.
The -I sql part ends up being commented out in generated Makefile
if configure fails to detect sqlite3 but these includes aren't
guarded with appropriate ifdef.

As a side note, libsqlite3-dev isn't mentioned in debian/control.

-k