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
)

Sample project: https://git.dblsaiko.net/MesonBundlesTest/

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 · 2025-01-25T18:40:41Z

I've been reading #106 and I feel like some of that discussion is relevant for this too, particularly #106 (comment) and #106 (comment).

Right now, in the implementation in this PR, frameworks act a lot like dependencies (in that they add their headers to targets linked against) instead despite being library targets—and while that is how Rust and Java targets work as well, I don't think it fits very well with the rest of Meson's design for C style dependencies. Additionally really does not make it possible to build frameworks with minimal or no build script changes (CMake can do this though I've never tried it myself), perhaps eventually even just a configure time flag—which I think is sort of what you were talking about in #14121 (comment), @jpakkane.

NB: It does not seem possible to specify that a framework depends on another, or a shared library, or an extra include dir, in the install interface, which is what the original issue is about. But whatever, if you want that, don't build frameworks.

The important difference to the above issue in this case is that both app bundles (which isn't relevant at all in the other issue) and framework bundles have a directory layout that is potentially relevant at runtime¹, that means, for them to work correctly they have to exist in assembled form in the build directory already, as opposed to that structure being created at install time.

For this to work in a way that fits with the existing design, a couple things have to happen:

For frameworks, there should be a new function similar to pkg.generate()

It takes the main library as dependency, plus the extra bundle options
It returns a framework dependency object which can be added to target dependencies, like declare_dependency
It creates the bundle in the build directory at build time, sort of like pkg.generate()
It has an install option like a library target
It should be possible to additionally install a .pc file
This will work fine for Ninja but will probably need special handling for Xcode since there is only the single framework target instead of a separate one for each the library and the bundle (this is the reason I did not go this route initially)
1. what should happen if this function is called multiple times with the same main library?

That is the easy case, since there is mostly precedent for this in declare_dependency/the pkg-config module. For applications there really isn't, but I think something analogous could be done there.

That would leave us with something like the following:

nsbundle = module('nsbundle')

mylib = shared_library('mylib', 'lib.m')
mylib_fw = nsbundle.framework(mylib, include_directories: 'include', install: true, resources: structured_sources(...), ...)

myapp_exe = executable('myexe', 'main.m', dependencies: [mylib_fw])
nsbundle.application(myapp_exe, resources: structured_sources(...), ...)

Unfortunately that means you will have both the app bundle and the original bare executable in the build directory, but oh well.

Another thing is that installing an app bundle or framework should disable install of the original library in some way, and its resource files which are already shipped in the bundle. Right now that probably needs some logic in the build script if you want to support building these.

What do you think?

¹ https://developer.apple.com/documentation/foundation/nsbundle#1651491

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

Merged

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 2 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.

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

ninja: Add rule for merge-plist

8a87f50

2xsaiko force-pushed the push-xtkkyrnnxouu branch 6 times, most recently from 403487f to c1a587e Compare January 23, 2025 15:37

2xsaiko added 6 commits January 23, 2025 23:39

Add symlink script

b6b0d33

ninja: Add rule for symlink

fcea33e

ninja: Use relative path for source file in copy target

ac75666

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

65d6f67

Allow targets to declare outputs as directories

61b256a

Add common bundle logic

6af1a5d

2xsaiko force-pushed the push-xtkkyrnnxouu branch 3 times, most recently from 85c059a to 839a937 Compare January 24, 2025 00:05

2xsaiko added 4 commits January 25, 2025 02:36

Add bundle target types

de2064c

Construct bundle targets via nsbundle module

cece563

ninja: Bundle target support

f753b6c

Framework target link support

3825453

2xsaiko force-pushed the push-xtkkyrnnxouu branch from 839a937 to 3825453 Compare January 25, 2025 01:36

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

2xsaiko commented Jan 25, 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 25, 2025

2xsaiko commented Jan 11, 2025 •

edited

Loading