Общепринятой аксиомой в сообществе BSD является то, что компилятор C принадлежит базовой системе. «Так обстояли дела с незапамятных времен, и они определяют то, как устроены системы BSD», — говорится в предложении.

Но почему? Что делает «наличие компилятора в базе» системой BSD? Почему компилятор является необходимой частью базовой системы? Подожди, что ли? Можем ли мы его убрать?

В этом посте, который является продолжением ответа, который я написал в ветке списка рассылки Отказ от поддержки GDB в дереве на freebsd-arch, я хотел бы изучить возможные ответы на эти вопросы.

Почему компилятор в базовой системе?

Традиционно системы BSD всегда требовали присутствия компилятора, поскольку сборка из исходного кода была единственным способом поддерживать ОС в актуальном состоянии и настраивать функции ядра. , а также для установки стороннего программного обеспечения из портов или pkgsrc.

Не существовало каких-либо приличных механизмов обновления только бинарных пакетов для базовой ОС, ядро ​​не было модульным и не имело достаточных настроек sysctl(8), а инструменты и репозитории для установки бинарных пакетов были очень примитивными и негибкими.

Случай с FreeBSD

Ситуация значительно изменилась за последние несколько лет, особенно для платформ FreeBSD Tier 1: теперь можно запускать полнофункциональную, современную систему, соответствующим образом настроенную для имеющейся машины, со всевозможными сторонними приложениями. сторонние пакеты установлены без необходимости что-либо компилировать.

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

В наши дни FreeBSD больше не нужно поставлять компилятор по умолчанию. (Однако вопрос о том, следует ли это сделать, — это отдельная история.)

На самом деле, как давний пользователь NetBSD, я был немного удивлен, когда пришел к FreeBSD, потому что обнаружил, что инструменты компилятора не являются обязательными. В NetBSD инструменты компилятора всегда были частью набора comp.tgz, отдельного от base.tgz. Оба собираются из исходного дерева в унисон, но при установке новой машины вы можете легко отказаться от распаковки comp.tgz. Я долгое время запускал бережливые серверы без инструментов компиляции (собирая свои пакеты в другом месте с помощью pkg_comp), и все было в порядке.

Оставим компилятор в базе

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

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

Учитывая вышеизложенное, я как разработчик системы не хочу заморачиваться о хитрых точках интеграции компилятора со сложным деревом исходников ОС. Эти детали лучше оставить небольшой группе экспертов по компиляторам, которые могут и будут делать правильные вещи для ОС в целом. Вам нужно только увидеть суперпростые функции кросс-компиляции NetBSD, предлагаемые build.sh, чтобы по-настоящему оценить то, что я имею в виду.

По этой теме я предлагаю посмотреть следующую презентацию, в которой приводится довод в пользу монолитного дерева исходных текстов, в котором цепочкой инструментов управляет небольшая команда увлеченных экспертов:

Вероятно, следует сделать установку инструментов компилятора необязательной: при установке FreeBSD из бинарного дистрибутива у пользователя должна быть возможность не устанавливать какие-либо инструменты компилятора. Интересно, каковы будут последствия этого, потому что FreeBSD поставляется со встроенными инструментами компилятора в течение многих лет, и от них могут быть тонкие скрытые зависимости.

Сборка из исходников считается вредной

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

Тем не менее, есть куча законных случаев для сборки из исходного кода. А именно:

  • применить изменения кода (дух),
  • настроить параметры оптимизации компилятора,
  • чтобы отключить функции для меньших двоичных файлов,
  • для отключения функций, которые имеют измеримое влияние на производительность — для которых аварийного выключателя во время выполнения недостаточно, чтобы устранить эти последствия, и
  • ориентироваться на новую платформу.

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

Меня больше всего раздражают программные пакеты, функциональность которых зависит от библиотек, выбранных во время сборки с помощью переключателей конфигурации. Подобные программные пакеты действительно проблематичны, когда приходит время предлагать бинарные пакеты: «какие опции вы должны включить?» или «как пользователь сможет выбрать более экономичную установку?». Существуют механизмы, позволяющие изменять зависимости во время выполнения (подумайте о динамически загружаемых подключаемых модулях), но зачастую их гораздо сложнее реализовать, чем просто настроить переключатели.

В следующий раз, когда вы скажете пользователю своего программного обеспечения «иди и собери из исходного кода», подумайте, можете ли вы сделать что-то еще, чтобы избежать такой ситуации в будущем.

Если вам понравился этот пост, нажмите на маленькую зеленую кнопку в виде сердечка, чтобы порекомендовать историю!