Здравствуйте, zx zpectrum, Вы писали:
ZZ>По сути-то необходимо соблюсти всего лишь два нюанса:
ZZ>1. gcc/clang тащит с собой кодогенерацию под все известные триплеты "аритектура-ос-libc";
Clang (а точнее llvm) так и работает вообще то. Ну а в gcc в принципе тоже можно организовать что-то подобное — там единственное отличие в том что традиционно плодят отдельные бинарники (да ещё и распространяемые отдельно) со своим именем под каждый триплет. Но можно накачать все нужные в одну папку и сделать простейший скриптик в несколько строк, который будет выбирать нужный по параметру.
ZZ>2. gcc/clang не имеет никаких умолчаний: всё надо передавать явно. Каждый define, каждый путь к директориям с заголовочными файлами и библиотеками, каждый флаг компиляции.
Да вообще то так по сути и работает. Если передашь путь через -I или -L, то в начале все файлы будут искаться именно там. И любой макрос можно предопределить через -D.
Так что в принципе к компиляторам на самом деле нет особых вопросов, они готовы к любым раскладам. Не готовы авторы библиотек и главное авторы скриптов сборки...
ZZ>Однако, подобный тулчейн будет ломать все исторически сложившиеся практики, и по-моему именно поэтому никогда не станет стандартным.
Именно, боюсь эта проблема для C/C++ никогда не будет решена из-за инерции. Но меня это совсем не беспокоит, т.к. на замену C++ уже пришёл Rust (который кстати с помощью LLVM компилирует). А в нём правильные практики организации сборки были заложены изначально, так что сейчас уже стали нормой для сообщества.