Использование C в общей многоплатформенной среде POSIX

Question

Я пишу инструменты, которые используются в общей рабочей области. Поскольку в этом пространстве работает несколько ОС, мы обычно используем Python и стандартизируем версию, установленную на всех машинах. Однако, если бы я хотел написать кое-что на C, мне было интересно, может ли я иметь приложение, завернутое в скрипт Python, который обнаружил операционную систему и выпустил правильную версию приложения C. Каждая платформа имеет GCC и использует ту же оболочку.

Одна из идей заключалась в том, чтобы скомпилировать C для пользователей ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Другим было просто скомпилировать его для каждой платформы и создать сценарий оболочки для выбора подходящего исполняемого файла.

Есть ли приемлемый/стабильный процесс для этого? Есть ли уловы? Существуют ли альтернативы (при условии абсолютной необходимости использовать собственный C-код)?

Уточнение: задействованы несколько ОС, которые не разделяют ABI. Например. OS X, различные Linux, BSD и т. Д. Мне нужно иметь возможность обновлять код на месте в общих папках и работать с новым кодом более или менее мгновенно. Распространение двоичных или исходных пакетов не является идеальным.

Answer 1

Вы знаете, вы должны посмотреть на статическую связь.

В наши дни у всех нас есть ОГРОМНЫЕ жесткие диски, а несколько дополнительных мегабайт (для переноски libc, а что нет) на самом деле не такая большая сделка.

Вы также можете попробовать запустить приложения в тюрьмах chroot() и распространять их.

Answer 2

В зависимости от вашей системы ОС OS вам может быть лучше создать пакеты для каждого класса системы.

В качестве альтернативы, если все они имеют одну и ту же архитектуру ABI и аппаратного обеспечения, вы также можете скомпилировать статические двоичные файлы.

Answer 3

Кроме того, вы можете использовать autoconf и распространять свое приложение только в исходной форме. :)

Answer 4

Запуск экземпляра интерпретатора Python для выбора правильного бинарного файла будет намного тяжелее, чем вам нужно. Я бы распространил файл shell .rc, который предоставляет псевдонимы.

В/shared/bin вы помещаете различные двоичные файлы:/shared/bin/toolname-mac,/shared/bin/toolname-debian-x86,/shared/bin/toolname-netbsd-dreamcast и т. Д. Затем , в общем общем файле shell .rc вы помещаете логику для установки псевдонимов в соответствии с платформой, так что в OSX он получает псевдоним toolname =/shared/bin/toolname-mac и т. д.

Это не сработает, если вы постоянно добавляете новые инструменты, потому что пользователям необходимо перезагрузить псевдонимы.

Я бы не рекомендовал распространять инструменты таким образом. Тестирование и определение новых сборок инструментов должно занимать достаточно времени и усилий, чтобы дополнительное время, необходимое для распространения инструментов для пользователей, было тривиальным. Кажется, вы оптимизируете, чтобы сократить время распространения. Замена инструментов, которые быстро возникают в живом окружении, слишком подвержена длительному и запутанному времени простоя, если что-то пойдет не так в письменной форме и создаст инструменты, особенно когда возникают полные кросс-платформенные проблемы.