Может ли autotools создавать многоплатформенные make-файлы

Question

У меня есть проект плагина, который я разрабатывал в течение нескольких лет, когда плагин работает с многочисленными комбинациями [первичная версия приложения, версия сторонней библиотеки, 32-разрядная и 64-разрядная версии ]. Есть ли (чистый) способ использовать autotools для создания одного файла makefile, который создает все версии плагина.

Насколько я могу судить по просмотру документации autotools, самое близкое приближение к тому, что мне нужно, - иметь N независимых копий проекта, каждый со своим собственным make-файлом. Это кажется немного субоптимальным для тестирования и разработки, поскольку (а) мне нужно постоянно распространять изменения кода во всех разных копиях и (б) существует много потерянного пространства для дублирования проекта столько раз. Есть ли способ лучше?

EDIT:

Я качение своего собственное решения на некоторое время, когда у меня фантазии Makefile и некоторая перл скрипты, чтобы выследить различные версии библиотеки третьих лиц и т.д. Таким образом, я открытые для других решений без автотелов. Для других инструментов сборки я бы хотел, чтобы их было очень легко для конечных пользователей. Инструменты также должны быть достаточно умны, чтобы выследить различные сторонние библиотеки и заголовки без огромных проблем. Я в основном ищу Linux-решение, но тот, который также работает для Windows и/или Mac, будет бонусом.

Answer 1

Насколько я знаю, вы не можете этого сделать. Однако, вы застряли с autotools? Не являются ли CMake или SCons опцией?

Answer 2

Мы попробовали его, и он не работает! Итак, теперь мы используем SCons.

Некоторые статьи на эту тему: 1 и 2

Edit: Некоторые небольшой пример, почему я люблю SCons:

env.ParseConfig('pkg-config --cflags --libs glib-2.0') 

С помощью этой строки кода, добавляемого GLib в среде компиляции (env). И не забывайте, что User Guide, который просто хорош для изучения SCons (вам действительно не нужно знать Python!). Для конечного пользователя вы можете попробовать SCons с PyInstaller или что-то в этом роде.

И по сравнению с make вы используете Python, поэтому полный язык программирования! Имея это в виду, вы можете делать все (более или менее).

Answer 3

Если ваш вопрос:

Могу ли я использовать Autotools на какой-то машины А, чтобы создать единый универсальный Makefile, который будет работать на всех других машинах?

тогда ответ «Нет». Автоутилисты даже не притворяются, что пытаются это сделать. Они предназначены для размещения переносного кода, который определит, как создать рабочий файл makefile на целевой машине.

Если ваш вопрос:

Могу ли я использовать Autotools настроить программное обеспечение, необходимое для работы на разных машинах, с разными версиями основного программного обеспечения, которое мой плагин работает с, плюс различные библиотеки 3-й партии, не говоря уже о 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 и т. Д.). Но это выполнимо.

С другой стороны, я не пытаюсь выпускать один файл makefile, который подходит всем машинам и средам клиентов; есть слишком много возможностей для того, чтобы быть разумным. Но autotools заботится о деталях для меня (и моих пользователей). Все, что они делают:

./configure 

Это проще, чем разработать, как отредактировать make-файл. (О, в течение первых 10 лет программа была настроена вручную, людям было трудно, хотя у меня были довольно хорошие настройки по умолчанию. Именно поэтому я перешел к автоматической настройке: это упрощает люди установки)

---

г-н Fooz прокомментировал:.

Я хочу что-то между ними. В моем случае клиенты будут использовать несколько версий и битов одного и того же базового приложения на одной машине. Меня не беспокоит кросс-компиляция, например, создание двоичных файлов Windows в Linux.

Вам нужна отдельная сборка вашего плагина для 32-разрядной и 64-разрядной версий? (Я бы предположить, - да, но вы могли бы удивить меня.) Так что вам нужно, чтобы обеспечить механизм для пользователя, чтобы сказать

./configure --use-tppkg=/opt/tp/pkg32-1.0.3 

(где tppkg является кодом для пакета третьей стороной, и расположение специфичный для пользователя.) Однако имейте в виду удобство использования: чем меньше таких опций, у пользователя есть, чтобы обеспечить, тем лучше; против этого, не делайте жесткий код вещей, которые должны быть дополнительными, например, места установки. Во что бы то ни стало посмотреть по умолчанию - это хорошо. И дефолт к бойню вещей, которые вы найдете. Возможно, если вы найдете как 32-битные, так и 64-битные версии, тогда вы должны построить и то, и другое, что потребует тщательной сборки. Вы всегда можете повторить «Проверка для TP-пакета ...» и указать, что вы нашли и где вы его нашли. Затем установщик может изменить параметры. Убедитесь, что вы документа в './configure --help', что варианты; это стандартная практика аутсорсинга.

Не делайте ничего интерактивного; скрипт configure должен запускаться, сообщая, что он делает.Скрипт Perl Configure (обратите внимание на заглавную букву - это полностью отдельная автоматическая система настройки) - одна из немногих интерактивно настроенных систем конфигурации (и это, вероятно, главным образом из-за ее наследия; если начать заново, то, скорее всего, -interactive). Такие системы более сложны для настройки, чем неинтерактивные.

Кросс-компиляция жесткая. Мне никогда не приходилось это делать, слава богу.

---

Г-н Fooz также прокомментировал:

Спасибо за дополнительные комментарии. Я ищу что-то вроде:

./configure --use-tppkg=/opt/tp/pkg32-1.0.3 --use-tppkg=/opt/tp/pkg64-1.1.2 

, где было бы создать как 32-разрядные, так и 64-разрядные объекты в одном Makefile для текущей платформы.

Ну, я уверен, что это можно сделать; Я не уверен, что это стоит сделать по сравнению с двумя отдельными сценариями конфигурации с полной перестройкой между ними. Вы, вероятно, захотите использовать:

./configure --use-tppkg32=/opt/tp/pkg32-1.0.3 --use-tppkg64=/opt/tp/pkg64-1.1.2 

Это указывает на два отдельных каталога. Вам нужно будет решить, как вы собираетесь делать сборку, но предположительно у вас есть два подкаталога, например «obj-32» и «obj-64» для хранения отдельных наборов объектных файлов. Вы также разместите свой файл в формате:

FLAGS_32 = ...32-bit compiler options... 
FLAGS_64 = ...64-bit compiler options... 

TPPKG32DIR = @TPPKG32DIR@ 
TPPKG64DIR = @TPPKG64DIR@ 

OBJ32DIR = obj-32 
OBJ64DIR = obj-64 

BUILD_32 = @BUILD_32@ 
BUILD_64 = @BUILD_64@ 

TPPKGDIR = 
OBJDIR = 
FLAGS = 

all: ${BUILD_32} ${BUILD_64} 

build_32: 
    ${MAKE} TPPKGDIR=${TPPKG32DIR} OBJDIR=${OBJ32DIR} FLAGS=${FLAGS_32} build 

build_64: 
    ${MAKE} TPPKGDIR=${TPPKG64DIR} OBJDIR=${OBJ64DIR} FLAGS=${FLAGS_64} build 

build: ${OBJDIR}/plugin.so 

Предполагается, что плагин будет общим объектом. Идея здесь заключается в том, что autotool будет обнаруживать 32-разрядные или 64-разрядные установки для стороннего пакета, а затем делать замены. Макрос BUILD_32 будет установлен в build_32, если потребуется 32-битный пакет и в противном случае останется пустым; макрос BUILD_64 будет обрабатываться аналогичным образом.

Когда пользователь запускает 'make all', он будет сначала строить цель build_32 и цель build_64. Чтобы построить цель build_32, он будет повторно запускать make и настроить флаги для 32-битной сборки. Аналогично, чтобы построить цель build_64, он перезапустит make и настроит флаги для 64-битной сборки. Важно, чтобы все флаги, связанные с 32-разрядными и 64-битными строками, были установлены на рекурсивном вызове make и что правила для создания объектов и библиотек написаны тщательно - например, правило для компиляции источника на объект должно быть осторожным, чтобы поместить объектный файл в нужный каталог объектов - с помощью GCC, например, необходимо указать (в .c.o правила):

${CC} ${CFLAGS} -o ${OBJDIR}/$*.o -c $*.c 

макрос CFLAGS будет включать $ {ФЛАГИ} значение, которое имеет дело с биты (например, FLAGS_32 = -m32 и FLAGS_64 = -m64 , and so when building the 32-bit version, ФЛАГИ = -m32 would be included in the CFLAGS` макро.

невязку l в autotools разрабатывает, как определить 32-битные и 64-битные флаги. Если худшее приходит к худшему, вам придется писать макросы для себя. Тем не менее, я бы ожидал (не исследовав его), что вы можете сделать это, используя стандартные средства из набора autotools.

Если вы не создадите себе тщательно (даже безжалостно) симметричный make-файл, он не будет надежно работать.

Answer 4

Вы когда-нибудь думали использовать один проект с несколькими сборками? если ваш проект Automake осуществляется надлежащим образом (т.е. не так, как GCC)

возможно следующее:

mkdir build1 build2 build3 
cd build1 
../configure $(YOUR_OPTIONS) 
cd build2 
../configure $(YOUR_OPTIONS2) 
[...] 

вы можете передавать различные параметры конфигурации, как включают в себя каталоги и компилятор (кросс-компилятор то есть).

вы можете даже запустить это в одном макияже вызова, запустив

make -C build1 -C build2 -C build3