Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Это какая-то крайне извращенная технология. Если параметрами библиотеки являются известные, фиксированные свойства целевой системы — они должны быть документированы и там, и там, и никаких сложностей с заданием значений возникать не должно.
Очевидно, параметры могут быть неизвестны, но, возможно, документированы.
ЕМ> Если же библиотеке нужна "тонкая настройка" на целевую платформу (какие-то нюансы аппаратной или программной конфигурации, производительности и т.п.), то конфигуратор должен быть сделан так, чтобы собрать его кросс-средствами было предельно просто, в идеале — в одну командную строку.
Откуда кросс-средствам знать параметры целевой платформы? Вы не забывайте, что сами кросс-средства тоже иногда собираются из исходников.
ЕМ>Ну и так заморачиваться со статической конфигурацией имеет смысл лишь в том случае, когда динамическая (при инициализации библиотеки уже на целевой платформе) обходится неоправданно дорого.
Иногда это просто не возможно.
ЕМ>То есть, проблема снова не в кросс-компиляции, как таковой, а в явной кривизне софта, ей подвергаемого.
Задача: сделать средство кросскомпиляции, которое будет работать для любых целевых архитектур, даже ещё не созданных. Как такую задачу решить?
BFE>>вам хотелось бы увидеть реальные строки из моей рабочей системы?
ЕМ>Да хоть бы пути с измененными именами примерно той же длины, чтобы стало более-менее понятно — реальная там необходимость в длинных путях, или просто причуда.
/asdf/asd/qwe/asd_asdfghjklas/asdfghjklh/adadadada.aaaa.aaaaaaaaaaa/qwertyuouy/sdf/asd_werty/asd/ljutdbms/aassdfgta/xdrtyhbvfgd/ddd.sdfrdgrdg.dd/dft.sgsgsgsgsg/sss_sdfrtgddfvxcdAndhjdjdkdkdkdlAtffhjkklsbddyecetdDuringhdjdlddydbLimitdsSgfhkfifnSkfdkfjjwqwaInvariant.cpp
И это при том, что были предприняты усилия по сокращению длины имён каталогов: многие из имён каталогов были по 40-50 символов длиной, да и вложенность была поболее.
BFE>>Просто ограничение в винде накладывают естественным образом ограничения на пользователей, а вот начинаешь что-нибудь развесистое из другой системы копировать и облом.
ЕМ>Вот и вопрос, отчего оно в той системе такое развесистое. Скажем, насколько часто в программах на C++ встречаются имена, полная запись которых (со всеми namespace-ами, именами классов и прочим) дотянет хотя бы до 200 символов?
Не часто, но встречается.
BFE>>Все исходники открыты, можете заняться.
ЕМ>А мне оно на хрена? Я предпочитаю называть каталоги именами разумной длины, чтоб путь, по возможности, не превышал 100-120 символов.
Так я о том и говорю, никто это чинить не будет.
BFE>>Это не будут чинить по другой причине: поставил WSL и нет таких проблем.
ЕМ>А по какой причине не чинили пятнадцать лет до появления WSL?
Считали извращением кросскомпилировать исходники линаксав не из под линаксов.
BFE>>попробуйте убедить какого-нибудь линуксоида устанавливать библиотеки не в систему, а домашний каталог.
ЕМ>Тогда, наверное, стоило бы при обсуждении проблем с кросс-компиляцией оговаривать, что бОльшая их часть возникает от кривизны рук на разных уровнях. 
Почему именно рук?
BFE>>Ну раз должны, тогда надо назначить ответственного. Есть кандидаты?
ЕМ>Ну а кто там в Linux-сообществе отвечает за разработку стандартов и рекомендаций? Вот их и назначать.
Не-не-не. Вам дают продукт как есть: не хотите — не пользуйте.
ЕМ>Если это делается грамотно и корректно в рамках поддерживаемых архитектур — пусть хоть к char'у приводят, но пишут в документации: "библиотека не поддерживает архитектуры, размер указателей в которых превышает sizeof (char)".
Вполне возможно, что где-то в недрах исходников, в комментарии так и написано. И что?
ЕМ>Почти в любой статье о "Unix Philosophy" упоминается о portability over efficiency. А как добиться portability без compatibility?
portability без compatibility — это легко. Это вообще ортогональные понятия.
