Как собрать собственный установщик Mac OS X (на платформе не Mac)? - PullRequest
6 голосов
/ 12 ноября 2008

Как мне создать собственный установщик Mac OS X для моего приложения на платформе не Mac?

Например, у меня есть компьютер с Windows и приложение на Java. Я хочу, чтобы на компьютере Windows был создан установщик (возможно, внутри .dmg архива), который работает с установщиком Apple.

Ответы [ 7 ]

4 голосов
/ 29 июля 2013

Теперь возможно создать собственный установщик Mac OS X на платформе не Mac. Как Луи Гербарг, хитрый момент - это файл спецификации (спецификации). Однако версия mkbom с открытым исходным кодом (основанная на коде osxbom Джозефа Коффланда) теперь доступна по адресу:

http://hogliux.github.io/bomutils

На веб-сайте также есть простое пошаговое руководство по созданию установщика Mac OS X в Linux (http://hogliux.github.io/bomutils/tutorial.html).

Моя компания регулярно собирает установщики Mac OS X для Linux с помощью этого метода, и до сих пор у нас не было серьезных проблем.

2 голосов
/ 18 января 2009

Сложно создать .dmg в Windows, но, безусловно, возможно создать структуру файла .app, которую можно затем сжать, как уже упоминали другие комментирующие. Бывают случаи, когда обычный .pkg не обрезает его, и вы хотите предоставить диалоги, проверки перед установкой и т. Д. Вы можете сделать это с помощью BitRock installbuilder , вы можете создавать установщики для Mac, Linux, Windows Солярис с каждой из других платформ.

2 голосов
/ 12 ноября 2008

Как уже отмечали другие, вы действительно принимаете сложное решение этой проблемы, и ваши пользователи будут проклинать ваше имя за это, если у вас нет действительно веской причины для этого. Это правда, что для определенных типов приложений потребуются установщики для Mac OSX. Они обычно включают в себя:

  • Приложения, устанавливающие собственные драйверы (например, расширения ядра)
  • Приложения, которым необходимо установить интегрированные среды или другие ресурсы, которые по какой-либо причине не могут быть упакованы в комплект приложений
  • Приложения, которые должны запускаться как системная служба и, следовательно, должны запускать некоторые сценарии после установки для запуска приложения во время загрузки
  • Плохо написанные программы, которые требуют внесения каких-либо изменений в систему пользователя (например, установки разрешений для папки или чего-то еще), а руки разработчика привязаны к маркетингу, чтобы распространять приложение наиболее болезненным способом

Хорошо, последний пункт немного саркастичен, но вы меня поняли? :) По сути, если вы пишете обычное приложение для конечного пользователя, вы должны распространять его обычным способом, который ожидают пользователи Mac, - это файл DMG, содержащий пакет вашего приложения. Или, если вы хотите быть по-настоящему модным, добавьте псевдоним в папку «Applications» внутри DMG, чтобы помочь пользователю перетащить туда программу. Если вы не пишете что-то, что должно само установить в систему, вместо того, чтобы просто запускаться системой, здесь нет причин использовать установщик. Кроме того, имейте в виду, что это OSX, который уже содержит полнофункциональную Java JRE, поэтому вам не нужно беспокоиться об упаковке JRE в установщик или что-то в этом роде.

Теперь, когда вас правильно отчитали за то, что вы задали этот вопрос, я отвечу на него, предположив, что ваше программное обеспечение относится к одной из указанных выше категорий. На самом деле, вам лучше всего пойти с коммерческим решением, таким как установщик VISE (который, опять же, я могу с уверенностью заявить, что подавляющее большинство пользователей Mac будут в ужасе отшатываться при установке продукта, созданного с помощью этого инструмента), который позволяет вам чтобы сделать именно то, что вы ищете здесь - в основном, создать кроссплатформенный установщик, который собирает для различных платформ, которые вы хотите поддерживать, из одного файла установщика.

Опять же, вам лучше всего делать то, что пользователям этой платформы наиболее удобно (именно поэтому все ответы на ваш вопрос призывают вас не устанавливать инсталлятор). Это означает, однако, что если вам действительно нужно сделать установщик, вы должны использовать non -кроссплатформенную платформу; Пользователи Windows будут чувствовать себя как дома, когда им предоставляется стандартный установщик MSI, а пользователи Mac будут чувствовать себя как дома с программой установки Apple. Программа PackageMaker общеизвестно ограничена, поэтому, если вам нужно, вы должны использовать iceberg . Это будет означать немного больше обслуживания для вас, так как вам нужно будет ухаживать за двумя (или более) отдельными установщиками, но если ваше программное обеспечение действительно настолько сложное, что требует этого, вы должны быть готовы пожертвовать ради комфорта ваших пользователей.

1 голос
/ 12 ноября 2008

Итак, пара быстрых вопросов.

Во-первых, зачем вам установщик? Большинство пользователей Mac предпочитают приложения, которые просто устанавливаются путем перетаскивания. Если вы не пишете специальный код для Mac OS X, трудно представить, что вам нужно размещать биты в специальных местах, таких как поддержка приложений или LaunchDaemons. Если все, что у вас есть, просто помещается в одну папку, зачем вообще беспокоиться об установщике?

Во-вторых, почему возникла проблема при сборке установщика Mac на Mac? Конечно, у вас есть Macintosh для тестирования приложения (вы не просто слепо отправляете его для Mac без тестирования на Mac, верно?).

Хорошо, сказав, что, если у вас все еще есть веская причина для того, чтобы на самом деле собрать это на ПК, есть некоторые моменты, которые не будут легкими. В основном .pkg - это набор текстовых скриптов, локализаций, архивный файл (Archive.pax.gz) и перечень материалов (Archive.bom).

Предполагая, что между сборками не так много изменений, вы можете создать установщик на Mac, а затем просто пересобрать bom и pax.gz, заменить их в существующий .pkg и пакетировать несколько фрагментов метаданных. С pax должно быть достаточно легко работать (pax - это стандартный формат архива), но файл bom может оказаться немного сложнее, поскольку я не верю, что он публично задокументирован, и я сомневаюсь, что инструменты для их создания (mkbom) часть Дарвина (не с открытым исходным кодом). Так что вам нужно разобраться с этим и написать собственный инструмент для создания файла BOM.

Другими словами, это может быть большой объем работы.

0 голосов
/ 05 ноября 2011

Проверьте этот код для чтения файлов спецификации: https://cauldrondevelopment.com/svn/osxbom/trunk

0 голосов
/ 13 ноября 2008

Поместите все в один файл JAR, добавьте его в ZIP. Готово.

А если серьезно, вы хотите распространять свое приложение среди пользователей Macintosh без его предварительного тестирования? На какой ты планете!?

0 голосов
/ 12 ноября 2008

Обычный способ установить приложение на Mac - перетащить приложение в папку приложения. Большинство программ представляют собой DMG, содержащую приложение и символическую ссылку на папку приложения. Почему вы хотите это по-другому? Вам нужно подумать о Mac, чтобы создать отличное приложение для Mac! Внешний вид очень важен, особенно для пользователей Mac.

...