Здравствуйте, B0FEE664, Вы писали:

BFE>Часто вместе с библиотекой идёт скрипт, который, например, может скомпилировать тестовый пример, запустить его и по выданному результату добавить тот или иной define в config.h, а этот config.h потом, на этапе компиляции библиотеки, подхватывается и используется. Так вот эту конфигурацию надо проводить на target системе, а для этого там нужно установить компилятор... Ну или потратить несколько дней рассматривая код и подбирая подходящие define'ы.

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

То есть, проблема снова не в кросс-компиляции, как таковой, а в явной кривизне софта, ей подвергаемого.

BFE>вам хотелось бы увидеть реальные строки из моей рабочей системы?

Да хоть бы пути с измененными именами примерно той же длины, чтобы стало более-менее понятно — реальная там необходимость в длинных путях, или просто причуда.

BFE>Просто ограничение в винде накладывают естественным образом ограничения на пользователей, а вот начинаешь что-нибудь развесистое из другой системы копировать и облом.

Вот и вопрос, отчего оно в той системе такое развесистое. Скажем, насколько часто в программах на C++ встречаются имена, полная запись которых (со всеми namespace-ами, именами классов и прочим) дотянет хотя бы до 200 символов?

BFE>Все исходники открыты, можете заняться.

А мне оно на хрена? Я предпочитаю называть каталоги именами разумной длины, чтоб путь, по возможности, не превышал 100-120 символов.

BFE>Это не будут чинить по другой причине: поставил WSL и нет таких проблем.

А по какой причине не чинили пятнадцать лет до появления WSL?

BFE>попробуйте убедить какого-нибудь линуксоида устанавливать библиотеки не в систему, а домашний каталог.

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

BFE>Ну раз должны, тогда надо назначить ответственного. Есть кандидаты?

Ну а кто там в Linux-сообществе отвечает за разработку стандартов и рекомендаций? Вот их и назначать.

BFE>Да мало ли любителей переопределять unsigned int в UI32 ? Или приводить указатель на структуру к int'у?

Если это делается грамотно и корректно в рамках поддерживаемых архитектур — пусть хоть к char'у приводят, но пишут в документации: "библиотека не поддерживает архитектуры, размер указателей в которых превышает sizeof (char)".

ЕМ>>Почти в любом описании идеологии *nix-систем подчеркивается идея совместимости софта. Врут?

BFE>Да где вы такое читали?

Почти в любой статье о "Unix Philosophy" упоминается о portability over efficiency. А как добиться portability без compatibility?