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

Question

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

Answer 3

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

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

Answer 4

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

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

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