GNOME Bugzilla – Bug 731313
gutils.c uses deprecated FSFindFolder
Last modified: 2018-05-24 16:37:17 UTC
Building glib-2.38.2 on OS X 10.8 (using -arch x86_64 to force a single architecture)... CC libglib_2_0_la-gutils.lo gutils.c:1424:7: warning: 'FSFindFolder' is deprecated: first deprecated in OS X 10.8 [-Wdeprecated-declarations] if (FSFindFolder (kUserDomain, type, kDontCreateFolder, &found) == noErr) ^ /System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/Folders.h:286:1: note: 'FSFindFolder' declared here FSFindFolder( ^ 1 warning generated. The code itself is inside an #ifdef HAVE_CARBON block. I thought carbon itself was deprecated or not really functional on 64-bit? So maybe the "real" bug is in HAVE_CARBON being a "presence" vs "viability" test of some sort?
The Foundation framework has NSFileManager, with NSSearchPathDirectory tokens analogous to all the FSFindFolder tokens passed in the HAVE_CARBON implementation of load_user_special_dirs() as of OS X 10.6 or earlier. There's already a HAVE_COCOA autoconf token that tests for that framework, so it would be easy (conceptually) to write and use a cocoa implementation of load_user_special_dirs in that case and then fall back to using the carbon if cocoa wasn't available. Is OS X "10.5 or below" still a relevant target platform? If so, would need to check all the NSFileManager tokens (or at least the last one to be made available) rather than just for cocoa itself.
Fixing Bug #731424 will make this easier to implement and maintain going forward.
There are still people who are using GLib with Mac OS 10.5 (due to owning PPC hardware) but I don't consider supporting such old versions to be something that we should be concerned about if we can simplify the code by depending on newer APIs. Most people using such older versions are using GLib via something like macports and can patch as necessary anyway. If you want to depend on the newer API then I'm happy to look at a patch. Would we still be using the C API or would this be Objective C code?
I had initially found NSSearchPathForDirectoriesInDomains, which is ObjC, and it seemed to work. That would mean either offloading this functionality into a new .m source file (I tested that current autoconf/automake/libtool2 does support the correct compiling/linking for that). I see a different approach in gio/Makefile.am (_CFLAGS+=-xobjective-c) to have a .c compile as ObjC...nobody on IRC a few days ago could remember exactly why that magic was needed. It's also probably doable in C via NSGetNextSearchPathEnumeration, which I also got to work. However, this API returns user directories named as "~" to mean homedir (~/Desktop, etc.), whereas the existing carbon API and the ObjC I tried return absolute paths (/Users/dmacks/Desktop, etc.). Is the use of tilde acceptable in this context? If not and want to remain in C, would have to expand it using GFile (is it allowed to have glib use gio, even though gio sits on top of glib in the linking stack?) or wordexp().
bug 672777 comment 13 says "iirc, we didn't call this ".m" because it caused all kinds of issues for automake to have an optionally-included objective C file"
Created attachment 279168 [details] configure.ac fragment: Test for sufficient support in new C API The various folders are specified with an enum list that was gradually extended over several OS X releases (some of the needed ones not added until 10.5 or 10.6). This tests for the availability of the highest one (by enum value) that is needed.
Created attachment 279169 [details] NS-pathreader.c: demonstration of modern C API This load_user_special_dirs() and find_folder() would go early in glib/gutils.c, and the #warning fallback would actually be the next implementation of those (HAVE_CARBON) in that glib source. Build with a simple Makefile.am: ACLOCAL_AMFLAGS = -I m4 bin_PROGRAMS = NS-pathreader NS_pathreader_SOURCES = NS-pathreader.c NS_pathreader_CPPFLAGS = $(GLIB_CFLAGS) NS_pathreader_LDFLAGS = $(GLIB_LIBS) and the previous comment's configure.ac.
(In reply to comment #5) > bug 672777 comment 13 says "iirc, we didn't call this ".m" because it caused > all kinds of issues for automake to have an optionally-included objective C > file" Aw heck, I'm even on the CC list of that bug and couldn't find it. Could you put a link to it in the comment in gio/Makefile.am? Not that I *don't* agree with the current comment there "This is dumb.", but some technical info for tracking the dumbness would be useful:)
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/885.