Well, it's not really "a functional library": it's missing functionality that requires Cocoa, namely:

 - the settings backend
 - the notification backend

The former does not require 10.9, but the latter does. Neither is *required* functionality, but applications using that API will have issues.

Of course. But making configure fail and library unable to build because some non-required functionality cannot be enabled is a little bit overkill IMHO.

By "functional" I mean testsuite *mostly* passes (there are some FAILs, but they have been always there, even on previous versions, and anyways I am looking into them also, trying to clean-up OS X ppc port).

(In reply to Carlos Sánchez de La Lama from comment #2)
> Of course. But making configure fail and library unable to build because
> some non-required functionality cannot be enabled is a little bit overkill
> IMHO.

It depends on what you define "required functionality". If an application is not using either then it's fine; if, on the other hand, and application is using settings and/or notifications, then it suddenly becomes quite necessary.

> By "functional" I mean testsuite *mostly* passes (there are some FAILs, but
> they have been always there, even on previous versions, and anyways I am
> looking into them also, trying to clean-up OS X ppc port).

The testsuite is a constrained environment; it's good that it passes, but it's not an indication of *actual* functionality.

> It depends on what you define "required functionality". If an application is
> not using either then it's fine; if, on the other hand, and application is
> using settings and/or notifications, then it suddenly becomes quite
> necessary.

I completely agree. However, given many supported platforms lack Cocoa (as it is an OS X-only thing), I think it is unlikely a *required* functionality relies on it. Other settings and notification backends can be compiled on OS X as well, not only Cocoa-based ones. It is not that disabling Cocoa stripes-out some part of the API, just disables those backends.

However, I might be wrong. I am not developing with glib/GIO, just trying to get it to properly build on my platform as some other package requires it.

(In reply to Carlos Sánchez de La Lama from comment #4)
> > It depends on what you define "required functionality". If an application is
> > not using either then it's fine; if, on the other hand, and application is
> > using settings and/or notifications, then it suddenly becomes quite
> > necessary.
> 
> I completely agree. However, given many supported platforms lack Cocoa (as
> it is an OS X-only thing), I think it is unlikely a *required* functionality
> relies on it.

Required functionality for applications, not required functionality for the test suite. We have API; this API is implemented on different platforms; the underlying implementation has requirements. By disabling Cocoa support you just build dummy code that has no actual functionality — i.e. the API contract may be satisfied, but the end result is not functional.

The test suite uses the GSettings memory backend, which, while perfectly fine for the testing, is patently useless to store actual user settings. You'd have to explicitly select *another* settings backend — like the key/value files one — which requires additional code on the application's side.

The notification system is a bit less problematic — except we don't really have feature discovery for it; you can add notifications to your application, and they simply won't ever fire — assuming the code inside GApplication doesn't simply crash because there's not GNotificationBackend instance.

> Other settings and notification backends can be compiled on OS
> X as well, not only Cocoa-based ones. It is not that disabling Cocoa
> stripes-out some part of the API, just disables those backends.

Yes, thus making the API that depends on those backends not really useful on MacOS. An application will compile, but it will fail to do something useful.

> Yes, thus making the API that depends on those backends not really useful on
> MacOS. An application will compile, but it will fail to do something useful.

Even *if* that was the case, I still believe allowing the library to build would be better. You will be able to build applications that used all the remaining parts of the API; i.e. you will not break anything that was not already broken, and would fix many cases that were.

But that is not even the case: the API will not be useless. For notifications, you could use Gtk+ backend. Of the GLib supported platforms listed on

https://wiki.gnome.org/Projects/GLib/SupportedPlatforms

only "Mac OS" has Cocoa, disabling Cocoa on Mac OS < 10.9 just allows those systems to use same backeds than, for example, a Linux system.

Looking at the code, I see only "null", "memory" and "nextstep" settings backends (the last one being the Cocoa one). What is the usual settings backend on a Linux system, then?

(In reply to Carlos Sánchez de La Lama from comment #6)
> > Yes, thus making the API that depends on those backends not really useful on
> > MacOS. An application will compile, but it will fail to do something useful.
> 
> Even *if* that was the case, I still believe allowing the library to build
> would be better. You will be able to build applications that used all the
> remaining parts of the API; i.e. you will not break anything that was not
> already broken, and would fix many cases that were.

If an application is not using the newer API, it can also bundle its own copy of GLib.

> But that is not even the case: the API will not be useless. For
> notifications, you could use Gtk+ backend.

What GTK backend? There is no "GTK backend": GTK depends on whatever backend GIO provides. On Linux, it uses DBus with two potential DBus interfaces discovered at run time. This does not work anywhere else.

> Of the GLib supported platforms listed on
> 
> https://wiki.gnome.org/Projects/GLib/SupportedPlatforms
> 
> only "Mac OS" has Cocoa, disabling Cocoa on Mac OS < 10.9 just allows those
> systems to use same backeds than, for example, a Linux system.

No, it does not.

> Looking at the code, I see only "null", "memory" and "nextstep" settings
> backends (the last one being the Cocoa one). What is the usual settings
> backend on a Linux system, then?

On Linux, you have dconf, which is implemented as an out of tree module because of circular dependencies — that's why both the GSettings and the GNotification backends are implemented as GIO extension points.

> > Even *if* that was the case, I still believe allowing the library to build
> > would be better. You will be able to build applications that used all the
> > remaining parts of the API; i.e. you will not break anything that was not
> > already broken, and would fix many cases that were.
> 
> If an application is not using the newer API, it can also bundle its own
> copy of GLib.

True. The problem with this approach is if for some reason there were bugs in previous versions, those applications could never get them fixed. I would prefer not "forcing" a build failure in the configure; we are not talking about binary packages here. But I agree it is a matter of opinion, and of course it is not my call.

> > But that is not even the case: the API will not be useless. For
> > notifications, you could use Gtk+ backend.
> 
> What GTK backend? There is no "GTK backend": GTK depends on whatever backend
> GIO provides. On Linux, it uses DBus with two potential DBus interfaces
> discovered at run time. This does not work anywhere else.

I see. If dbus is only supported on Linux (and BSDs, I guess) and there is no way to have it working on OS X, then I get your point now.

Thanks for the patience :)

In MacPorts, we are patching glib to remove the gcocoanotification backend, when building on OS X < 10.9. MacPorts is not ready to require 10.9 as a minimum OS version. (Heck, we still run on 10.4.)

This was actually fixed in bug #747146 by disabling notification support on OS X < 10.9. I don’t want to go changing that code again, so let’s leave this to rest.

*** This bug has been marked as a duplicate of bug 747146 ***