Re: devel/gobject-introspection on Darwin

[clément bouvier <clement.bouvier.europe%gmail.com@localhost>]

Sorry for the laconic message, yesterday.

Concerning the undefined symbols in the build, it coming from our glib2 patched. 
In fact, the problem on macOS platform is that the implementation of "gappinfo" is gosxappinfo and there is not alternative so that suppose all applications on macos
is a "macOS bundle" but it is not true (pkgsrc doesn't build bundle, neither macports or any other packaging system).
We build by default all our binaries with X11 implementation (gtk, Tk, etc…) and these binaries suppose that devel/glib2 uses gdesktopappinfo implementation and the binary builds crash. 
For instance @schmonz patched the devel/glib2 to include gdesktopappinfo.h header to help the gtk{2,3} build [1]

But if we include the header gdesktopappinfo without any implementation in devel/glib2, g-ir-scanner in devel/gobject-introspection has a problem for making the gir-XML files.
There was glib2 upstream proposal and patch for choosing the implementation at compile time ("native", "gdesktopappinfo") [2] but it was before mesonbuild migration.
My patch submitted at pkgsrc is an adaptation to this patch. However, as Patrick Welches mentioned in the PR, upstream also adapted the patch.
 The problem is that this patch failed their CI test on Windows platform because the maintainers just put gdesktopappinfo implementation choice on windows but this implementation is unix oriented so there is some header and assumption that is not true on Windows (typically #include <unistd.h>) [3]. In comparison with the patch submitted to pkgsrc, I only focused on macOS platform and I didn't touch anything to Windows.
So the plan I have (with Patrick Welches discussion) is to contact upstream and ideally try to make the CI tests correct so as to their branch be validated. 

I read your pull-request to object-introspection but I don't think that it is gobject-introspection problem initially [4].

Now there also is another problem with devel/gobject-introspection.
Meson build and pkgsrc cwrapper don't work correctly together on macos  (@rpath problem).
I already mentioned on @pkg-users [5], on .work_log we obtain for g-ir-compiler:

[*] cc -o tools/g-ir-compiler 'tools/f9d35d4@@g-ir-compiler@exe/compiler.c.o' [...] '-Wl,-rpath,@loader_path/../girepository' '-Wl,-rpath,@loader_path/../girepository/cmph' -Wl,-rpath,/Users/cbouvier/pkg/lib -Wl,-rpath,/Users/cbouvier/prj/pkgsrc/devel/gobject-introspection/work/gobject-introspection-1.60.1/output/tools/../girepository
<.> /usr/bin/clang -m64 -o tools/g-ir-compiler 'tools/f9d35d4@@g-ir-compiler@exe/compiler.c.o' [...] -Wl,-rpath,/Users/cbouvier/pkg/lib -Qunused-arguments 

So @loader_path is filtered out (please forget the -Wl,-rpath,/Users/cbouvier/prj/pkgsrc/devel/gobject-introspection/work/gobject-introspection-1.60.1/output/tools/../girepository part because it was a test and it is not here normally), so the binary cannot be working in the WRKDIR.
Meson_build has custom targets to make the type-lib files based on the gir xml files generated by the g-ir-scanner. Theses typelib files are generated by the g-ir-compiler

The targets are (in meson language): 

typelibs = []
foreach gir : gir_files
  typelibs += custom_target('generate-typelib-@0@'.format(gir).underscorify(),
    input: gir,
    output: '@BASENAME@.typelib',
    depends: [gobject_gir, ],
    command: [gircompiler, '-o', '@OUTPUT@', '@INPUT@',
              '--includedir', meson.current_build_dir(),
              '--includedir', meson.current_source_dir(),
    ],
    install: true,
    install_dir: typelibdir,
  )
endforeach

So the targets cannot work because the g-ir-compiler cannot find during the build its girepository lib.

The workaround is either as I proposed, make a static version of girepository library and build an version of g-ir-compiler with it and generate the typelib files, either use Brook's method.
Now about upstream, as Brook said, I don't think upstream validate the kind of patch because their build system would work outside pkgsrc.
Probably the plan, as Brook, propose is to split the pkg into two parts:
* devel/gobject-introspection-tools with girepository library and g-ir-scanner, g-ir-compiler and so on tools
* devel/gobject-introspection with the gir-xml and typelibs files to generate.

But that causes another problem because upstream does not provide any kind opportunities to choose the g-ir-compiler during the custom targets…(for instance using a find_program and configure variable dance ).
But maybe upstream can be more ok with this kind of proposal….I don't know.

Cheers,
Clément.  

[1] http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/devel/glib2/patches/patch-gio_meson.build.diff?r1=1.4&r2=1.5&f=h  
[2] https://gitlab.gnome.org/GNOME/glib/issues/1263
[3] https://gitlab.gnome.org/pwithnall/glib/pipelines/23785
[4] https://gitlab.gnome.org/GNOME/gobject-introspection/issues/301

> Le 2 août 2019 à 20:31, clément bouvier <clement.bouvier.europe%gmail.com@localhost> a écrit :
> 
> Thank you,
> 
> I posted a series of patch on pkg-users:
> https://mail-index.netbsd.org/pkgsrc-users/2019/07/22/msg029070.html
> concerning pkg/54393…
> 
> Cheers,
> Clement.
> 
>> Le 2 août 2019 à 19:46, Brook Milligan <brook%nmsu.edu@localhost> a écrit :
>> 
>> I have finally had success building devel/gobject-introspection on a MacBook.  Before I commit the patches (attached), however, I would appreciate feedback.
>> 
>> The patch to meson.build is already filed upstream and is awaiting action on the merge request.  I think that should not be controversial as (in my experience anyway) there are no relevant symbols to link against and trying to do so should clearly be prevented.
>> 
>> I am less certain of the other part, which changes Makefile and tools/meson.build, and adds files/fix-darwin-rpath.sh.  The idea is to introduce a step using install_name_tool to fix the rpath in g-ir-compiler so that it will run correctly during the build process.  Of course, this must be reverted during the install step, so the post-install target is added.
>> 
>> This seems overly complicated (an alternative might be to create a new package for the girepository library, but that also is invasive into the package build process, just in a different way).  However, it is what is essentially stated as necessary by https://mesonbuild.com/Creating-OSX-packages.html; see the statement "This is the part of OSX app bundling that you must always do manually."
>> 
>> In any case, I would greatly appreciate comments, as we need a way to make this package on Darwin and I don't think purity is an option in this case.  Thanks.
>> 
>> Cheers,
>> Brook
>> 
>> 
>> <gobject-introspection.patch>
>