bug#49660: 28.0.50; json-available-p should exist

bug#49660: 28.0.50; json-available-p should exist

[Lars Ingebrigtsen]

All other libraries like this have an -available-p function, but not
json.c.

But json.c is slightly unusual in that it's not compiled at all if
jansson isn't available, so the function will have to go somewhere else,
which is rather, er, inconvenient.

Anybody have an idea how to solve that problem?


In GNU Emacs 28.0.50 (build 93, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0)
 of 2021-07-19 built on elva
Repository revision: b0c73439932eefb8302ec10c61d95ffcf2ef39be
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Debian GNU/Linux 11 (bullseye)


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#49660: 28.0.50; json-available-p should exist

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Tue, 20 Jul 2021 14:53:00 +0200
> 
> 
> All other libraries like this have an -available-p function, but not
> json.c.
> 
> But json.c is slightly unusual in that it's not compiled at all if
> jansson isn't available, so the function will have to go somewhere else,
> which is rather, er, inconvenient.
> 
> Anybody have an idea how to solve that problem?

Compile json.c always, but have a HAVE_LIBJANSSON preprocessor symbol
that would effectively ifdef away all of json.c except that single
function (and syms_of_json).

bug#49660: 28.0.50; json-available-p should exist

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Compile json.c always, but have a HAVE_LIBJANSSON preprocessor symbol
> that would effectively ifdef away all of json.c except that single
> function (and syms_of_json).

Yeah, I guess there's really no other cleanish way to do this?  And it's
the pattern we follow in all the other library-specific src/*.c files, I
think...

So unless somebody protests (or beats me to it), I'll do this in a few
days.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#49660: 28.0.50; json-available-p should exist

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Yeah, I guess there's really no other cleanish way to do this? 

Oh, I thought of a simple hack: We could define json-available-p in
json.c, but we could also have (say) loadup.el check whether it's
defined, and if not, it can define a nil-returning stub?  That'll mean a
whole lot less #ifdef-ing in json.c.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#49660: 28.0.50; json-available-p should exist

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 49660@debbugs.gnu.org
> Date: Tue, 20 Jul 2021 16:47:13 +0200
> 
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
> > Yeah, I guess there's really no other cleanish way to do this? 
> 
> Oh, I thought of a simple hack: We could define json-available-p in
> json.c, but we could also have (say) loadup.el check whether it's
> defined, and if not, it can define a nil-returning stub?  That'll mean a
> whole lot less #ifdef-ing in json.c.

If you are ready to define json-available-p somewhere other than
json.c, then you could simply do that in subr.el or somesuch.  It
would be cleaner than defining stubs in loadup.el.

bug#49660: 28.0.50; json-available-p should exist

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> If you are ready to define json-available-p somewhere other than
> json.c, then you could simply do that in subr.el or somesuch.  It
> would be cleaner than defining stubs in loadup.el.

The meats of json-available-p have to be in json.c, though?  (It has to
call init_json_functions (on Windows) to see whether we have the DLL or
not.)

We could have a json--available-p in json.c that does that, but it
doesn't seem less hackey...  but I guess it doesn't really matter
much -- neither solution is super clean.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#49660: 28.0.50; json-available-p should exist

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 49660@debbugs.gnu.org
> Date: Tue, 20 Jul 2021 17:50:17 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > If you are ready to define json-available-p somewhere other than
> > json.c, then you could simply do that in subr.el or somesuch.  It
> > would be cleaner than defining stubs in loadup.el.
> 
> The meats of json-available-p have to be in json.c, though?

No, it doesn't have to.  You could have json-available-p that simply
tested one of json.c primitives to be fboundp, and if so, tried to
invoke one of them on a trivial input to see if it signals an error.

Alternatively, we could do this like decompress.c does: it would
require the test for availability to be slightly more complex:

  (and (fboundp 'json-available-p)
       (json-available-p))

Would that be good enough?

bug#49660: 28.0.50; json-available-p should exist

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> No, it doesn't have to.  You could have json-available-p that simply
> tested one of json.c primitives to be fboundp, and if so, tried to
> invoke one of them on a trivial input to see if it signals an error.

That's true -- especially since they now signal a distinct error when
the library isn't available.  Pushed to Emacs 28 now.

> Alternatively, we could do this like decompress.c does: it would
> require the test for availability to be slightly more complex:
>
>   (and (fboundp 'json-available-p)
>        (json-available-p))
>
> Would that be good enough?

No, I think the -available-p predicates should always be defined.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no