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

Ответ 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 обеспечивают хорошее распределение и создают альтернативу.