LINUX.ORG.RU

Нужна услуга за вознаграждение - linux, cygwin


1

3

Мне нужен работающий кросс-компилятор. Как его сделать - есть статья: http://waqur.livejournal.com/468891.html с автором связаться не могу. Готов заплатить. Флуд приветствуется. Реальные предложения - в личку. у меня в процессе следования статьи вылезают ошибки, как бороться не знаю.

Ответ на: комментарий от red_eyed_peguin

autoconf простой и понятный. libtool при всей его гомосексуальной сущности просто не имеет замены, так что трах с ним ненавязчиво переностится абсолютно на все инструменты сборки. automake для простых проектов прост как пробка.

бугога

Главный аргумент за автотулзы: это стандарт де-факто.

да фтопку такой «стандарт»

Любое дите осилит сборку с кастомными флагами компиляции

Пользователи не должны заниматься сборкой. Сбоочная система должна облегчать жизнь программисту в первую очередь, autotools этого не делает.

Reset ★★★★★
()
Ответ на: комментарий от Reset

autotools облегчает жизнь интегратора, для чего в общем и предназначена. Все остальные только создают дополнительные трудности. cmake в общем, еще можно терпеть.

slapin ★★★★★
()
Ответ на: комментарий от slapin

интегратора

Это кто?

Все остальные только создают дополнительные трудности

Можно пример дополнительных трудностей?

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

интегратор ~= считай дистрибутивоклепатель.

ковыряние разномастных файлов scons очень анноит, когда тебе надо много пакаджей собрать. autotools и cmake достаточно однородны, хотя в cmake чаще встречаются странные вещи, из-за того, что оно из коробки многих тестов не умеет, или ее велосипедят чаще, я не знаю. в scons всегда сплошные велосипеды - каждый изобретает новый несовместимый с другими способ запустить pkgconfig, libtool, при этом хахардкодив пути, прописав жестко -I/usr/include, и прочее... то есть делают свою билд-систему, используя scons как API, что само по себе интересно, но ад для интегратора. Поэтому если я вижу autotools, в 99% случаях все работает и собирается, в 1% - делается пара стандартных действий в известных уже местах. С scons каждый раз все по-новому.

slapin ★★★★★
()
Ответ на: комментарий от slapin

прописав жестко -I/usr/include

1) это легко поправить 2) разве autotools этого не позволяют сделать? Чего только люди не захардкодят...

ковыряние разномастных файлов scons очень анноит, когда тебе надо много пакаджей собрать

Возможно, но где ты взял много кривых проектов на scons? А дистрибутивостроители один раз решают это проблему, потом патч из версии в версию мигрирует.

Но дело даже не в этом. От проблем разрабов мы плавно перешли к совершенно другим проблемам. Перефразируя: плевать на желание программистов, главное чтобы мейнтейнеру было удобненько.

Можно пример проекта который сложно собрать?

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

Перефразируя: плевать на желание программистов, главное чтобы мейнтейнеру было удобненько.

для программистов автотулзы вполне удобны, если их освоить. Это для юзеров пытки и мучение наблюдать каждый раз выхлоп configure и ждать, когда он завершится :)

Harald ★★★★★
()
Ответ на: комментарий от Reset

Сбоочная система должна облегчать жизнь программисту в первую очередь, autotools этого не делает.

Таким «прогромиздам-неосиляторам» прямая дорога в MSVS/Dephli — «кодить мышкой».

red_eyed_peguin
()
Ответ на: комментарий от true_admin

Перефразируя: плевать на желание программистов, главное чтобы мейнтейнеру было удобненько.

Система сборки выбирается и настраивается один раз. Собирать получившийся продукт потом придется много кому. Иными словами, если программист потратит 8 часов на нормальную систему сборки, это позволит 10 мейнтейнерам сэкономить гораздо больше времени на чтение мануалов. Мне вот в те редкие моменты, когда надо что-то собрать ручками в самую последнюю очередь хочется связываться с инопланетными cmake'ами, где каждая софтина норовит изобрести свои названия ключей для одних и тех же параметров конфигурации.

red_eyed_peguin
()
Ответ на: комментарий от red_eyed_peguin

Традиционное красноглазое бросание из крайности в крайность. Зачем? cmake же есть!

Reset ★★★★★
()
Ответ на: комментарий от red_eyed_peguin

Иными словами, если программист потратит 8 часов на нормальную систему сборки

И еще по 8 часов на добавление каждого нового модуля или на рефакторинг структуры проекта. Нафиг нафиг!

это позволит 10 мейнтейнерам сэкономить

Это все решается предоставлением основных ручек для майнтейнеров. Что тебе надо? Выбор install prefix'а? Есть оно уже из коробки. Выбор ключей и компиялтора? Опять же из коробки есть. Всё что надо и так уже имеется.

Reset ★★★★★
()
Последнее исправление: Reset (всего исправлений: 1)
Ответ на: комментарий от red_eyed_peguin

и еще расскажи как использование autocrap'а в так называемом gtk-стеке экономит время майнтейнерам, которые собирают это в не-юникс системах

Reset ★★★★★
()
Ответ на: комментарий от Reset

и еще расскажи как использование autocrap'а в так называемом gtk-стеке экономит время майнтейнерам, которые собирают это в не-юникс системах

К примеру, кросскомиляцией из уютненького линакса.

red_eyed_peguin
()
Ответ на: комментарий от red_eyed_peguin

Понятно, то есть никак не экономит.

Reset ★★★★★
()
Ответ на: комментарий от Reset

И еще по 8 часов на добавление каждого нового модуля или на рефакторинг структуры проекта. Нафиг нафиг!

даже такой тупой нуб как я с лёгкостью добавляет туда новые модули. Неужели это для тебя так сложно?

drBatty ★★
()
Ответ на: комментарий от drBatty

А то. Каждый раз читать километровые маны к десятку утилит и править десяток файлов, вместо чтения одного мана к одной утилите и правки одного файла.

Reset ★★★★★
()
Последнее исправление: Reset (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.