История коммита: добавляем новую опцию в Doxygen

Я использую Doxygen для генерации документации для одной из своих библиотек, libSDL2pp. Однажды, просматривая оную документацию я наткнулся на интересный факт: мой email в сгенерированном HTML был изменён до неузнаваемости, очевидно в целях помешать спам-ботам собирать адреса. Меня такое поведение категорически не устраивало, а в Doxygen не было настройки чтобы его отключить, поэтому я решил её добавить.

Вот так выглядит изменённый email:

То же в HTML (отформатировано для читаемости):

<a href="#" onclick="location.href='mai'+'lto:'+'amd'+'mi'+'3@a'+'md'+'mi3'+'.r'+'u'; return false;">
	amdmi<span style="display: none;">.nosp@m.</span>3@am<span style="display: none;">.nosp@m.</span>dmi3.<span style="display: none;">.nosp@m.</span>ru
</a>

Отступление: в начале я как-то не осознал что <span>ы вставляемые в адрес должны быть невидимы из-за display: none, но этот встроенный стиль не работал из-за заголовка Content-Security-Policy у меня на сервере. Это отдельная проблема в Doxygen которую также нужно исправить.

Python 3.11 в портах FreeBSD

Месяц назад я добавил в порты FreeBSD Python 3.11 (alpha2). Это продолжение моей работы над поддержкой (пререлиза) Python 3.10, и, как и с предыдущей версией, целью является дать возможность заинтересованным поиграть с новой версией языка, мантейнерам проверить совместимость своих портов, а разработчикам - своего кода. Хочу рассказать про статус поддержки и про то как был портирован Python 3.10.

Статус Python 3.10

Поддержка Python 3.10 пока далека от полноценной, так как эту версию языка пока не поддерживают многие критичные пакеты (в основном по причине устаревших версий в портах, но есть и случаи отсутствия поддержки в upstream). Самый критичный - math/py-numpy (обновление висит с 4 ноября). От него зависит большое количество других портов, и все они, соответственно, пока не доступны под Python 3.10.

Пакетопригодность: нежелательные флаги компилятора

Иногда возникает желание добавить в сборку по умолчанию несколько полезных флагов компиляции типа -Werror (чтобы гарантировано исправлять предупреждения компилятора) и -march=native (чтобы собирать более эффективные бинарники). На деле это сулит проблемы при создании пакетов.

Писать большие посты трудно

Работа над азбукой переносимости как-то подзаглохла, и причина тому скорее всего в попытке откусить слишком большой кусок, а именно написать сразу огромную статью, да ещё и на двух языках. Сейчас две такие статьи в черновиках, работы до публикации они требуют ещё много, и это демотивирует. Поэтому пробую сменить формат на небольшие посты. Это не помешает собрать их потом в книгу, а писать станет проще.

Помимо этого, думаю над изменением названия. Всё-таки тема ближе к опакечиванию чем к переносимости (хотя это и связанные вещи). Поэтому на ум приходит что-то ближе к “Руководство по переносимости и пригодности к опакечиванию”/“A Guide To Portability And Packaging Friendliness” (РППО/GPPF).

Азбука переносимости: именование проектов

Удивительно, но можно насоздавать проблем для переносимости и пакетирования ПО проекта даже не написав ни строчки кода, а просто неудачно его назвав.

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