当前位置：文江博客话题详情

如何构建本机 Mac OS X 安装程序（在非 Mac 平台上）？

发布于 2024-07-08 02:29:56 字数 145 浏览 12 评论 0原文

如何在非 Mac 平台上为我的应用程序构建本机 Mac OS X 安装程序？

例如，我有一台 Windows 电脑和一个 Java 应用程序。我希望 Windows 电脑构建一个与 Apple 安装程序配合使用的安装程序（可能在 .dmg 存档内）。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

浪菊怪哟 2024-07-15 02:29:57

现在可以在非 Mac 平台上创建本机 Mac OS X 安装程序。对于 Louis Gerbarg，最棘手的部分是 BOM（物料清单）文件。不过，mkbom 的开源版本（基于 Joseph Coffland 的 osxbom 代码）现已提供：

http://hogliux .github.io/bomutils

该网站还提供了有关在 Linux 上创建 Mac OS X 安装程序的易于遵循的分步教程（http://hogliux.github.io/bomutils/tutorial.html ）。

我的公司定期使用这种方法在 Linux 上构建 Mac OS X 安装程序，到目前为止我们还没有遇到任何重大问题。

回复收藏 0 原文

白日梦 2024-07-15 02:29:57

正如其他人已经指出的那样，您实际上正在采取硬性解决方案来解决此问题，并且您的用户会为此咒骂您的名字，除非您有一个真正的理由这样做。确实，某些类型的应用程序需要 Mac OSX 的安装程序。这些通常包括：

安装自定义驱动程序（即内核扩展）的应用程序
需要安装框架或其他资源（由于某种原因无法打包在应用程序包中）的
应用程序需要作为系统服务运行，因此必须运行某些应用程序用于在启动期间启动应用程序的安装后脚本
编写不佳的程序，需要对用户系统进行某种类型的更改（即设置文件夹或其他内容的权限），并且开发人员的双手被营销部门束缚以分发应用程序以最痛苦的方式可能

好吧，最后一点有点讽刺，但是你明白我的意思了吗？ :) 基本上，如果您正在编写一个普通的最终用户应用程序，您应该以 Mac 用户期望的正常方式分发它，这是一个包含应用程序包的 DMG 文件。或者，如果您想要真正的花哨，可以在 DMG 内的“应用程序”文件夹中添加一个别名，以帮助用户将程序拖到那里。除非您正在编写的东西必须将自身安装到系统中，而不是简单地由系统运行，否则没有理由在这里使用安装程序。另外，请记住，这是 OSX，它已经包含功能齐全的 Java JRE，因此您无需担心将 JRE 打包到安装程序或类似的东西中。

既然您因提出这个问题而受到了适当的责骂，那么我将假设您的软件属于上述类别之一来回答它。实际上，您最好的选择是使用商业解决方案，例如 VISE 安装程序（我可以再次自信地说，绝大多数 Mac 用户在安装使用此工具制作的产品时会感到恐惧），它允许您完全按照您在这里寻找的内容进行操作 - 基本上，制作一个跨平台安装程序，该安装程序可以通过单个安装程序文件为您想要支持的各种平台构建。

不过，再次强调，您最好的选择是做该平台用户最喜欢的事情（这就是为什么对您的问题的所有答复都敦促您不要制作安装程序）。然而，这意味着，如果您确实必须制作安装程序，则应该使用非跨平台框架； Windows 用户在使用标准 MSI 安装程序时会感到最自如，而 Mac 用户在使用 Apple Installer pkg 时会感到最自在。不过，PackageMaker 程序的局限性是众所周知的，因此，如果必须的话，您应该使用 iceberg 相反。这对您来说意味着更多的维护工作，因为您需要维护两个（或更多）单独的安装程序，但如果您的软件确实如此复杂以至于需要这样做，您应该愿意为舒适性做出牺牲您的用户。

As others have already pointed out, you are really taking the hard solution to this problem, and your users will curse your name for it, unless you have a really good reason to do so. It is true, that certain types of applications will require installers for Mac OSX. These generally include:

Applications which install custom drivers (ie, kernel extensions)
Applications which need to install frameworks or other resources which for some reason could not be packaged within the application bundle
Applications which need to run as a system service and therefore must run some post-install scripts to launch the app during bootup
Poorly written programs which require making some type of changes to the user's system (ie, setting permissions on a folder or something), and the developer's hands are tied by marketing department weenies to distribute the application in the most painful way possible

Ok, so that last point is a bit sarcastic, but do you get my drift here? :) Basically, if you are writing a normal, end-user application, you should distribute it in the normal way that Mac users would expect, which is a DMG file containing your application's bundle. Or if you want to be really fancy, stick an alias to the "Applications" folder inside of the DMG to help the user drag the program in there. Unless you are writing something which must install itself into the system, rather than simply be run by the system, there's no reason to use an installer here. Also, keep in mind that this is OSX, which already contains a fully-functioning Java JRE, so you don't need to worry about packaging the JRE in an installer or anything like that.

Now that you've been properly scolded for asking this question, I'll answer it with the assumption that your software falls in one of the categories above. Really, your best bet would be to go with a commercial solution such as VISE installer (which, again, I can state confidently that a vast majority of Mac users will recoil in terror when installing a product made with this tool), which allows you to do exactly what you are looking for here -- basically, to make a cross-platform installer which builds for the various platforms you want to support from a single installer file.

Again, though, your best bet here is to do what users of that platform are most comfortable with (which is why all the responses to your question urge you not to make an installer). That means, however, if you really must make an installer, you should use a non-cross-platform framework; windows users will feel most at home when presented with a standard MSI installer, and Mac users will feel most at home with an Apple Installer pkg. The PackageMaker program is notoriously limited, though, so if you must, you should use iceberg instead. This will mean a bit more maintainance for you, since you'll need to tend after two (or more) separate installers, but if your software is really so complex as to demand this, you should be willing to make the sacrifice for the comfort of your users.

回复收藏 0 原文

怪我入戏太深 2024-07-15 02:29:57

在 Windows 上创建 .dmg 很困难，但当然可以创建一个可以压缩的 .app 文件结构，正如其他人评论所提到的。有时，常规 .pkg 无法剪切它，而您希望提供对话框、安装前检查等。您可以使用 BitRock installbuilder，您可以从其他每个平台构建适用于 mac、Linux、Windows、Solaris 的安装程序。

回复收藏 0 原文

没︽人懂的悲伤 2024-07-15 02:29:57

那么，有几个简单的问题。

首先，为什么需要安装程序？大多数 Mac 用户更喜欢直接拖动安装的应用程序。如果您不是编写 Mac OS X 特定代码，则很难想象您需要将位放置在特殊位置，例如应用程序支持或 LaunchDaemons。假设您拥有的所有内容都放在一个文件夹中，为什么还要麻烦安装程序呢？

其次，为什么在 Mac 上构建 Mac 安装程序会出现问题？当然，您有一台 Macintosh 来测试该应用程序（您不会只是盲目地在 Mac 上发布它而不在 Mac 上进行测试，对吗？）。

好吧，话虽如此，假设您仍然有充分的理由在 PC 上实际构建它，那么有些部分并不容易。基本上，.pkg 是一堆文本脚本、本地化、存档文件 (Archive.pax.gz) 和物料清单 (Archive.bom)。

假设构建之间没有太大变化，您可以在 Mac 上制作安装程序，然后重建 bom 和 pax.gz，将它们替换为现有的 .pkg，并批处理一些元数据。 pax 应该很容易处理（pax 是标准存档格式），但 bom 文件可能有点棘手，因为我不相信它是公开记录的，并且我怀疑创建它们的工具（mkbom）是否是达尔文的一部分（非开源）。因此，您需要弄清楚这一点并编写一个自定义工具来创建 bom 文件。

换句话说，这可能是一项大量的工作。

回复收藏 0 原文