Boost 1.78.0 и MinGW-w64 x32 GCC 10+

На днях попытался собрать компилятором MinGW GCC 10.3.0 x32 Boost 1.77 и я упёрся в issue наподобие https://github.com/boostorg/build/issues/724 . Собственно, я сначала подумал, что и пожалуйста, не нужно и забил. Но потом вышел новый Boost 1.78 и я снова упёрся в эту проблему.

Внимательный читатель сразу заметит - зачем я вообще собираю x32 приложения в 2021 году? На то две причины: у меня есть небольшой парк старых машин на которые иногда хочется собраться, а вторая - историческая, как-то привычно и удобно на нём сидеть, программировать под него всё ещё можно. Но в этот раз, всё пошло немного наперекосяк.

Тем кому лень читать дальше, сообщу сразу - всё можно легко собрать, если вместо обычного "b2 toolset=gcc" использовать

b2 toolset=gcc address-model=32

Но это, правда странно и этот способ мне подсказали в самих репозиториях.

Перво-наперво, я покопался в недрах boost.build. Если что - она rule-based и разобраться в правилах, честно говоря, для меня оказалось адской болью, потому что они тьюринг-полны, а комментариев в Jam-файлах буста раз-два и обчёлся. Собственно, я в итоге, не смог разобраться и создал issue, после чего отправился заниматься своими делами. В issue мне посоветовали поискать какая библиотека собственно всё ломает, и, путём выпиливания либ в лоб, спустя полчаса оказалось два факта:

• Почему-то build пытается собрать сразу x32 и x64 билды компилятором, который в x64 по определению не может (но x32 собирается)
• Проблема в boost.log,  именно там что-то происходило странное.

В итоге, я пошёл в boost.log, где это решение мне и сообщили. Увы, мейнтейнеры после этого вступили в короткую перепалку, суть которой в итоге заключалась в том, где и к кому действительно эта проблема относится, и, по сути, проблема осталась. С b2 toolset=gcc этим компилятором Boost пока собрать нельзя (хотя x64 вариант прекрасно собирает оба варианта, так что это вообще некритично, как оказалось).

В принципе, ковыряние с этим заняло у меня часов 4-6, что, не так уж много.

 Если подумать над возникшей ситуацией, грустно другое:

• Такое ощущение, что и boost.build, и boost.log поддерживают на плаву два человека, по одному на утилиту и библиотеку. Это грустно, ибо поддерживать так качество очень тяжело. За всё время никто кроме них двоих на issue не обратил внимание. Им огромное спасибо, но всё же, есть такое ощущение что Boost не то чахнет, не то не получает должную поддержку.
• boost.build имеет колоссальную сложность и нулевые инструменты отладки. Отладочная печать мне не объяснила ничего. Лично я так и не понял что случилось. Почему зависимость становится рекурсивной? Неясно. Зачем мешать Python, Prolog и XML в одном файле?  Неясно. Как работают и применяются правила? Честно говоря, толком в существующей документации не удалось разобраться. Даже синтаксис вызывает огромные вопросы. Впрочем, глядя на зачатки CMake в исходниках Boost есть шанс, что в будущем станет проще и boost.build уйдёт из эксплуатации. Я, в любом случае, не видел её применения нигде кроме Boost. 

С другой стороны, так ли это важно, глядя на другие языки? Не уверен.