Общепринятой аксиомой в сообществе 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 поставляется со встроенными инструментами компилятора в течение многих лет, и от них могут быть тонкие скрытые зависимости.
Сборка из исходников считается вредной
В заключение скажу немного по касательной: делать компиляцию чего-либо пользователем стандартной практикой — в большинстве случаев ужасный опыт.
Тем не менее, есть куча законных случаев для сборки из исходного кода. А именно:
- применить изменения кода (дух),
- настроить параметры оптимизации компилятора,
- чтобы отключить функции для меньших двоичных файлов,
- для отключения функций, которые имеют измеримое влияние на производительность — для которых аварийного выключателя во время выполнения недостаточно, чтобы устранить эти последствия, и
- ориентироваться на новую платформу.
Если приведенные выше случаи не применимы, то компиляция из исходного кода не должна быть необходимой: альтернативы существуют, и их можно реализовать. Если требуется сборка из исходного кода, либо вы плохо поработали как разработчик — например. не разрешая достаточную конфигурацию во время выполнения — или у вас недостаточно ресурсов для запуска проекта — например. из-за невозможности предоставить бинарные пакеты для распространенных платформ.
Меня больше всего раздражают программные пакеты, функциональность которых зависит от библиотек, выбранных во время сборки с помощью переключателей конфигурации. Подобные программные пакеты действительно проблематичны, когда приходит время предлагать бинарные пакеты: «какие опции вы должны включить?» или «как пользователь сможет выбрать более экономичную установку?». Существуют механизмы, позволяющие изменять зависимости во время выполнения (подумайте о динамически загружаемых подключаемых модулях), но зачастую их гораздо сложнее реализовать, чем просто настроить переключатели.
В следующий раз, когда вы скажете пользователю своего программного обеспечения «иди и собери из исходного кода», подумайте, можете ли вы сделать что-то еще, чтобы избежать такой ситуации в будущем.
Если вам понравился этот пост, нажмите на маленькую зеленую кнопку в виде сердечка, чтобы порекомендовать историю!