Add support for building Apple bundles #14121

2xsaiko · 2025-01-11T17:22:01Z

Adds macOS (, Swift, GNUstep, whatever else) bundle support.

Still WIP but it can build a simple bundle at this point.

nsbundle = module('nsbundle')

tgt = nsbundle.application(
  'Example App',
  'main.m',
  dependencies: [
    dependency('appleframeworks', modules: ['Foundation', 'AppKit']),
  ],
  bundle_resources: structured_sources('icon.icns'),
  info_plist: 'Info.plist', # gets merged with some default generated options
)

TODO:

Framework bundle support
Maybe other bundle (.bundle) support
Xcode backend support
The code is probably sucky because I have no idea how this codebase works
Tests
Documentation
(whatever I can't think of at the moment)

Maybe:

Nested framework support (Contents/Frameworks, Contents/Shared Frameworks) & rpath patching on the built executable

Don't plan on writing:

VS backend support (don't have Windows so can't test it)

Closes #48. 🎉

bonzini · 2025-01-11T17:43:40Z

I would make it a new module.

2xsaiko · 2025-01-11T18:39:32Z

The app_bundle function? I can probably do that. I looked into it originally but then didn't do it because this is 90% the same as executable() and also this way you can use build_target to switch between executable and app_bundle depending on build configuration without having to duplicate the target definition.

What's your alternative for using build_target like that?

eli-schwartz

Not familiar enough with Apple bundles to say much about the topic, but I have a few observations regarding the coding style.

eli-schwartz · 2025-01-12T00:00:09Z

mesonbuild/build.py

+    def __init__(
+        self,
+        name: str,
+        subdir: str,
+        subproject: SubProject,
+        for_machine: MachineChoice,
+        sources: T.List['SourceOutputs'],
+        structured_sources: T.Optional[StructuredSources],
+        objects: T.List[ObjectTypes],
+        environment: environment.Environment,
+        compilers: T.Dict[str, 'Compiler'],
+        kwargs,
+    ):
+        self.bundle_resources: T.Optional[StructuredSources] = kwargs['bundle_resources']


Do not use the "black" deformatter.

Which formatter should I use?

eli-schwartz · 2025-01-12T00:00:28Z

mesonbuild/build.py

+        super().__init__(
+            name,
+            subdir,
+            subproject,
+            for_machine,
+            sources,
+            structured_sources,
+            objects,
+            environment,
+            compilers,
+            kwargs,
+        )


eli-schwartz · 2025-01-12T00:01:47Z

mesonbuild/build.py

+    def contents_root(self) -> str:
+        return {
+            'oldstyle': [],
+            'contents': ['Contents'],
+            'flat': [],
+        }[self.bundle_layout]
+
+    def bin_root(self) -> T.List[str]:
+        return {
+            'oldstyle': [],
+            'contents': [x for x in ['Contents', self.exe_dir_name] if x],
+            'flat': [],
+        }[self.bundle_layout]
+
+    def resources_root(self) -> T.List[str]:
+        return {
+            'oldstyle': ['Resources'],
+            'contents': ['Contents', 'Resources'],
+            'flat': [],
+        }[self.bundle_layout]
+
+    def info_root(self) -> T.List[str]:
+        return {
+            # The only case where Info.plist is in the Resources directory.
+            'oldstyle': ['Resources'],
+            'contents': ['Contents'],
+            'flat': [],
+        }[self.bundle_layout]


Surely there must be a better way to do this?

Yeah, this is super ugly. I do want to find a better way to write this. Could at least make this return a str and keep the rest the same but I'm still not satisfied with that.

There, I suppose the simplest way is probably the best here.

eli-schwartz · 2025-01-12T00:04:06Z

mesonbuild/envconfig.py

        """
        Machine is Darwin (iOS/tvOS/OS X)?
        """
-        return self.system in {'darwin', 'ios', 'tvos'}
+        return self.system == 'darwin'


This will probably break existing use cases in the wild. It also looks like it conflicts with changes you made elsewhere? What is the purpose of the change -- the commit message doesn't have much in the way of "why"s and definitely doesn't mention this change at all.

Yeah, I still need to split this change out. From what I can see the system is never 'ios' or 'tvos' but always 'darwin', those variants are subsystem instead (e.g. see cross/iphone.txt).

This was first added in f59786e. I suppose people are supposed to be able to both use system='ios' and system='darwin' subsystem='ios'? I'll revert this then.

eli-schwartz · 2025-01-12T00:04:38Z

mesonbuild/interpreter/interpreter.py

+    def func_app_bundle(
+        self, node: mparser.BaseNode, args: T.Tuple[str, SourcesVarargsType], kwargs: kwtypes.BuildTarget
+    ) -> build.AppBundle:


The black deformatter strikes again...

eli-schwartz · 2025-01-12T00:10:36Z

mesonbuild/build.py

+        sources: T.List['SourceOutputs'],
+        structured_sources: T.Optional[StructuredSources],
+        objects: T.List[ObjectTypes],
+        environment: environment.Environment,
+        compilers: T.Dict[str, 'Compiler'],


When adding brand new code, avoid quoting annotations. Since meson moved to python 3.7 as the minimum, we started using from __future__ import annotations which has the equivalent effect, so the manual quoting is no longer needed -- and makes lines slightly longer, which adds up and eventually tends to cause overly long lines which then need wrapping.

eli-schwartz · 2025-01-12T00:11:22Z

mesonbuild/build.py

+    def type_suffix(self):
+        return "@app"


Can add trivial type annotation. Also, double quotes -> single quotes.

eli-schwartz · 2025-01-12T00:17:32Z

mesonbuild/backend/ninjabackend.py

@@ -14,6 +14,7 @@
 import json
 import os
 import pickle
+import plistlib


This import is only needed on a single platform, and only some of the time. Maybe it would be a good idea to delay importing it until the function that uses it.

This can be used on any platform (specifically I also want a reasonable build system for GNUstep on Linux). But yeah, I'll move the import into the function.

jpakkane · 2025-01-19T18:43:23Z

I have been thinking about this also and maybe having a top level function for this is not the best thing to do. Because in practice it would mean that most build files just end up with if macos; app_bundle(...) else executable(...). It also get annoying if you want to bundle some helper exe in you bundle but itself builds as a bundle.

One alternate way of doing this would be to have a new option bundle for layout. This would set things up so that the build directory would be a whole bundle (you'd need additional functions to specify plists and all that). This is important because, from what I can tell, some functionality of macOS is not available unless the thing you are running is an app bundle. FWICT this is also, roughly, how Xcode sets up its projects.

2xsaiko · 2025-01-20T14:43:18Z

I have been thinking about this also and maybe having a top level function for this is not the best thing to do. Because in practice it would mean that most build files just end up with if macos; app_bundle(...) else executable(...).

Yeah, this is why I asked about using build_target with types added by a module in #14121 (comment). I wouldn't want that if/else either because that's awful to use.

Speaking of that, I just thought about a possible way to have the public interface in a module only: Have build_target also be able to take opaque type objects that you can return from a module, i.e. build_target(target_type: nsbundle.application_type()) or whatever. Is that a good idea?

It also get annoying if you want to bundle some helper exe in you bundle but itself builds as a bundle.

Right now, what I have in mind is something like nsbundle.application(..., executables: [foo_exe]) which will be placed into the bundle's executables directory (i.e. Xcode's EXECUTABLES_FOLDER_PATH).

One alternate way of doing this would be to have a new option bundle for layout. This would set things up so that the build directory would be a whole bundle (you'd need additional functions to specify plists and all that).

Which build directory? There are no per-target build directories except the private one, aren't there? This would have to be a per-target build directory since the bundle should effectively act like a single file, and that's how it already works right now. It should not contain "build residue" such as the private directory and whatnot, and you should be able to create more than one bundle target per project. Otherwise I don't see how this would be more practical to use than the current workaround in the documentation.

This is important because, from what I can tell, some functionality of macOS is not available unless the thing you are running is an app bundle.

Yeah. This is working fine already though. Building a project with an app bundle target as of right now builds an app bundle in the same place an executable would be, which you can run from the build directory.

The Ninja bundle builder uses this to merge a user supplied Info.plist with some Meson-generated data.

In case the source file is built by a target, the input file path needs to be the same as the target that generates the input file in order for Ninja to set up the target dependency.

2xsaiko force-pushed the push-xtkkyrnnxouu branch from 87b098e to d76708a Compare January 11, 2025 23:45

2xsaiko mentioned this pull request Jan 11, 2025

Show real error if module exists but import failed #14124

Open

2xsaiko force-pushed the push-xtkkyrnnxouu branch from d76708a to ec73cc4 Compare January 11, 2025 23:56

eli-schwartz requested changes Jan 12, 2025

View reviewed changes

2xsaiko force-pushed the push-xtkkyrnnxouu branch from ec73cc4 to 284e328 Compare January 12, 2025 13:55

Add MachineInfo.is_macos() function

fe3d330

2xsaiko force-pushed the push-xtkkyrnnxouu branch 10 times, most recently from 6e7e637 to 7976bcc Compare January 16, 2025 00:56

2xsaiko added 10 commits January 20, 2025 15:52

Add MachineInfo.is_wasm() function

1e0dd25

Add merge-plist script

56854d5

The Ninja bundle builder uses this to merge a user supplied Info.plist with some Meson-generated data.

ninja: Add rule for merge-plist

b984e26

ninja: Use relative path for source file in copy target

50f589d

In case the source file is built by a target, the input file path needs to be the same as the target that generates the input file in order for Ninja to set up the target dependency.

Allow modules to construct BuildTarget subclasses from function args

b41a0b6

Allow targets to declare outputs as directories

57664bf

Add common bundle logic

a0929e1

Add AppBundle target type

dede422

Construct AppBundle via nsbundle module

7429d9f

ninja: Bundle target support

3c49081

2xsaiko force-pushed the push-xtkkyrnnxouu branch from 7976bcc to 3c49081 Compare January 20, 2025 14:52

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add support for building Apple bundles #14121

Add support for building Apple bundles #14121

2xsaiko commented Jan 11, 2025 •

edited

Loading

bonzini commented Jan 11, 2025

2xsaiko commented Jan 11, 2025

eli-schwartz left a comment

eli-schwartz Jan 12, 2025

2xsaiko Jan 12, 2025

eli-schwartz Jan 12, 2025

eli-schwartz Jan 12, 2025

2xsaiko Jan 12, 2025

2xsaiko Jan 12, 2025

eli-schwartz Jan 12, 2025

2xsaiko Jan 12, 2025

2xsaiko Jan 12, 2025

eli-schwartz Jan 12, 2025

eli-schwartz Jan 12, 2025

eli-schwartz Jan 12, 2025

eli-schwartz Jan 12, 2025

2xsaiko Jan 12, 2025

jpakkane commented Jan 19, 2025

2xsaiko commented Jan 20, 2025

Add support for building Apple bundles #14121

Are you sure you want to change the base?

Add support for building Apple bundles #14121

Conversation

2xsaiko commented Jan 11, 2025 • edited Loading

bonzini commented Jan 11, 2025

2xsaiko commented Jan 11, 2025

eli-schwartz left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jpakkane commented Jan 19, 2025

2xsaiko commented Jan 20, 2025

2xsaiko commented Jan 11, 2025 •

edited

Loading