Советы по развертыванию кода на С++ для работы где угодно

Я не говорю о создании портативного кода. Это скорее вопрос распределения. У меня средний проект. Он имеет несколько зависимостей от общих библиотек (например, openssl, zlib и т.д.). Он отлично компилируется на моей машине, и теперь настало время дать его миру.

По существу, строительная техника в лучшем виде. Я хочу сделать инсталляторы для Windows, Linux, MacOSX и т.д. Я хочу сделать загружаемый tar-мяч, который сделает код работать с ./configure и make (возможно, с помощью autoconf). Было бы обледенением на торт, чтобы иметь опцию make, которая будет строить инсталляторы.. может быть даже кросс-компиляция, поэтому установщик Windows может быть построен в Linux.

Какова лучшая стратегия? Где я могу рассчитывать потратить больше времени? Должен ли основной фокус быть autoconf или есть другие инструменты, которые могут помочь?

Ответ 1

Я бы порекомендовал CMake. Преимущества:

Он очень прост в использовании для создания простых и сложных проектов со статическими библиотеками, динамическими библиотеками, исполняемыми файлами и их зависимостями.
Он независим от платформы и создает файлы файлов makefile и/или ide для большинства компиляторов и IDE.
Он абстрагирует различия между окнами и unix, например, "libShared.so" и "Shared.dll" называются "Shared" (cmake обрабатывает различия имен для каждой платформы), если Shared является частью вашего проекта, он сортирует зависимость, если не предполагает, что она находится в пути компоновщика.
Он исследует систему пользователей для компиляторов и сторонних библиотек, которые необходимы, затем вы можете дополнительно удалить компоненты, когда сторонние библиотеки недоступны или отображать сообщение об ошибке (он поставляется с макросами для поиска наиболее распространенных сторонних библиотек).
Его можно запустить из командной строки или с помощью простого gui, который позволяет пользователю изменять любой из параметров, которые были обнаружены выше (например, компилятор или версия сторонней библиотеки).
Он поддерживает макросы для автоматизации общих шагов.
Существует компонент под названием CPack, который позволяет вам создать установщик, я думаю, что это всего лишь строка командной строки make install (я ее не использовал).
Компонент CTest интегрируется с другими модульными тестовыми библиотеками, такими как тест повышения или тест Google.

Я использую CMake для всех сейчас, даже простых тестовых проектов с визуальной студией.

Я никогда не использовал autotools, но многие другие пользователи прокомментировали, что cmake проще в использовании. По этой причине проект KDE переместился в cmake из autotools.

Ответ 2

Продукт, над которым я работаю, не слишком отличается от этого. Мы используем систему сборки на основе autoconf, и она работает очень хорошо.

Место, которое вы потратите больше всего времени, безусловно, поддерживает пользователей. Пользовательские системы будут иметь всевозможные морщины, которые вы не ожидаете, пока они не наткнутся на них, и вам нужно будет добавить дополнительные параметры конфигурации для их поддержки. Со временем мы добавили опции для установки путей include и lib для каждой библиотеки, от которой мы зависим; мы добавили опции для изменения флагов компиляции для работы с различными странными сбоями в различных версиях этих библиотек (или изменения API от одной версии к другой, чем изменения в нашем коде), мы добавили обходные пути для того, что некоторые библиотеки BLAS используйте интерфейс C, а некоторые используют интерфейс Fortran, поэтому, хотя они теоретически реализуют одну и ту же библиотеку, они делают несколько вещей несколько иначе, и так далее. Вы не можете заранее предугадать все это, и ему также необходимо документировать, чтобы пользователи могли определить, какие параметры установить.

О, и установщики действительно больно, потому что они обычно зависят от ОС (если только это не оболочка script и вам нужен CygWin), а места для установки, как правило, зависят от ОС и т.д., Это еще одна область, которая займет много времени - либо при создании хорошего установщика, либо в поддержке пользователей в настройке вручную.

Настройка кросс-компиляции, по моему опыту, стоит того, что стоит проблемы (по крайней мере для случая с Linux-Windows, не уверен в MacOS/X) - намного проще, чем пытаться сохранить несколько разных систем сборки в синхронизации.

В качестве альтернативной перспективы существует опция, которую OpenFOAM-проект использует для своей довольно большой библиотеки С++, которая должна распространять ее вместе с "одобренным" компилятором g++ и пакетами для всех остальных компонентов, чтобы они не приходится беспокоиться о разных компиляторах и т.д. Но это действительно работает только на одной ОС. Я предполагаю, что версия Windows/MacOSX предназначена для предоставления предварительно настроенных изображений VMWare. В некоторых случаях есть что сказать об этом....

Ответ 3

Используйте autotools, большинство пользователей знакомы с ними (то есть они знают, что нужно выполнить. /configure & make && make install)

Создайте .tar.gz с make dist, протестируйте его, убедитесь, что он компилируется и работает более чем в одной системе.
Для Linux/Unix/Cygwin не предоставляйте установщиков... source tar.gz более точен. В любом случае каждый дистрибутив Linux имеет свои собственные правила упаковки, и большинство из них знают, как использовать сборки autoconf, у пользователей могут быть 32 или 64-битные системы или даже работать по PPC или Sparc - так что не беспокойтесь.

Возможно, стоит создать один deb или rpm для большинства популярных систем, но не более того.
В Windows (родной, а не cygwin) предоставляются двоичные файлы. Установка Migw + auto довольно болезненна, и пользователи Windows, как правило, более "следуют", а затем "следующие", а затем "wget/tar/configure/make/make-install" пользователи. "Предоставьте почтовый индекс или какой-нибудь установщик, есть некоторые установщики FOSS там.

Помните, что у слабых пользователей Windows по умолчанию нет zlib или openssl... Поэтому вам нужно отправить их с вашим пакетом.

О CMake...

Если вы ориентируетесь в основном на платформу Windows или вы готовы поддерживать MSVC, то, вероятно, вы должны ее рассмотреть. В противном случае, autotools обеспечивают хорошее распределение и создают альтернативу.