Могут ли autotools создавать многоплатформенные make-файлы?
-
11-07-2019 - |
Вопрос
У меня есть проект плагина, который я разрабатываю в течение нескольких лет, и он работает с многочисленными комбинациями [версия основного приложения, версия сторонней библиотеки, 32-битная или 32-битная версии].64-битная].Есть ли (чистый) способ использовать autotools для создания единого make-файла, который собирает все версии плагина.
Насколько я могу судить, просматривая документацию по autotools, самое близкое к тому, что мне хотелось бы, — это иметь N независимых копий проекта, каждая со своим собственным make-файлом.Это кажется немного неоптимальным для тестирования и разработки, поскольку (а) мне придется постоянно распространять изменения кода по всем различным копиям и (б) при таком многократном дублировании проекта приходится тратить много места.Есть ли способ лучше?
РЕДАКТИРОВАТЬ:
Некоторое время я разрабатывал собственное решение, в котором у меня есть модный make-файл и несколько скриптов Perl для поиска различных версий сторонних библиотек и т. д.Таким образом, я открыт для других решений, не связанных с автоинструментами.Что касается других инструментов сборки, я бы хотел, чтобы конечные пользователи могли легко их установить.Инструменты также должны быть достаточно умными, чтобы без особых проблем выслеживать различные сторонние библиотеки и заголовки.В основном я ищу решение для Linux, но бонусом будет решение, которое также работает для Windows и/или Mac.
Другие советы
Если ваш вопрос:
Могу ли я использовать автоинструменты на некотором компьютере A для создания единого универсального файла сборки, который будет работать на всех других компьютерах?
тогда ответ - "Нет". Автоинструменты даже не делают вид, что пытаются это сделать. Они разработаны для того, чтобы содержать переносимый код, который определит, как создать работающий make-файл на целевом компьютере.
Если ваш вопрос:
Могу ли я использовать автоинструменты для настройки программного обеспечения, которое должно работать на разных компьютерах, с разными версиями основного программного обеспечения, с которым работает мой плагин, а также с различными сторонними библиотеками, не говоря уже о проблемах с 32-разрядными и 64-разрядными? р>
тогда ответ - "да". Автоинструменты предназначены для этого. Кроме того, они работают на Unix, Linux, MacOS X, BSD.
У меня есть программа SQLCMD (которая предшествует одноименной программе Microsoft на десять и более лет), которая работает с базами данных IBM Informix. Он обнаруживает, что версия клиентского программного обеспечения (называемая IBM Informix ESQL / C, часть IBM Informix ClientSDK или CSDK) установлена, и является ли она 32-битной или 64-битной. Он также определяет, какая версия программного обеспечения установлена, и адаптирует его функциональные возможности к тому, что доступно в поддерживаемом продукте. Он поддерживает версии, которые были выпущены в течение 17 лет. Он настроен автоматически - мне пришлось написать несколько макросов autoconf для функциональности Informix и для нескольких других штуковин (высокое разрешение, наличие / dev / stdin и т. Д.). Но это выполнимо.
С другой стороны, я не пытаюсь выпустить один make-файл, который подходит для всех машин и сред клиентов; слишком много возможностей, чтобы это было разумно. Но autotools заботится о деталях для меня (и моих пользователей). Все, что они делают, это:
./configure
Это проще, чем работать над тем, как редактировать make-файл. (О, в течение первых 10 лет программа настраивалась вручную. Людям было трудно это сделать, хотя у меня были довольно хорошие настройки по умолчанию. Именно поэтому я перешел на автоматическую настройку: это значительно облегчает люди для установки.)
<Ч>Мистер Фуз прокомментировал:
Я хочу что-то среднее. В моем случае клиенты будут использовать несколько версий и битов одного и того же базового приложения на одном компьютере. Я не беспокоюсь о кросс-компиляции, такой как сборка бинарных файлов Windows в Linux.
Вам нужна отдельная сборка вашего плагина для 32-битной и 64-битной версий? (Я бы предположил, что да, но вы могли бы меня удивить.) Поэтому вам нужно предоставить механизм, позволяющий пользователю говорить
./configure --use-tppkg=/opt/tp/pkg32-1.0.3
(где tppkg - это код для вашего стороннего пакета, а местоположение определяется пользователем.) Однако следует учитывать удобство использования: чем меньше таких опций пользователь может предоставить, лучшее; против этого не стоит жестко кодировать вещи, которые должны быть необязательными, такие как места установки. Во что бы то ни стало посмотрите в локациях по умолчанию - это хорошо. И по умолчанию к кусочкам материала, который вы найдете. Может быть, если вы найдете как 32-битную, так и 64-битную версии, вам следует собрать обе - хотя это потребует тщательной разработки. Вы всегда можете повторить " Проверка наличия TP-пакета ... " и укажите, что вы нашли и где вы его нашли. Затем установщик может изменить параметры. Убедитесь, что в « ./ configure --help
» задокументированы параметры; это стандартная практика автоинструментов.
Не делайте ничего интерактивного; скрипт configure должен запуститься, сообщив, что он делает. Сценарий Perl Configure
(обратите внимание на заглавную букву - это полностью отдельная система автоматической настройки) - это одна из немногих оставшихся интенсивно интерактивных систем конфигурации (и это, вероятно, в основном из-за ее наследия; если запускать заново) это, скорее всего, будет неинтерактивным). Такая система
Мы попробовали, и это не сработало!Поэтому мы используем сейчас SCons.
Несколько статей на эту тему: 1 и 2
Редактировать:Небольшой пример, почему я люблю SCons:
env.ParseConfig('pkg-config --cflags --libs glib-2.0')
С помощью этой строки кода вы добавляете GLib в среду компиляции (окружение).И не забывайте Гид пользователя что просто здорово для изучения SCons (вам действительно не обязательно знать Python!).Для конечного пользователя вы можете попробовать SCons с PyInstaller или что-то вроде того.
И по сравнению с make
, вы используете Python, то есть полноценный язык программирования!Имея это в виду, вы можете делать все (более или менее).
Вы когда-нибудь задумывались об использовании одного проекта с несколькими каталогами сборки? если ваш проект automake реализован надлежащим образом (т.е. НЕ как gcc)
возможно следующее:
mkdir build1 build2 build3
cd build1
../configure $(YOUR_OPTIONS)
cd build2
../configure $(YOUR_OPTIONS2)
[...]
вы можете передавать различные параметры конфигурации, такие как каталоги include и компиляторы (т.е. кросс-компиляторы).
вы можете даже запустить это в один вызов make, запустив
make -C build1 -C build2 -C build3