Здравствуйте, Евгений Музыченко, Вы писали:
BFE>>Очевидно, параметры могут быть неизвестны, но, возможно, документированы.
ЕМ>Мне, наоборот, очевидно, что сама идея библиотеки с неизвестными параметрами,
Параметры известны, вручную их редактировать долго, но можно.
BFE>>Вы не забывайте, что сами кросс-средства тоже иногда собираются из исходников.
ЕМ>Если они собираются исключительно для использования там же, где собирались — значит, их сборка не имеет никакого отношения к "кросс"-технологиям.
Имеет. Для кросс компиляции нужен компилятор, который умеет в эту кросскомпиляцию. А где его взять? Правильно — собрать из исходников.
ЕМ>Если же там предусмотрена возможность сборки в одной системе (хостовой), а использования — в другой (целевой), то должна быть возможность описать целевую систему явно (в идеале — запуском в ней скрипта, который сформирует набор параметров, который можно будет передать системе сборки в готовом виде).
Ну так и делается. Только вот параметров там столько, что одна поверхностная конфигурация без вникания в параметры, а только по выбору групп параметров, занимает несколько часов.
ЕМ>Принципиально кросс-компиляция ничем не отличается от локальной компиляции — результат полностью определяется набором средств и их настройкой.
Ага. Теоретически теория совпадает с практикой.
ЕМ>Мне одному кажется, что здесь видна явная тенденция к удлинению имен сверх разумной, или еще кто-нибудь так считает?
Видна, не видна, важно, что gcc такое не тянет.
ЕМ>Как я понимаю, до сих пор считается извращением кросс-компилировать любые линуксовые исходники вне системы, где будет работать софт (упомянутый true linux way"). А многие ли понимают, что это тупиковый путь? Чем это принципиально отличается от использования литералов вместо именованных констант, глобальных переменных вместо параметров функций и т.п?
Это вопрос не ко мне.
BFE>>Вам дают продукт как есть: не хотите — не пользуйте.
ЕМ>А какие соображения поддерживают оставление продукта в таком состоянии? 
Иногда, для заработка денег, иногда из за нехватки времени. А в целом я не знаю.
ЕМ>Я б такую библиотеку использовал лишь в крайних случаях, когда без нее совсем никак. Насколько часто такое бывает?
Зависит от политики компании. Если политика: "ничего своего не пишем, если уже можно взять написанное", то тащат всё подряд не взирая на качество кода.
Если политика: проверяем всё, так как от нашего кода зависит безопасность, то даже из C-шного стандартного printf могут выкинут функциональность вывода чисел с плавающей точкой, так как такая конвертация не однозначна и занимает много места.
ЕМ>Я еще могу понять, когда такое используется "чиста у себя" — "как-то получилось, и хрен с ним". Но получается, что такие библиотеки регулярно включаются в массовые продукты, и это считается вполне нормальным.
А вы думаете, что есть множество людей, которым нечего делать и которые сидят и пишут код за просто так? Вот что есть — то и имеем.
BFE>>portability без compatibility — это легко.
ЕМ>Compatibility — это ж не только о двоичной совместимости. Это совместимость и по идеологии, набору функций, файловым системам, ключевым утилитам, их параметрам и функциональности и прочему. Если в линуксе на какой-то платформе не будет bash'а или совместимой с ним оболочки, а все скрипты будут переписаны на другой язык — это будет еще линукс, или уже что-то другое?
Конечно линукс. У bash'а есть несколько альтернатив, штук 5 или больше.
А у Windows, например, есть несколько альтернативных графических интерфейсов. И что? Это уже не Windows?
ЕМ>Ну и сама идея portability автоматически подразумевает, что хотя бы первая сборка ядра и основного софта под новую платформу будет проходить в другой системе.
Ну почему же? Человека, который ратует за то, чтобы править все параметры вручную, не затруднит прямо в кодах набивать программки. Взгляните, например, на мой никнейм. ....
ЕМ> Тут бы и сообразить, что описание целевой системы в явном виде должно быть правилом, а не исключением для таких случаев.
Опять "должно"? Я уже советовал назначить ответственного...
