GNOME Bugzilla – Bug 796214
Meson: Cocoa detection doesn't work
Last modified: 2018-05-24 20:34:09 UTC
When building for macosX10, the check for cocoa support fails: Command line: clang -I/Users/collabora/xclaesse/cerbero/build/dist/darwin_x86_64/include /var/folders/z9/c62vstj127n2r09wzzllvll40000gn/T/tmpjl65w000/testfile.c -pipe -c -o /var/folders/z9/c62vstj127n2r09wzzllvll40000gn/T/tmpjl65w000/output.obj -Wall -g -O2 -arch x86_64 -m64 -Wno-error=format-nonliteral -mmacosx-version-min=10.10 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk -DHAVE_STRNDUP -Wall -g -O2 -arch x86_64 -m64 -Wno-error=format-nonliteral -mmacosx-version-min=10.10 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk -O0 -std=gnu89 Code: #include <Cocoa/Cocoa.h> #ifdef GNUSTEP_BASE_VERSION #error "Detected GNUstep, not Cocoa" #endif Compiler stdout: Compiler stderr: In file included from /var/folders/z9/c62vstj127n2r09wzzllvll40000gn/T/tmpjl65w000/testfile.c:1: In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12: In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:8: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSObjCRuntime.h:503:1: error: expected identifier or '(' @class NSString, Protocol; ^
Created attachment 372165 [details] [review] Meson: Fix cocoa and carbon support - Compiler checks were failing because it were using C compiler to build objc code. - xdgmime is needed on osx too. - -DGIO_COMPILATION must be passed to objc compiler too. - gapplication doesn't build on osx, it is excluded in autotools too. We have to be careful when we use add_project_link_arguments(): All targets are builtusing link arguments for the C language, except for libgio on osx which use the objc language, because it contains some ".m" source files. See https://github.com/mesonbuild/meson/issues/3585.
This patch depends on bug #672777 first, because objc source files must be renamed to .m otherwise meson tries to build them with the C compiler.
Review of attachment 372165 [details] [review]: Note: I realise it’s not something you’ve touched in this bug, but it’s related: there’s a FIXME in gio/meson.build about gnextstepsettingsbackend.c which needs fixing. Also, gosxappinfo.h isn’t listed at all in gio/meson.build. ::: gio/meson.build @@ +421,3 @@ + subdir('xdgmime') + internal_deps += [xdgmime_lib] gio/Makefile.am has this conditional on OS_UNIX. I don’t think we want to build xdgmime on Windows. ::: meson.build @@ +605,3 @@ + # Mac OS X Carbon support + glib_have_carbon = objcc.compiles('''#include <Carbon/Carbon.h> + #include <CoreServices/CoreServices.h>''', Nitpick: Indentation inside the ''' is a bit off. I think it would be nicer to line up the `#include`s. @@ +614,3 @@ + #if MAC_OS_X_VERSION_MIN_REQUIRED < 1090 + #error Compiling for minimum OS X version before 10.9 + #endif''', name : 'OS X 9 or later') Nitpick: Same here. Also, put the `name` on its own line. (I realise it was like this before, but let’s improve the formatting while you’re touching it.) @@ +621,3 @@ + #ifdef GNUSTEP_BASE_VERSION + #error "Detected GNUstep, not Cocoa" + #endif''', Nitpick: Same here. @@ +631,3 @@ + # libgio mix C and objC source files and there is no way to reliably know + # which language flags it's going to use to link. Add to both languages for + # now. See https://github.com/mesonbuild/meson/issues/3585. This comment should include the word `FIXME` so we can grep for it later and, ideally, improve things once #3585 is fixed.
Created attachment 372192 [details] [review] Meson: Fix cocoa and carbon support - Compiler checks were failing because it were using C compiler to build objc code. - xdgmime is needed on osx too. - -DGIO_COMPILATION must be passed to objc compiler too. - gapplication doesn't build on osx, it is excluded in autotools too. We have to be careful when we use add_project_link_arguments(): All targets are built using link arguments for the C language, except for libgio on osx which use the objc language, because it contains some ".m" source files. See https://github.com/mesonbuild/meson/issues/3585.
(In reply to Philip Withnall from comment #3) > Review of attachment 372165 [details] [review] [review]: > > Note: I realise it’s not something you’ve touched in this bug, but it’s > related: there’s a FIXME in gio/meson.build about gnextstepsettingsbackend.c > which needs fixing. oh, didn't split my commits correctly, the FIXME is removed in the patch on bug #672777. Fixed now. > Also, gosxappinfo.h isn’t listed at all in gio/meson.build. None of the not-installed headers are listed because it's not needed. The compiler tells ninja the list of headers needed to build a source file and it uses that to know when to rebuild. > ::: gio/meson.build > @@ +421,3 @@ > > + subdir('xdgmime') > + internal_deps += [xdgmime_lib] > > gio/Makefile.am has this conditional on OS_UNIX. I don’t think we want to > build xdgmime on Windows. It moves it to the "if host_system != 'windows'" block, previously it was in the else block of "if glib_have_cocoa". Exactly the same as in Makefile.am.
Created attachment 372194 [details] [review] Meson: Fix cocoa and carbon support - Compiler checks were failing because it were using C compiler to build objc code. - xdgmime is needed on osx too. - -DGIO_COMPILATION must be passed to objc compiler too. - gapplication doesn't build on osx, it is excluded in autotools too. We have to be careful when we use add_project_link_arguments(): All targets are built using link arguments for the C language, except for libgio on osx which use the objc language, because it contains some ".m" source files. See https://github.com/mesonbuild/meson/issues/3585.
(In reply to Xavier Claessens from comment #5) > (In reply to Philip Withnall from comment #3) > > Review of attachment 372165 [details] [review] [review] [review]: > > > > Note: I realise it’s not something you’ve touched in this bug, but it’s > > related: there’s a FIXME in gio/meson.build about gnextstepsettingsbackend.c > > which needs fixing. > > oh, didn't split my commits correctly, the FIXME is removed in the patch on > bug #672777. Fixed now. Actually, no, that FIXME is rightfully removed in the other commit, because it's that commit that adds gnextstepsettingsbackend.m in the right place at the same time as renaming it from .c.
(In reply to Xavier Claessens from comment #5) > (In reply to Philip Withnall from comment #3) > > Review of attachment 372165 [details] [review] [review] [review]: > > > > Note: I realise it’s not something you’ve touched in this bug, but it’s > > related: there’s a FIXME in gio/meson.build about gnextstepsettingsbackend.c > > which needs fixing. > > oh, didn't split my commits correctly, the FIXME is removed in the patch on > bug #672777. Fixed now. Thanks. > > Also, gosxappinfo.h isn’t listed at all in gio/meson.build. > > None of the not-installed headers are listed because it's not needed. The > compiler tells ninja the list of headers needed to build a source file and > it uses that to know when to rebuild. OK. > > ::: gio/meson.build > > @@ +421,3 @@ > > > > + subdir('xdgmime') > > + internal_deps += [xdgmime_lib] > > > > gio/Makefile.am has this conditional on OS_UNIX. I don’t think we want to > > build xdgmime on Windows. > > It moves it to the "if host_system != 'windows'" block, previously it was in > the else block of "if glib_have_cocoa". Exactly the same as in Makefile.am. Whoops, my mistake, sorry.
Review of attachment 372194 [details] [review]: ++++++
Attachment 372194 [details] pushed as 2e3769a - Meson: Fix cocoa and carbon support
These commits broke make dist. Reverted
-- 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/1381.