[RFC] meson: support exporting to xcode

[tangalbert919]

Even though Meson supports exporting to Xcode, a few changes are required so that mpv runs successfully on it:

• mpv must have at least one source file to compile, as Xcode does not support object-only targets.
• The sources and bridging header for the custom swift target are added to libmpv sources, but only if Xcode was specified as the backend to use. This is mainly so they show up in the IDE itself, which should make development on macOS easier.

Right now, Meson's Xcode backend is in need of repairs (see mesonbuild#12056). At best, mpv will not be able to take advantage of this until Meson 1.3.0 is released. Meson's Xcode backend is functional as of 1.4.0, so mpv can take advantage of this now.

[Dudemanguy]

Marked this as draft for now since it depends on some meson changes.

[NekoAsakura]

Can this pull request continue to be processed? Building with Xcode can significantly enhance the debugging experience on macOS.

[Akemi]

i am not completely against any kinda of xcode integration, i made a similar PR #8854 once. building was completely done via meson still and you could debug via xcode.

though not sure this is the right way to go:

• adding xcode as another build dependency or as a build system ontop of our own just adds another opening for errors
• not sure if the maintenance burden is something we want to take care of
• unneeded added build complexity

maybe it would just be better to add/write a tutorial how to create an xcode project that uses our build system instead, eg how i created the my previous PR.

[NekoAsakura]

I personally enjoy using Xcode for debugging because it makes tracking variables in frames and threads much more convenient, especially compared to use lldb in command line. Even Xcode supports debugging through attach to a runtime process, some advanced features are disabled. I've seen a project(https://github.com/libobjc/FFmpeg-in-Xcode) for ffmpeg, but I'm not sure if we could achieve something similar. I'm happy to spend time on this work, writing a tutorial, or creating a similar project, but it won’t be immediately as I’m currently quite busy.

[tangalbert919]

@Akemi I understand some of your concerns, and I read through your old PR when I was working on this one. Let me clear up some of your concerns and explain what I was thinking when I was working on this.

• adding xcode as another build dependency or as a build system ontop of our own just adds another opening for errors

In this PR, both of those things are avoided. Meson is able to export to Xcode, and when it does, the generated project file forces Xcode to use the Meson build system. Meson still uses ninja as the default backend, so the only time Xcode is required is if the user specifies it as the backend during setup.

• not sure if the maintenance burden is something we want to take care of

I think this is in reference to your old PR. I can see how that would be a burden, considering what it took for you to even make the project file in the first place. One of my goals for this PR was to avoid that entirely, since Meson can just generate that project file instead. Plus, I don't think anyone wants to deal with merge conflicts taking place in that file every time they update their fork.

• unneeded added build complexity

For the most part, I tried to minimize this as much as possible, since Meson's Xcode backend works much better now and is getting a bit more attention than it did before. That being said, there are some things that Xcode cannot handle due to its own limitations (e.g. it can't handle object-only targets), so if there is any of that added build complexity, it's mainly to address that problem. It should have absolutely no effect when Xcode is not being used as the backend by Meson.

If there is anything I have missed, please feel free to let me know and I can address it.

[Akemi]

In this PR, both of those things are avoided. Meson is able to export to Xcode, and when it does, the generated project file forces Xcode to use the Meson build system. Meson still uses ninja as the default backend, so the only time Xcode is required is if the user specifies it as the backend during setup.

the whole swift compilation/target is excluded (https://github.com/mpv-player/mpv/pull/12235/files#diff-b72cb4b6ee70aeec879fdbd428279f1e80b0795137e185a144673a172bebbef0R39-R66), so who takes care of this? it's not our code so it's either something from meson or xcode. in either case it's another build path that i would possibly avoid. it makes the whole thing more complex and adds another opening for errors (mentioned above).

if it's meson, we should use this functionality not just for exporting to xcode but get rid of our whole custom target.

I think this is in reference to your old PR.

no, see above.

if possible:

• we should get rid of the many preprocessors of the swift headers (eg one header with it and that header is included everywhere needed)
• remove the complexity and cases from our custom targets and xcode export, currently it makes it more complex than needed

otherwise i would be fine going forward with this.

[tangalbert919]

I think I understand what you mean this time, so I'll explain it this way:

The entire project can be exported to Xcode in its current state, but it won't build successfully because of linking errors. To address that problem, you only need to do this:

@@ -1816,8 +1815,8 @@ if get_option('cplayer')
                  rename: 'mpv.svg')
     install_data('etc/mpv-symbolic.svg', install_dir: join_paths(hicolor_dir, 'symbolic', 'apps'))
 
-    mpv = executable('mpv', main_fn_source, objects: libmpv.extract_all_objects(recursive: true), dependencies: dependencies,
-                     win_subsystem: get_option('win32-subsystem'), install: true)
+    mpv = executable('mpv', main_fn_source, dependencies: dependencies,
+                     win_subsystem: get_option('win32-subsystem'), install: true, link_with: libmpv)
 
     if win32 and get_option('win32-subsystem') != 'console'
         wrapper_sources= 'osdep/win32-console-wrapper.c'

That's all you actually have to do so you can start debugging this in Xcode. Replacing objects with link_with gets around the issue of Xcode complaining about missing objects because two objects with the same name had to be "renamed" to avoid conflicts, and meson can't detect that during configuration.

The other changes, I can explain. A few of them aren't needed anymore because they have already been addressed in one way or another, but the one you're concerned about has a decent explanation.

the whole swift compilation/target is excluded (https://github.com/mpv-player/mpv/pull/12235/files#diff-b72cb4b6ee70aeec879fdbd428279f1e80b0795137e185a144673a172bebbef0R39-R66), so who takes care of this? it's not our code so it's either something from meson or xcode.

When using Xcode as the backend, the custom swift target is excluded because its sources are added into the libmpv target instead (https://github.com/mpv-player/mpv/pull/12235/files#diff-30d8f6be6320feeacf686be94f48c70869b52630e01ea625f0f15adc0d57c3e4R1579-R1586). The idea is to make those files visible to Xcode, since meson doesn't add input files in custom targets to Xcode at all. Xcode can already do what the custom target is configured to do anyway, but it generates the bridge header file in a different place, so I ended up doing stuff like more preprocessing just so it compiles. It's not an ideal way to handle it, but at least it works.

It's not a necessary change if you're not concerned about being able to edit those swift files in Xcode. It just makes development a bit easier when you have to make changes there.

if it's meson, we should use this functionality not just for exporting to xcode but get rid of our whole custom target.

I'm guessing you want to turn that into a library target that libmpv links to, right? That would be beyond the scope of this PR, but it is something worth doing because the custom target looks like a workaround.