Один из разработчиков OpenBSD опубликовал (http://undeadly.org/cgi?action=article&sid=20100310215559) сообщение, в котором обратил внимание на излишнюю привязанность приложений, использующих Autoconf, к GNU-инструментам, что мешает портированию программ на платформы, в которых в качестве стандартного рабочего окружения не используется инструментарий GNU.
В качестве примера, приводится завязанность некоторых тестов в скриптах configure на наличие в номере версии идентификатора GNU; при оценке возможностей mkdir используются прямые привязки к GNU coreutils; в тесте поддержки архивов ustar просто проверяется наличие gnu-tar. Иными словами, вместо полноценной поддержки других систем, многие тесты при оценке возможностей системного окружения просто полагаются на наличие или отсутствие GNU-make, GNU-bash, GNU-tar, GNU-m4, GNU-mkdir и т.п.
URL: http://undeadly.org/cgi?action=article&sid=20100310215559
Новость: https://www.opennet.ru/opennews/art.shtml?num=25751
т.е. пользоваться мы хотим, а соблюдать лицензию нет? пущай пилят свои фичи, кто-то запрещает?
omg.. ну и где здесь речь о лицензии?
тыкните пальцем, где ее нарушение?
а в чем по вашему состоит соблюдение лицензии? использование тулзы только под переGNUтым линуксом? Оригинально...
а при чем тут нарушения?
тулза сама под гпл и расчитана на гпл.
вот и всё.
хотите пользоваться? пользуйтесь. не хотите? не пользуйтесь.зы:
с таким же успехом можно жаловаться, что под msvc не компилится ядро от бзд.
autotools был задуман как инструмент для написания _портируемых_ приложений. В данном случае привязкой к GNU-окружению портабельность неоправданно ухудшается.
он сам из состава гну-утилит.
и работает на всех тех платформах, что и все эти гну утилиты. не больше и не меньше.1. Together with Automake and Libtool, Autoconf forms the GNU build system.
2. The GNU build system, also known as the Autotools, is a suite of programming tools produced by the GNU project.
3. The GNU build system comprises the GNU utility programs Autoconf, Automake, and Libtool [3]. Other related tools frequently used with the GNU build system are GNU’s make program, GNU gettext, pkg-config, and the GNU Compiler Collection, also called GCC.
http://airs.com/ian/configure/т.е. autoconf - часть GNU build system.
Прочли внимательно? _ДЛЯ СБОРКИ_ онли.
Зачем мне оно лишнее в системе?
>Зачем мне оно лишнее в системе?Есть такое понятие - зависимости и пререквизиты. Если вы их не можете удовлетворить - идете лесом с интересом и ищете себе другую прогу, патчите что вам там удобно и прочая. А автор проги не может проверить что какой-то странный TAR из вон той странной системы будет корркетно работать с его прогой, пардон. Потому что экзотов - много, а автор - один. Более того - гнутый тулчейн и утили спортированы на дофигища разных платформ и систем, так что даже побухтеть про портабельность толком не выйдет. Как максимум про зависимости разве что.
ну они б вместе с таром и гцц выкинули бы.
но тогда требования совсем уж маразмом отдавать станут.
>ну они б вместе с таром и гцц выкинули бы.
>но тогда требования совсем уж маразмом отдавать станут.GNU tar, к слову, никто не выкидывал — BSD tar древнее GNU tar. Но Столлман сотоварищи решили, что их не устраивает лицензия (к слову, у них хватило ума понять, что BSDL не позволяет взять код и перелицензировать по-своему), и сделали своё.
Ну а что касается GCC — стараются. Вон, FreeBSD на LLVM переползает, OpenBSD — на PCC… Процесс долгий и мучительный, но как-то двигается.
>[оверквотинг удален]
>>но тогда требования совсем уж маразмом отдавать станут.
>
>GNU tar, к слову, никто не выкидывал — BSD tar древнее GNU
>tar. Но Столлман сотоварищи решили, что их не устраивает лицензия (к
>слову, у них хватило ума понять, что BSDL не позволяет взять
>код и перелицензировать по-своему), и сделали своё.
>
>Ну а что касается GCC — стараются. Вон, FreeBSD на LLVM переползает,
>OpenBSD — на PCC… Процесс долгий и мучительный, но как-то двигается.
>Вот смотря на все это - думается, что BSD-лицензия и весь проект BSD созданы с одной-единственной целью: оттянуть от FSF/GNU силы (головы, руки) на бесполезную деятельность по повторению уже имеющегося, и дать возможность зохавать хоть какие-то плоды этой деятельности конкретным проприетарщикам. Без отдачи.
>[оверквотинг удален]
>>код и перелицензировать по-своему), и сделали своё.
>>
>>Ну а что касается GCC — стараются. Вон, FreeBSD на LLVM переползает,
>>OpenBSD — на PCC… Процесс долгий и мучительный, но как-то двигается.
>>
>
>Вот смотря на все это - думается, что BSD-лицензия и весь проект
>BSD созданы с одной-единственной целью: оттянуть от FSF/GNU силы (головы, руки)
>на бесполезную деятельность по повторению уже имеющегося, и дать возможность зохавать
>хоть какие-то плоды этой деятельности конкретным проприетарщикам. Без отдачи.Молодой человек, учите историю. BSD существовали до появления GNU/Linux. Собственно, Linux обязан своей популярностью отчасти тому факту, что на BSD в своё время очень сильно наехала AT&T. Пока народ в спешном порядке выкидывал их код — время шло, и те силы, которые могли пойти на развитие BSD, ушли в Linux. Тем не менее BSD выкарабкалось, превратившись в NetBSD, FreeBSD, OpenBSD, Darwin/MacOS X, DragonFlyBSD…
>Молодой человек, учите историю. BSD существовали до появления GNU/Linux.http://lurkmore.ru/Nobody_cares
> Собственно, Linux обязан своей популярностью отчасти тому факту, что на BSD в своё время
Linux своей популярности в основном обязан GNU/FSF, и лично Торвальдсу. BSD (изначально - проприетарщина) нервно курит в сторонке.
>>Молодой человек, учите историю. BSD существовали до появления GNU/Linux.
>
>http://lurkmore.ru/Nobody_cares
>
>> Собственно, Linux обязан своей популярностью отчасти тому факту, что на BSD в своё время
>
>Linux своей популярности в основном обязан GNU/FSF, и лично Торвальдсу. BSD (изначально
>- проприетарщина) нервно курит в сторонке.В первую очередь — им, да. Я поэтому и сказал «отчасти». Насчёт «проприетарщины» — как бред больного человека — молчу.
>В первую очередь — им, да. Я поэтому и сказал «отчасти». Насчёт
>«проприетарщины» — как бред больного человека — молчу.Вот и молчите себе, как бред больного человека.
Net/2 was the basis for two separate ports of BSD to the Intel 80386 architecture: the free 386BSD by William Jolitz and the proprietary BSD/386 (later renamed BSD/OS) by Berkeley Software Design (BSDi). 386BSD itself was short-lived, but became the initial code base of the NetBSD and FreeBSD projects that were started shortly thereafter.
BSDi soon found itself in legal trouble with AT&T's Unix System Laboratories (USL) subsidiary, then the owners of the System V copyright and the Unix trademark. The USL v. BSDi lawsuit was filed in 1992 and led to an injunction on the distribution of Net/2 until the validity of USL's copyright claims on the source could be determined.
!!!!!!!!!!!!!!!!!!! The lawsuit slowed development of the free-software descendants of BSD for nearly two years while their legal status was in question !!!!!!!!!!!!!!!!!!!!!!!!, and as a result systems based on the Linux kernel, which did not have such legal ambiguity, gained greater support.
!!!!!!!!!!!!!!!!!!! In June 1994, 4.4BSD was released in two forms: the freely distributable 4.4BSD-Lite contained no AT&T source, whereas 4.4BSD-Encumbered was available, as earlier releases had been, only to AT&T licensees. !!!!!!!!!!!!!!!
Бздям на добрый десяток (!!!) лет больше чем Linux-ам и какими-то двумя годами - не отмажетесь :P.
человеческой глупости ещё больше
>Вот смотря на все это - думается, что BSD-лицензия и весь проект
>BSD созданы с одной-единственной целью: оттянуть от FSF/GNU силы (головы, руки)
>на бесполезную деятельность по повторению уже имеющегося, и дать возможность зохавать
>хоть какие-то плоды этой деятельности конкретным проприетарщикам. Без отдачи.— слова не мужа, но ребёнка.
Почитай ещё раз лицензию BSDL. Перепиши Xorg, Apache Server, Firefox/Thunderbird под GNU, если идеология у тебя столь сильна — будет истинно-православно.
Зачем? GNU-коммюнити не страдает имбецилизмом ака переписыванием всего под xxDL.
>OpenBSD — на PCC… Процесс долгий и мучительный, но как-то двигается.Более того, если кто-то рискнет по дефолту поюзать его - майнтайнеры и юзеры просто позеленеют. Ибо в портах/репах/whatever есть далеко не все. А вот сборка софта бздунам после данного храброго действа начнет изрядно доставлять. Я бы на это посмотрел, ибо "за что боролись, на то и напоролись".
>>OpenBSD — на PCC… Процесс долгий и мучительный, но как-то двигается.
>
>Более того, если кто-то рискнет по дефолту поюзать его - майнтайнеры и
>юзеры просто позеленеют. Ибо в портах/репах/whatever есть далеко не все. А
>вот сборка софта бздунам после данного храброго действа начнет изрядно доставлять.
>Я бы на это посмотрел, ибо "за что боролись, на то
>и напоролись".Когда допилят llvm - gcc подохнет и в линукс мире.
>Когда допилят llvm - gcc подохнет и в линукс мире.Вот "когда допилят" - тогда и приходите. Тем более, что скорее LLVM станет плагином для GCC. Ну и GCC тоже на месте не стоит, не забывайте, что LLVM кроме x86 толком ничего не умеет.
>Когда допилят llvm - gcc подохнет и в линукс мире.Боюсь что с учетом поддерживаемых GCC платформ - дооооолго ждать придется пока сие станет генерить более качественный код под большинство платформ. Если это вообще когда-нибудь случится. А без этого - я уже освоил один тулчейн, который позволяет мне компилить под кучу разных платформ. И менять его только потому что каким-то корпорасам из яппла неудобна его лицензия - я не собираюсь. Меня его лицензия устраивает, я не вижу нужды зажимать сорс компилера а компилять им можно хоть фирмваре с защитой от чтения, никто и не пикнет. Стало быть для МЕНЯ ограничений там - попросту нет. Кто чувствует себя ущемленным и кому так надо зажопить сорц - тот пусть и дергается. Вот правда их блобы мне и даром не нужны. Не собираюсь закладываться на 1 вендора и прогибаться под него и его блобы - пройденный этап, второй раз на одни и те же грабли я не встану, извините.
>т.е. пользоваться мы хотим, а соблюдать лицензию нет? пущай пилят свои фичи,
>кто-то запрещает?И причём здесь лицензии? И пользоваться не хочется, а приходится: ПО-то стороннее, что в портах живёт, зачастую именно им конфигурится; да и X.Org, к слову, тоже.
Ну, как бы, авторы программ вовсе не обязаны по вашему свистку делать удобно именно вам. Более того - когда особо ретивые бздуны рискнут все-таки поменять $CC на свои конструкции под бздуновой лицензией - их будет ждать очень много интересных открытий по части совместимости и глюков (и совместимости глюков) а также юзежа гнутых расширений в прогах.
>>т.е. пользоваться мы хотим, а соблюдать лицензию нет? пущай пилят свои фичи,
>>кто-то запрещает?
>
>И причём здесь лицензии? И пользоваться не хочется, а приходится: ПО-то стороннее,
>что в портах живёт, зачастую именно им конфигурится; да и X.Org,
>к слову, тоже.Не хочется - не пользуйтесь. Пишите свое.
по-моему вы понятия не имеете о чем говорите.
Эммм. autoconf - это ведь сама по себе гнутая утилита, не?
и? gcc тоже Gnu Compiler Collection, однако, работает и компилирует код под разные платформы, не только GNU/Linux.
так и аутоконф тоже. он часть гнушных утилит.
ставьте всё и работайте. или пишите своё.
>так и аутоконф тоже. он часть гнушных утилит.
>ставьте всё и работайте. или пишите своё.Если бы можно было, доработав autotools и как-то «установив» их, решить все проблемы, это бы давно сделали. Собственно, что было возможно сделать в этом направлении, Marc и его коллеги и сделали, спасибо им огромное за работу, которую они проделали вместо парней из GNU.
Но дистрибутив программы уже использует autotools, и с этим портирующему приходится мириться.
>Если бы можно было, доработав autotools и как-то «установив» их, решить все проблемы, это бы давно сделали.ну конечно! проще поплакаться про гну/тар пару десятков лет.
и ни в коем случае его не устанавливать!!!! это же гну!
autoconf способствовать портированию программ, Марка возмущает не лицензмя autoconf, а то что тесты, например, проверяют tar GNU тогда работаем, если нет то вываливаемся с ошибкой, хотя tar есть и нужный функционал тоже
Я понимаю, Марк мог бы сделать патч, позволяющий использовать не GNU-утилиты, но этот патч не будет принят, если лицензия на него будет BSD. Так?
Надо пойти на жертву и сделать патч, совместимый с лицензией для Autoconf.
>Я понимаю, Марк мог бы сделать патч, позволяющий использовать не GNU-утилиты, но
>этот патч не будет принят, если лицензия на него будет BSD.
>Так?
>Надо пойти на жертву и сделать патч, совместимый с лицензией для Autoconf.Там одним патчем не исправить. Ошибка, что называется, в ДНК. Марк провёл ОЧЕНЬ много времени в допиливании autotools, благодаря чему работа портирирующих уменьшилась на порядок. И теперь война с autotools занимает не 98% работы портирующего, а всего лишь 50%.
вас послушать, так прям ну столько МНОГО сил/времени/средств.
не то что эти дармоеды из состава аутосонф.
зы:
не нравится гну? пишите своё.
со своим уставом то и в чужой монастырь. нда.
ззы:
и что значит одним патчем не обойдётся? чушь то не порите.
одной строчкой - да. а вот патча и одного хватит.
>вас послушать, так прям ну столько МНОГО сил/времени/средств.
>не то что эти дармоеды из состава аутосонф.
>зы:
>не нравится гну? пишите своё.
>со своим уставом то и в чужой монастырь. нда.Ещё раз: от того, что разработчики OpenBSD напишут свою систему конфигурирования, НИЧЕГО не изменится. Её использовать надо в программах. Сейчас разработчики (портируемых) программ активно использует autotools: у них GNU/Linux с GNU-утилитами, и поэтому им зачастую даже в голову не приходит, что происходит при попытке сделать шаг в сторону.
А альтернативы-то есть. Тот же Марк в своё время заметно теплее отзывался, скажем, о CMake, который хоть и тоже не идеален, но проблем создаёт заметно меньше.
>ззы:
>и что значит одним патчем не обойдётся? чушь то не порите.
>одной строчкой - да. а вот патча и одного хватит.А вы тоже предпочитаете всё подряд в один патч запихивать? Сочувствую тем, кто пользуется вашими программами.
фигня вопрос! для это и придумали патчи.
или вы хотите, чтобы этим занялся кто-то другой?это гну утилиты для сборки програм.
и для их работы необходимо соответсвующее окружение.
если вам не нравиться то, что просит аутоконф - исправьте. или установите.
>фигня вопрос! для это и придумали патчи.
>или вы хотите, чтобы этим занялся кто-то другой?
>
>это гну утилиты для сборки програм.
>и для их работы необходимо соответсвующее окружение.
>если вам не нравиться то, что просит аутоконф - исправьте. или установите.
>Раньше я полагал, что если человек умеет писать, то умеет и читать. Но ваш пример доказывает, что я ошибался.
ну ваш пример ещё хуже - читать с грехом пополам умеет, писать тоже, а вот думать - нет.
минона, я поддерживаю предыдущих ораторов, что вы фанатик, не понимающий о чем говорите.
Autoconf БЫЛ СОЗДАН ДЛЯ ВОЗМОЖНОСТИ ПОРТИРОВАНИЯ НА РАЗНЫЕ ПЛАТФОРМЫ.
Еще раз: Autoconf БЫЛ СОЗДАН ДЛЯ ВОЗМОЖНОСТИ ПОРТИРОВАНИЯ НА РАЗНЫЕ ПЛАТФОРМЫ!
Где вообще вы увидели хоть слово про лицензии?
Или вы слово портирование понимаете под тем, что на всех платформах должен красоваться набор гнутых утил, когда такие же есть нативные?
Должен вам открыть тайну, наверняка люди, которые делают проверки на гнутость и версии гнутости утил делают это уж всяко не из соображений лицензии, а просто от незнания/лени/некомпетентности/непрофессионализма. Вы сами чего-нибудь писали кроссплатформенного? а вообще писали что-нибудь?
вот вам яруий пример, чуть ниже посмотрите, там один горе-программер пишет"
Согласен с "одним из разработчиков OpenBSD" - такая привязка есть, и могу его порадовать: и не только в Autoconf. :)> Сам сколько писал - так и поступал - требовал наличие gnu coreutils & etc.
>
> Ну на кой мне разбираться что там у него в системе еще есть? Проше указать в требованиях то что я знаю и использую. Кроме *BSD есть еще куча unix-ов, с корявым System5, тот же solaris :)
> В одном скрипте я даже версию bash требовал!!!
> Я не понимаю такой паталогии - избавляться от gnu utils.
>Autoconf БЫЛ СОЗДАН ДЛЯ ВОЗМОЖНОСТИ ПОРТИРОВАНИЯ НА РАЗНЫЕ ПЛАТФОРМЫ.
>Еще раз: Autoconf БЫЛ СОЗДАН ДЛЯ ВОЗМОЖНОСТИ ПОРТИРОВАНИЯ НА РАЗНЫЕ ПЛАТФОРМЫ!И еще раз, ДОТ - AUTOCONF БЫЛ СОЗДАН ДЛЯ ВОЗМОЖНОСТИ ПОРТИРОВАНИЯ НА РАЗНЫЕ ПЛАТФОРМЫ В РАМКАХ ОКРУЖЕНИЯ GNU. О религиозных фанатиках речи не было.
хааааа, не смешите меня. Как любят говорить гнутые парни: "пруфлинк в студию".
ну и кто с таким выгнутым захочет общаться?
а еще меня фанатиком обзывал.
ну вот, не можете =)Autoconf is an extensible package of m4 macros that produce shell
scripts to automatically configure software source code packages.
These scripts can adapt the packages to many kinds of UNIX-like
systems without manual user intervention. Autoconf creates a
configuration script for a package from a template file that lists the
operating system features that the package can use, in the form of m4
macro calls.WWW: http://www.gnu.org/software/autoconf/
ключевое здесь второе предложение
вот именно.
и если в ОС нет "features that the package can use" то "configuration script" не соберется.
английскими ж буквами, чёрным по белому написано!
>вот именно.
>и если в ОС нет "features that the package can use" то
>"configuration script" не соберется.
>английскими ж буквами, чёрным по белому написано!Угу. Параметр командной строки "--version" - это та самая feature, которая нужна пакету, да? Или, коли уж вы так привязались к tar, всё-таки поддержка имён с большей длиной имени?
подписываюсь под каждым словом, добавлю ещё что --version можно и подделать, но автоконф должен проверить действительно поддерживается нужный функционал.
должен? подайте в суд.
там и свои подписи предъявите. :D
ну а как же он обеспечит что например тот же тар не имеет ограничения в 100 символов в имени файла? в случае если я подделаю вывод --version
>>Autoconf БЫЛ СОЗДАН ДЛЯ ВОЗМОЖНОСТИ ПОРТИРОВАНИЯ НА РАЗНЫЕ ПЛАТФОРМЫ.
>>Еще раз: Autoconf БЫЛ СОЗДАН ДЛЯ ВОЗМОЖНОСТИ ПОРТИРОВАНИЯ НА РАЗНЫЕ ПЛАТФОРМЫ!
>
>И еще раз, ДОТ - AUTOCONF БЫЛ СОЗДАН ДЛЯ ВОЗМОЖНОСТИ ПОРТИРОВАНИЯ НА
>РАЗНЫЕ ПЛАТФОРМЫ В РАМКАХ ОКРУЖЕНИЯ GNU. О религиозных фанатиках речи не
>было.ссылочку на официальные документы autoconf где сказано про рамку окружения гну.
>ссылочку на официальные документы autoconf где сказано про рамку окружения гну.Я понимаю, что включать очень сложно и не хочется, но autoconf - часть GNU Build System, с пререквизитом GNU M4. Работа его под не-GNU окружениями не гарантируется.
вот где это сказано? сами придумали?
>вот где это сказано? сами придумали?1/ ""Autoconf does not solve all problems related to making portable software packages—for a more complete solution, it should be used in concert with other GNU build tools like Automake and Libtool. These other tools take on jobs like the creation of a portable, recursive makefile with all of the standard targets, linking of shared libraries, and so on. See The GNU Build System, for more information."" -- http://www.gnu.org/software/autoconf/manual/html_node/Introd...
2/ ""Autoconf is an extensible package of M4 macros that produce shell scripts to automatically configure software source code packages. These scripts can adapt the packages to many kinds of UNIX-like systems without manual user intervention."" -- http://www.gnu.org/software/autoconf/
Обратите _особое внимание на слово "can".
3/ **Когда** осилите, переходите к содержательной части поста #184 http:/openforum/vsluhforumID3/64676.html#184
Внимательно повторяю: YHBT. И на блесне Вы у "своего" же дядьку Марка -- он вкинул, а наивные-то зеленоглазые думали была команда "ату на GNU". _Вы ошиблись, была команда "Голос!".
>[оверквотинг удален]
>makefile with all of the standard targets, linking of shared libraries,
>and so on. See The GNU Build System, for more information.""
>-- http://www.gnu.org/software/autoconf/manual/html_node/Introd...
>
>2/ ""Autoconf is an extensible package of M4 macros that produce shell
>scripts to automatically configure software source code packages. These scripts can
>adapt the packages to many kinds of UNIX-like systems without manual
>user intervention."" -- http://www.gnu.org/software/autoconf/
>
>Обратите _особое внимание на слово "can".Ну ессесно, "can" — так же как автомобиль "can" отвезти вас от дома до работы. А может и сломаться. Только не факт, что в случае поломки виноват водитель (хотя бывает и такое, безусловно), дом или работа.
>3/ **Когда** осилите, переходите к содержательной части поста #184 http:/openforum/vsluhforumID3/64676.html#184
>
>Внимательно повторяю: YHBT. И на блесне Вы у "своего" же дядьку Марка
>-- он вкинул, а наивные-то зеленоглазые думали была команда "ату на
>GNU". _Вы ошиблись, была команда "Голос!".Команды не было, была просьба усилить борьбу с кривыми конфигураторами — перечитайте, если не верите.
Это у вас, красноглазиков, видимо, все в едином порыве за кем-то ходят. ;) (на всякий случай ремарка: шучу!)
>Команды не было, была просьба усилить борьбу с кривыми конфигураторами — перечитайте, если не верите.так вот что вы тут делаете!
боретесь! :D
>вот где это сказано? сами придумали?Это следует из здравой логики. Я всегда могу подсунуть окружение на котором любая билд-система всосет по полной. Авторы билд системы могут и не иметь доступа для тестирования к такому окружению и заранее предусмотреть все возможные закидоны всех возможных окружений - не могут. Хотите BSD tar? Ваш супер-пупер $CC под супер-пупер лицензией? А также прочих тамагоч и покемонов? Великолепно - вот вы тогда и трахайтесь с патчингом, портированием и прочая. Не вижу в каком месте это не честно и почему у гнушников должна вообще болеть бошка от бздунов при том что бздуны один хрен только спят и видят как бы от ненавистных трех букв избавиться поизящнее. Гордость и независимость от всех остальных имеет свою цену в виде долбежки всех стен своим лбом.
>Гордость и независимость от всех остальных
>имеет свою цену в виде долбежки всех стен своим лбом.И поэтому так важна унификация утилит сборки.
Кстати "костыли":
% pkg_info | grep autoconf
autoconf-2.13.000227_6 Automatically configure source code on many Un*x platforms
autoconf-2.62 Automatically configure source code on many Un*x platforms
autoconf-wrapper-20071109 Wrapper script for GNU autoconf
% pkg_tree -v autoconf-2.62
autoconf-2.62
|\__ perl-threaded-5.10.1
|\__ libsigsegv-2.5
|\__ m4-1.4.14,1
| \__ libsigsegv-2.5
\__ autoconf-wrapper-20071109% uname -rsm
FreeBSD 8.0-STABLE amd64Под GNUтым OpenJDK ("JDK" — это система поддержки компиляции и сборки, если кто не в курсе) отлично работает Apache Tomcat. Без этой возможности пришлось бы использовать проприетарную яву, через которую есть нехилый vendor-lock in на Oracle.
Пилять!>нехилый vendor-lock in на Oracle.
Java от SUN - GPL
собственно выпуск ее под GPL и позволил допилить OpenJDK
(путем пофункционального копирования тысяч строк кода)
>Пилять!
>
>>нехилый vendor-lock in на Oracle.
>
>Java от SUN - GPL
>собственно выпуск ее под GPL и позволил допилить OpenJDK
>(путем пофункционального копирования тысяч строк кода)В OpenJDK нету: JavaWeb Start, Java-Plug-in (для работы апплетов в браузере), Nimbus Look&Feel, JavaFX Script. Так что — мимо.
>минона, я поддерживаю предыдущих ораторов, что вы фанатик, не понимающий о чем говоритеа я поддерживаю свое же мнение, что он идиот. но теперь уже и в отношении вас. и что? :D
>Еще раз: Autoconf БЫЛ СОЗДАН ДЛЯ ВОЗМОЖНОСТИ ПОРТИРОВАНИЯ НА РАЗНЫЕ ПЛАТФОРМЫи что, не собирает? ай-ай-ай. (ты чего разорался то? я и так прекрасно вижу)
>Или вы слово портирование понимаете под тем, что на всех платформах должен красоваться набор гнутых утил, когда такие же есть нативные?такие же? уверен? :D
зы:
ты ниже обсуждение про 100 символов в солярном таре читал. а ведь чудики так и не нашли ни в каком стандарте это якобы "требование". а ведь этот тар еще и gzip с bzip2 не умеет. а gzip с bzip2 в стандартной поставке соляры нет. так что ты выберешь - один гнутый тар установить, или две gzip/bzip2 (тоже гнутые) и через pipe заюзать "родной" тар, который может и не отработать как надо (хер его знает что там разрабы линуксячьи понапихали - вот уроды! :D)?
autoconf - часть gnu build system. не хочешь после сборки держать гнутые утилиты - удаляй. можешь вместе с gcc. а еще лучше ставь все необходимое для сборки в черут, собирай и удаляй.
что вы к этому чруту привязались)))) умное слово чтоль, чтоб пыль в глаза пускать?Ну так autoconf и должен проверить, может ли в соляре этот самый tar выполнять тот ФУНКЦИОНАЛ, который нужен для сборки. Если нет, то да, нам нужен гнутай tar. Вопросов нет.
Проблема в том, что некоторые программеры просто из личной лени делают необходимым это гнутый tar, повторюсь, даже если финкциональности нативного хватает для сборки.
>что вы к этому чруту привязались)))) умное слово чтоль, чтоб пыль в глаза пускать?да о вас же беспокоюсь.
чтоб вам гнутые утили глаза не мозолили
>Ну так autoconf и должен проверить, может ли в соляре этот самый tar выполнять тот ФУНКЦИОНАЛ, который нужен для сборки. Если нет, то да, нам нужен гнутай tar. Вопросов нет.автоконф должен собрать скрипт, который соберёт программу в бинарник.
не больше и не меньше. это единственное, что он "должен".а если у вас есть "хотелка" чтобы при этом он заюзал "нативный" тар (т.к. гнушный тар расходится с мировозрением) - ю а велком в комманду разработчиком для написания скриптов проверок
>автоконф должен собрать скрипт, который соберёт программу в бинарник.
>не больше и не меньше. это единственное, что он "должен".
>так зачем он тогда тогда требует установить гнутые утилиты?
>так зачем он тогда тогда требует установить гнутые утилиты?Потому что его авторы проверяли его с оными утилитами, оные утилиты портабельны и есть под кучу платформ. А как работает супер-мега-тар который ни с чем не совместим на моей супер-мега-кастомной платформе авторы могли и не знать и не имеют никаких оснований считать его удовлетворяющим зависимостям.
>Я понимаю, Марк мог бы сделать патч, позволяющий использовать не GNU-утилиты, но
>этот патч не будет принят, если лицензия на него будет BSD.
>Так?
>Надо пойти на жертву и сделать патч, совместимый с лицензией для Autoconf.Нет. Речь ни разу не идет о лицензии. Вообще. Речь идет о том, что автоконф не выполняет своего прямого назначения.
не понимаю. autoconf часть гну-утилит и ими пользуется. в чём трабл?
в том, что слово портирование не означаниет копирования утил, функционал которых уже есть в нативном виде
а что означает слово "портирование"? :D
да без проблем
http://ru.wikipedia.org/wiki/%D0%9F%D0%B...
ну так прочитай его! :D
>не понимаю. autoconf часть гну-утилит и ими пользуется. в чём трабл?В том, что религиозным фанатикам не понять, что собранный под GNU-окружение софт им придется вылизывать самостоятельно. Они еще и возмутиться умудряются.
Неправильный подход. Ругаться и баба базарная может.Не нравится GNU autoconf - пишите BSD autoconf.
Все равно конечная цель состоит в создании BSD-аналогов для всех GPL-программ, и некая... эмм... несовместимость будет только стимулировать разработчиков.
Тоже такая мысль мелькнула. Процесс переписывания всего под лицензией BSD самоподдерживается.Разработчики систем BSD мыслят примерно так. Если нечто из GNU не умеет работать с BSD, то это нечто нужно переписать под BSD. Чем больше переписано под BSD, тем больше несовместимостей с BSD возникает у GNU. Процесс переписывания повторяется и таким образом самоподдерживается.
Вот и переписывайте наздоровье. Если доживете, конечно, до той "светлой" поры когда сможете выбросить ненавистное вам слово из вашей системы и заменить на религиозно правильное, ага. Правда, многовато переписывать придется, хе-хе.
>Вот и переписывайте наздоровье. Если доживете, конечно, до той "светлой" поры когда
>сможете выбросить ненавистное вам слово из вашей системы и заменить на
>религиозно правильное, ага. Правда, многовато переписывать придется, хе-хе.Давай открою тебе глаза. Для проекта Lustre (совсем фиговый такой проектик) - были написаны абсолютно свои макросы в стиле autoconf именно по причине того что штатные не совместимы не счем, a Cray XT[3-5] build system - только очень слегка напоминает gnu.
Самый смешной баг это в основном макросе autoconf код написан с нарушениями стандарта на C,
в результате использование его в случае указания -Werror - который обычно используется в bsd world - невозможен.
давай. открой. пруфлинком.
а то как не скачаешь, так сразу в глаза бросается
configure debian autoMakefile.am ChangeLog config.h.in configure.ac depcomp Makefile.in autoMakefile.in
и пр.
кстати, чтобы сейчас скачать ещё и регистрироваться надо. вот такой опенсорс у оракла пошёл.зы:
не успела сан купить люстру, как сан-боям ужо и автоконф не нравится, и гцц. то ли ещё будет.
ззы:
>были написаны абсолютно свои макросы в стиле autoconf именно по причине того что штатные не совместимы не счемштатные - это какие?
>не успела сан купить люстру, как сан-боям ужо и автоконф не нравится, и гцц. то ли ещё будет.Это было переписано еще до покупки саном.
кстати
>>configure debian autoMakefile.am ChangeLog config.h.in configure.ac depcomp Makefile.in autoMakefile.in
>>отношения к autoconf не имеет, это automake - так что выучите предмет ;-)
>штатные - это какие?
потратьте время и посмотрите сами - там все просто - только с -Werror работать не будет.
>отношения к autoconf не имеет, это automake - так что выучите предмет ;-)The GNU build system comprises the GNU utility programs Autoconf, Automake, and Libtool
>потратьте время и посмотрите сами - там все просто - только с -Werror работать не будет.ты просвещать хотел или потролить?
>Самый смешной баг это в основном макросе autoconf код написан с нарушениями
>стандарта на C,Напишите лучше. Вам кто-то не дает? А то вонять все умеют, а вот патчи прислать - не дождешься. Ну еще могут посоветовать пару решений из разряда "отомщу кондуктору: куплю билет и пойду назло ему пешком". То есть если вы хотите чтобы вашу прогу поменьше компилили под РАЗНЫЕ платформы - валите на cmake или что там еще. Желающих собирать под таргет платформу не только вашу прогу но и сам cmake для нее будет явно меньше чем тех кто осилит запустить на целевой платформе аж 1 несчастный шелскрипт (что как-то зело проще и нифига не требует окромя шел-интерпретера для стариа и понимания того чего не хватает в системе для вон той проги).
>Неправильный подход. Ругаться и баба базарная может.
>
>Не нравится GNU autoconf - пишите BSD autoconf.О! Точно-точно. $CC они сколько "переписывали"? Лет пять-семь?... Вот с автоконфом мы их ещё лет _25 не увидим. Славно++
>Все равно конечная цель состоит в создании BSD-аналогов для всех GPL-программ, и
>некая... эмм... несовместимость будет только стимулировать разработчиков.Только они сами, разработчики, об этом помалкивают и ти-и-ихо-ти-и-ихо пользуют ненавистное, несвободное _гнутое... Более того разработчики-таки и о "ненависти" к помалкивают, а флагами машут тупые форумные bsd-троли. Исключительно.
>[оверквотинг удален]
>
>О! Точно-точно. $CC они сколько "переписывали"? Лет пять-семь?... Вот с автоконфом мы
>их ещё лет _25 не увидим. Славно++
>
>>Все равно конечная цель состоит в создании BSD-аналогов для всех GPL-программ, и
>>некая... эмм... несовместимость будет только стимулировать разработчиков.
>
>Только они сами, разработчики, об этом помалкивают и ти-и-ихо-ти-и-ихо пользуют ненавистное, несвободное
>_гнутое... Более того разработчики-таки и о "ненависти" к помалкивают, а флагами
>машут тупые форумные bsd-троли. Исключительно.Да что значит «используют»?! Проблемы всплывают при портировании УЖЕ НАПИСАННОГО, чужого ПО, использующего autotools! Причём здесь BSD-разработчики? Ну, кроме того, что им приходится эти якобы портируемые программы портировать ручками.
вы уж не выдумывайте о ручках то.
гну-тар ручками поставить? ню-ню. хороши ручки.
>вы уж не выдумывайте о ручках то.
>гну-тар ручками поставить? ню-ню. хороши ручки.Ага. А ещё пути прописывать, куда ставиться, пути к либам-заголовкам указывать, опции компилятора в нормальный вид приводить…
одним словом - ппц.
до такого даже марк не додумался.зы:
я вот уж и забыл с кого периода всё собираю в черуте.
>одним словом - ппц.
>до такого даже марк не додумался.
>
>зы:
>я вот уж и забыл с кого периода всё собираю в черуте.Думаю, не позднее чем опёнковцы придумали изоляцию при сборке. Потом этот принцип пошёл в другие аналогичные системы.
т.е. предыдущий ваш пост как аргумент вычёркивем? :D
>т.е. предыдущий ваш пост как аргумент вычёркивем? :DДа просто повторяться надоело. Вы же отказываетесь понимать то, что вам говорят.
Кстати, если не секрет, а сколько вы в своей жизни софта портировали? Не то чтобы это напрямую коррелировало с убедительностью вашей аргументации, но просто интересно?
так и мне интересно сколько же человек спортировал и собрал софта, что до сих пор плачется на пути для сборки.
хотя нет. не интересно. таких полно.
>так и мне интересно сколько же человек спортировал и собрал софта, что
>до сих пор плачется на пути для сборки.
>хотя нет. не интересно. таких полно.Если вы про Марка, то он, среди прочего:
— Переписал систему портов OpenBSD и утилиты pkg_*, когда-то импортированные из FreeBSD (первой ОС, в которой появилась и заработала идея локальных портов, между прочим);
— Участвовал (участвует?) в разработке GCC;
— Портировал на OpenBSD несколько поколений KDE, с зависимостями;
— Портировал ещё несколько сотен приложений:/usr/ports$ make search key="Marc Espie" | fgrep 'Maint:' | wc -l
258
Если вы про меня, то мои заслуги скромнее. Я сейчас мэйнтейню, например, порты fwbuilder и krename, в загашнике болтаются ещё несколько портов — пойдут после tree unlock. Сейчас вот замахнулся сделать эмулятор ALSA поверх libsndio, но, чувствую, не осилю. :-P
А вот вы ушли от ответа.
я про вас. бог с ним, с марком.
итак, какие конкретно у вас проблемы с путями? без тролизма плс.
>Сейчас вот замахнулся сделать эмулятор ALSA поверх libsndio, но, чувствую, не осилю. :-Pда. вот это не мешало бы.
>я про вас. бог с ним, с марком.
>итак, какие конкретно у вас проблемы с путями? без тролизма плс.
>>Сейчас вот замахнулся сделать эмулятор ALSA поверх libsndio, но, чувствую, не осилю. :-P
>
>да. вот это не мешало бы.Нет, речь про вас. Сколько программ вы портировали? Насколько вообще вы компетентны в предмете, чтобы тут рассуждать?
судя по тому, что вы нависали, побольше будет.
так что там с путями? чтобы тут рассуждать. :D
если вы стесняетесь, то скажите хоть с какой на какую платформу =)
стесняюсь? :D а к примеру по комментам не видно?
или теперь ты мне расскажешь про стандарт на 100 символов? и как его обойти? как к нему bzip2 присобачить не устанавливая, как нужные кодировки в кастрированном "нативном" iconv прикрутить?...
не стесняйся! рассказывай! а то предыдущие ораторы как то сдулись неожиданно! :D
да, по комментам не видно. Вижу только про линух
ну дык... я не окулист
или вы ожидали, что если я что-то пишу под какую то платформу, то и фанатеть от неё должен? :Dмне точно также для сборки приходится ставить гнутые утили.
и это не потому, они или автоконф плохие.
>я про вас. бог с ним, с марком.
>итак, какие конкретно у вас проблемы с путями? без тролизма плс.Отрывки из grep по патчам к файлам configure*. Порты выбирал наугад, там вывод на много страниц.
/usr/ports/misc/mc/patches/patch-configure- IFS=$as_save_IFS
/usr/ports/misc/mc/patches/patch-configure-
/usr/ports/misc/mc/patches/patch-configure:- test -z "$ac_cv_path_ZIP" && ac_cv_path_ZIP="/usr/bin/zip"
/usr/ports/misc/mc/patches/patch-configure-+ ac_cv_path_ZIP="${LOCALBASE}/bin/zip"
/usr/ports/misc/mc/patches/patch-configure- ;;
/usr/ports/print/foomatic-db/patches/patch-configure-
/usr/ports/print/foomatic-db/patches/patch-configure-
/usr/ports/print/foomatic-db/patches/patch-configure:-SBINSEARCHPATH=/usr/sbin:/sbin:/usr/local/sbin:/etc/sbin
/usr/ports/print/foomatic-db/patches/patch-configure:-BINSEARCHPATH=/usr/bin:/bin:/usr/local/bin
/usr/ports/print/foomatic-db/patches/patch-configure:-DATASEARCHPATH=/usr/share:/usr/local/share:/usr/lib:/usr/local/lib:/opt
/usr/ports/print/foomatic-db/patches/patch-configure:+SBINSEARCHPATH=/usr/sbin:/sbin:!!LOCALBASE!!/sbin
/usr/ports/print/foomatic-db/patches/patch-configure:+BINSEARCHPATH=/usr/bin:/bin:!!LOCALBASE!!/bin
/usr/ports/print/foomatic-db/patches/patch-configure:+DATASEARCHPATH=/usr/share:!!LOCALBASE!!/share:/usr/lib:!!LOCALBASE!!/lib
/usr/ports/print/foomatic-db/patches/patch-configure- BSB=$BINSEARCHPATH:$SBINSEARCHPATH
/usr/ports/print/foomatic-db/patches/patch-configure- for ac_dir in cups/model
/usr/ports/lang/otcl/patches/patch-configure-+++ configure Sat Oct 13 15:48:01 2007
/usr/ports/lang/otcl/patches/patch-configure-@@ -4163,6 +4163,7 @@ TCL_H_PLACES=" \
/usr/ports/lang/otcl/patches/patch-configure: /usr/local/lib/tcl$TCL_HI_VERS \
/usr/ports/lang/otcl/patches/patch-configure: /usr/local/lib/tcl$TCL_ALT_VERS \
/usr/ports/lang/otcl/patches/patch-configure: /usr/local/include/tcl$TCL_VERS \
/usr/ports/lang/otcl/patches/patch-configure:+ /usr/local/include/tcl$TCL_HI_VERS/generic \
/usr/ports/lang/otcl/patches/patch-configure: /usr/local/include/tcl$TCL_HI_VERS \
/usr/ports/lang/otcl/patches/patch-configure: /usr/local/include/tcl$TCL_ALT_VERS \
/usr/ports/lang/otcl/patches/patch-configure: /usr/local/include \
/usr/ports/lang/otcl/patches/patch-configure-@@ -5532,16 +5533,16 @@ case $system in
/usr/ports/lang/otcl/patches/patch-configure- DL_LIBS="-ldl"
/usr/ports/net/arpd/patches/patch-configure_in- EVENTINC="-I${prefix}/include"
/usr/ports/net/arpd/patches/patch-configure_in- EVENTLIB="-L${prefix}/lib -levent"
/usr/ports/net/arpd/patches/patch-configure_in:+ elif test -f /usr/include/event.h; then
/usr/ports/net/arpd/patches/patch-configure_in-+ EVENTLIB="-levent"
/usr/ports/net/arpd/patches/patch-configure_in- else
И ещё много, много, много простыней...>>Сейчас вот замахнулся сделать эмулятор ALSA поверх libsndio, но, чувствую, не осилю. :-P
>
>да. вот это не мешало бы.Да вам-то оно зачем? Вам ведь libsndio нафиг не сдался, когда есть православный ALSA (или что сейчас самым православным в Linux считается), не? :)
Спасибо Вам за этот комментарий. Теперь буду знать, что мне лучше держаться от autotools как можно дальше.
Вдогонку ещё немного статистики:Количество патчей к configure* (то есть исключены те случаи, когда спасает повторный прогон autoconf, либо — о, чудо! — имеющийся configure отрабатывает корректно):
$ find /usr/ports -mindepth 4 -maxdepth 5 \
>! -path '/usr/ports/pobj*' -path '*/patches/patch-configure*' \
>| wc -l663
Почти точное (реально больше за счёт Makefile, действующих сразу на целый набор портов) общее количество программ, использующих autoconf:
$ find /usr/ports -mindepth 3 -maxdepth 4 \
>! -path '/usr/ports/pobj*' -name Makefile \
>| xargs egrep -l '^CONFIGURE_STYLE.*(gnu|autoconf|automake)' \
>| wc -l1639
С учётом оговорки выше получается, что примерно 40-50% ото всех "портируемых" приложений требуют усилий по допиливанию. Такая вот математика.
>Спасибо Вам за этот комментарий. Теперь буду знать, что мне лучше держаться
>от autotools как можно дальше.Да, идите, пожалуйста и сделайте свое, с шахматами и поэтессами. И не забудьте нас осчастливить чем-то не менее портабельным гнутых автотулзов, разумеется. А то каконйить cmake жутко грабелен и требует для своей работы инсталяции себя любимого тогда как конфигур всего лишь скрипт который сам по себе. Всякие там scons и что там еще вообще хотят питон и что там еще которые есть далеко не везде, etc. В итоге портабельность получается в сумме еще более жопная а сборка на мало-мальски экзотичных или минимальных платформах может предоставить немало геморроя.
Честно - это их проблемы. Они сборщики дистра, им и работать.
абсолютно поддерживаю.
если их что-то не устраивает - ю а велком в группу разработки.
а то вон сколько тут понаписали, а воз и ныне там.
так а где будет портируемость? это основная цель автоконфа
соберешь программу. запустишь. она заработает - значит портирована.
после этого можешь средства для ее сборки удалить. самой программе они не нужны.
>так а где будет портируемость? это основная цель автоконфаПортируемость != пререквизиты. Доступно?
Согласен с работчиками OpenBSD, часто встречаемые проблемы при портировании.
В то время, как все нормальные люди уже поняли, что autotools пора закапывать, разработчики OpenBSD продолжают открывать их для себя.
>В то время, как все нормальные люди уже поняли, что autotools пора
>закапывать, разработчики OpenBSD продолжают открывать их для себя.Комментарий у вас глуповатый получился. Разговор идет о проблемах портирования, а не о разработке.
А что использовать вместо? Waf которому питон нужен? Или еще что? Просветите.
CMake. Waf и scons создают больше проблем чем решают, а дле тех, кто этим потом будет пользоваться, я бы сказал они еще хуже autotools.
>CMake.А его еще инсталить надо. Особенно "прикольно" если его под целевую платформу самого нет нифига. Тогда сперва придется собирать его. Да и вообще - грабель с ним почему-то есть. Автотулсы горбатые, кривые и хреновые. Но временем отлажены и свое дело более-менее делают. А то что сватается как замена в итоге обычно доставляет нифига не меньше головняка. Нет, то есть, если "портироваие" это "компилежка на i386 под бздю" оно может и ничего, да. А если это чтонить поэкзотичнее, то чего? Там ни бздей, ни Cmake и как правило только сам гнутый тулчайн да может немного гнутых довесков, если повезет.
>[оверквотинг удален]
>
>А его еще инсталить надо. Особенно "прикольно" если его под целевую платформу
>самого нет нифига. Тогда сперва придется собирать его. Да и вообще
>- грабель с ним почему-то есть. Автотулсы горбатые, кривые и хреновые.
>Но временем отлажены и свое дело более-менее делают. А то что
>сватается как замена в итоге обычно доставляет нифига не меньше головняка.
>Нет, то есть, если "портироваие" это "компилежка на i386 под бздю"
>оно может и ничего, да. А если это чтонить поэкзотичнее, то
>чего? Там ни бздей, ни Cmake и как правило только сам
>гнутый тулчайн да может немного гнутых довесков, если повезет.Да никто и не говорит, что CMake — панацея. Идеала пока что нет, иначе бы все им давно пользовались. :) Идея с шеллом — в своё время была грамотная, сейчас уже сам autoconf частично написан на Perl — думаю, что-то аналогичное, только более продуманное (при всей моей нелюбви к Perl), было бы очень в тему…
>[оверквотинг удален]
>>Нет, то есть, если "портироваие" это "компилежка на i386 под бздю"
>>оно может и ничего, да. А если это чтонить поэкзотичнее, то
>>чего? Там ни бздей, ни Cmake и как правило только сам
>>гнутый тулчайн да может немного гнутых довесков, если повезет.
>
>Да никто и не говорит, что CMake — панацея. Идеала пока что
>нет, иначе бы все им давно пользовались. :) Идея с шеллом
>— в своё время была грамотная, сейчас уже сам autoconf частично
>написан на Perl — думаю, что-то аналогичное, только более продуманное (при
>всей моей нелюбви к Perl), было бы очень в тему…Или, как вариант, чисто сишная, без посторонних зависимостей, реализация, с единственным шелл-скриптом, который её компилирует. :)
>[оверквотинг удален]
>>>гнутый тулчайн да может немного гнутых довесков, если повезет.
>>
>>Да никто и не говорит, что CMake — панацея. Идеала пока что
>>нет, иначе бы все им давно пользовались. :) Идея с шеллом
>>— в своё время была грамотная, сейчас уже сам autoconf частично
>>написан на Perl — думаю, что-то аналогичное, только более продуманное (при
>>всей моей нелюбви к Perl), было бы очень в тему…
>
>Или, как вариант, чисто сишная, без посторонних зависимостей, реализация, с единственным шелл-скриптом,
>который её компилирует. :)Или вот ещё интереснее: поскольку устанавливаемый софт написан на том или ином языке программирования, транслируем метакод, скажем, того же CMake'а в скрипт либо на том же языке, что и прога (поэтому интерпретатор будет гарантированно), либо на том же Perl (если прога на компилируемом языке). И этот сгенерированный скрипт и прилагаем…
>Или, как вариант, чисто сишная, без посторонних зависимостей, реализация, с единственным
>шелл-скриптом, который её компилирует. :)Дык этот скрипт, вестимо, называется configure и генерится столь нелюбимыми тут некоторыми автотулсами. Потому то и работает везде - ему кроме сишного компилера да шел интерпретера нифига не надо. А вот перл... ну найдите блин его на какихнить обкусаных эмбеддед окружениях или супер-минимальных инсталляциях систем в контейнерах типа опенвзы например, ага, где стоит полный минимум обычно (а то засирать виртуальные окружения чем попало когда их легион - очень накладно, знаете ли, так что их делают максимально урезанными по возможности).
>А вот перл... ну найдите
>блин его на какихнить обкусаных эмбеддед окружениях или супер-минимальных инсталляциях систем
>в контейнерах типа опенвзы например, ага, где стоит полный минимум обычно
>(а то засирать виртуальные окружения чем попало когда их легион -
>очень накладно, знаете ли, так что их делают максимально урезанными по
>возможности).ага, а тут ещё автоконф гнутые утилиты требует... зачем непонятно, coreutils зачем-то, ведь у меня busybox установлен, и всё что нужно умеет делать.
>ага, а тут ещё автоконф гнутые утилиты требует... зачем непонятно, coreutils зачем-то,
>ведь у меня busybox установлен, и всё что нужно умеет делать.
>В который раз, ДОТ, поясняем: autoconf - это утилита GNU. Логично предположить, что она требует другие утилиты GNU, и с не-GNU версиями работы не гарантирует. Если так хочется - отключите требование, и работайте НА СВОЙ СТРАХ И РИСК. Если работает - предложите патч с обнаружением вашей версии утилиты. У кого-то не заработает - получите по шее вы, как коммиттер патча.
>>ага, а тут ещё автоконф гнутые утилиты требует... зачем непонятно, coreutils зачем-то,
>>ведь у меня busybox установлен, и всё что нужно умеет делать.
>>
>
>В который раз, ДОТ, поясняем: autoconf - это утилита GNU. Логично предположить,
>что она требует другие утилиты GNU, и с не-GNU версиями работы
>не гарантирует. Если так хочется - отключите требование, и работайте НА
>СВОЙ СТРАХ И РИСК. Если работает - предложите патч с обнаружением
>вашей версии утилиты. У кого-то не заработает - получите по шее
>вы, как коммиттер патча.да пускай хоть всё окружение GNU/Hurd требует,если это обосновано необходимым функционалом этого окружения, а если автоконф по другому проверить функционал не может, то он написан не правильно.
>окружения, а если автоконф по другому проверить функционал не может, то
>он написан не правильно.Тем не менее, большинству OSS программеров (судя по статистике использования) он вполне удобен, и им пользуются. Все остальное в данном случае - это сугубо ваши религиозные соображения.
>Тем не менее, большинству OSS программеров (судя по статистике использования) он вполне
>удобен, и им пользуются. Все остальное в данном случае - это
>сугубо ваши религиозные соображения.допустим он достаточно удобен, но почему вы не хоте его улучшить?
>>Тем не менее, большинству OSS программеров (судя по статистике использования) он вполне
>>удобен, и им пользуются. Все остальное в данном случае - это
>>сугубо ваши религиозные соображения.
>
>допустим он достаточно удобен, но почему вы не хоте его улучшить?Чем? Тормозными проверками каждой из миллиона функций каждой используемой тулзы? Не проще взять гарантированно рабочие тулзы, и проверить только версию?
>окружения, а если автоконф по другому проверить функционал не может, то
>он написан не правильно.Возьмите и напишите правильно. Кто-то не дает? Почему-то пока то что появилось на замену любезно предоставляет еще в 100500 раз больше грабель а по степени портабельности и близко не стояло.
>Возьмите и напишите правильно. Кто-то не дает? Почему-то пока то что появилось
>на замену любезно предоставляет еще в 100500 раз больше грабель а
>по степени портабельности и близко не стояло.я Вам уже отвечал на этот вопрос, вопрос не в том напишет ли кто-то правильно, вопрос в том "как правильно?", и если Вы считаете что правильно проверять версию, то пожалуйста используйте дальше автоконф, к Вам лично претензий нету.
>вопрос в том "как правильно?"POSIX для этого и придумали.
как имннно вы будете его собираьб - ваше дело. но собрать и работать можно.
>Да никто и не говорит, что CMake — панацея. Идеала пока что
>нет, иначе бы все им давно пользовались. :) Идея с шеллом
>— в своё время была грамотная, сейчас уже сам autoconf частично
>написан на Perl — думаю, что-то аналогичное, только более продуманное (при
>всей моей нелюбви к Perl), было бы очень в тему…На взрослой Java всё собирается Ant'ом — универсальная штука. Есть тренд миграции небольших проектов на Maven, но люди ещё не дошли до него чисто концептуально — "как это так декларативный язык описания управляет полным жизненным циклом приложения и его библиотеками от компиляции до установки и тестирования?" Но Явка, похоже, только в Солярке прижилась в качестве одного из основных интрументов управления программным окружением.
>Но Явка, похоже, только в Солярке прижилась в качестве одного из основных интрументов управления программным окружением.вот и в недоумении, с чего вдруг? :D
>>Но Явка, похоже, только в Солярке прижилась в качестве одного из основных интрументов управления программным окружением.
>
>вот и в недоумении, с чего вдруг? :DТак все сервера в телекоме, которые считают, сколько с тебя содрать за мобильную связь, на Соляре с JEE. :D
мобыть J2EE? ну да ладно. некоторые вон и на дотнете работают. у каждого свои тараканы :D
>мобыть J2EE? ну да ладно. некоторые вон и на дотнете работают. у
>каждого свои тараканы :DМобыть и на J2EE, но уже давно вышло Java EE 5.0 и недавно 6.0, так что "2" — лишняя. ;)
может и лишнее, вот только в продакшене убрать это "лишнее" ой как порой не просто.
>Так все сервера в телекоме, которые считают, сколько с тебя содрать за
>мобильную связь, на Соляре с JEE. :DИзен, не пиши о том, в чем некомпетентен. нет там java. зато есть много ненавистного некоторыми linux'а.
Даже cisco ASA - и то линукс.
>
>>Так все сервера в телекоме, которые считают, сколько с тебя содрать за
>>мобильную связь, на Соляре с JEE. :D
>
>Изен, не пиши о том, в чем некомпетентен. нет там java. зато
>есть много ненавистного некоторыми linux'а.
>
>Даже cisco ASA - и то линукс.Большая тройка с тобой не согласна.
У большой тройки кстати в биллингах сроду был ряд очень интересных багов, позволяющих не сильно тупым абонентам слегка нагреть "нежно любимого" оператора :). При том минимум 2 известных мне ошибки приводили к влетам операторов на очень круглые суммы бабла и при том они были искренне детсадовские, любой нормальный проектировщик должен был бы предотвратить их еще в зародыше.
>Большая тройка с тобой не согласна.билайн и мтс используют comverse. факт общедоступный. там sco unixware + rhel3.
comverse one - вообще целиком на linux, ввиду смерти SCO.
>
>>Большая тройка с тобой не согласна.
>
>билайн и мтс используют comverse. факт общедоступный. там sco unixware + rhel3.
>
>
>comverse one - вообще целиком на linux, ввиду смерти SCO.ПО, считающее деньги, написано на Java.
ПО для бизнеса как правило отличается наиболее халтурным исполнением. Почитать что ЮЗЕРЫ думают о таких ПОДЕЛКАХ можно например на том же хабре где юзеры клиент-банка на яве очень некисло так прошлись по его "достоинствам" и "фичам".
У BeeLine на Red Hat-е :D
>вот и в недоумении, с чего вдруг? :DНаверное остальные не очень хотят столько говна в систему вкатывать, что, блин, логично. А покажите мне яву для мипсовых роутеров например. Или армовских железяк. А вот манагер пакетов для них я могу и показать если что. Равно как и гнутые тулчейны под них. А вот какогонить перла, питона, CMake-а или там еще чего вполне может и не быть. Ну, бздунов то это понятное дело не интересует - им интересно только портирования под свои специфичные утили на i386 гробики.
А чем можно заменить? Не троллинга ради, действительно интересно.
Да хотя бы cmake - который вполне себе генерит makefile под нужное окружение
будь то bsd or gnu make, или ms vc workplace, eclipse project, возможно что-то еще.
Имеет интерграцию с cdash & ctest для организации автоматизированого тестирования сборки и unit testing.
ну так пользуйтесь.
жду в люстре.
и штоб работало везде.
>ну так пользуйтесь.
>жду в люстре.
>и штоб работало везде.а еще может вам шнурки отгладить? или по теме возражений нет?
чем autotools лучше cmake ;-)
мы вот составляли документ - выходит что autotools сливают обоим альтернативам.
Что scons, что cmake. причем за scons говорит большая гибкость - за cmake интеграция с cdash/ctest.
>а еще может вам шнурки отгладить? или по теме возражений нет?достаточно претворить свои слова в дела.
>чем autotools лучше cmake ;-)как чем? он используется при сборке люстры.
>мы вот составляли документ - выходит что autotools сливают обоим альтернативам.документ? это вам в правительство надо. там любят документы.
>чем autotools лучше cmake ;-)Тем что не требует инсталить пакет в систему, елки. Который еще и должен под нее быть. Или можно неплохо пободаться с его сборкой. Хотя такой цели и не стояло и стояла цель собрать прогу X на системе Y.
>В то время, как все нормальные люди уже поняли, что autotools пора
>закапывать, разработчики OpenBSD продолжают открывать их для себя.А они их и не используют в своих разработках. Проблемы начинается, когда это якобы портируемого ПО пытаются сконфигурить на OpenBSD.
Поверьте (а хотите — проверьте), разбираться в нутре pf проще, чем дебрях этого крапа.
зогоните всё эти гнутары, гнумэйки и пр. по зависимостям.
или выпустите патч.
или напишите своё.зы:
ну блин, сейчас каждый из состава гну просто будет обязан ставить себе pcbsd, чтобы марку вдруг (ни-ни!!!) не пришлось ставить гнумэйк, гнутар и прочий крап из корэ-утилс.
это возмутительно! понапридумали всяких корэ. а бедным бздишникам мучайся.
>зогоните всё эти гнутары, гнумэйки и пр. по зависимостям.
>или выпустите патч.
>или напишите своё.
>
>зы:
>ну блин, сейчас каждый из состава гну просто будет обязан ставить себе
>pcbsd, чтобы марку вдруг (ни-ни!!!) не пришлось ставить гнумэйк, гнутар и
>прочий крап из корэ-утилс.
>это возмутительно! понапридумали всяких корэ. а бедным бздишникам мучайся.Если они претендуют на то, что софт, созданный с применением autotools, портируем, то обязаны ставить и проверять. Иначе пусть честно пишут: «GNU environment is the only supported one».
не софт созданный с его помощью, а сборка этого софта.
бздишнеку это стыдно не понимать.
>не софт созданный с его помощью, а сборка этого софта.
>бздишнеку это стыдно не понимать.Чтобы софт собирался с помощью autotools, приходится кое-какие манипуляции проводить, если вы не в курсе. Такому ярому защитнику GNU стыдно не знать.
вот и установите всё необходимое для сборки.
>вот и установите всё необходимое для сборки.Вы не поняли: манипуляции имелись в виду те, которые производятся над самим дистрибутивом программы.
да я уже повторять замучался - манипулируйте не с конфигуре, а с окружением.
желательно в черуте.
>да я уже повторять замучался - манипулируйте не с конфигуре, а с
>окружением.
>желательно в черуте.Вы не знаете, о чём говорите. Повторяю ещё раз: если бы дело ограничивалось установкой нужных прог — всё было бы легко и просто. Это раз.
Во-вторых, в chroot просто так куда попало не позапихиваешь — при установке пакета в реальную систему прога будет искать либы и всякие файлы данных по тем же путям. И чего тогда?
вот по этому в черут запихивают не только проги, но и хидеры, и сырцы, и библы, и даже их определённые версии (но с этим сложнее - в любом случае, если версии библ не совместимы, то они не совместимы. и надо прекращать и разбираться).
в любом случае, после сборки сырцы и хидеры проге уже не нужны. да и всегда есть различные вариации --prefix.в общем, гораздо проще для конкретной проги написать по её требованиям скрипт создания такого черута, чем патчить сам конфигуре, прописывая пути к нужным сырцам и библам.
зы:
ldd грузит согласно своим настройкам, а не оттуда, где лежали в момент компиляции и LD_LIBRARY_PATH никто пока не отменял.
>вот по этому в черут запихивают не только проги, но и хидеры,
>и сырцы, и библы, и даже их определённые версии (но с
>этим сложнее - в любом случае, если версии библ не совместимы,
>то они не совместимы. и надо прекращать и разбираться).
>в любом случае, после сборки сырцы и хидеры проге уже не нужны.
>да и всегда есть различные вариации --prefix.Угу. Только эти вариации как раз не всегда работают. А то и просто отсутствуют.
>в общем, гораздо проще для конкретной проги написать по её требованиям скрипт
>создания такого черута, чем патчить сам конфигуре, прописывая пути к нужным
>сырцам и библам.Для конкретной — да. А вот поддерживать для каждой проги свою песочницу — это проще сразу застрелиться. Хорошая система портов тем и хороша, помимо прочего, что облегчает работу не только (и не столько) конечному юзеру, которому нужны обычно только бинарники, сколько мэйнтейнеру. У меня пока что плохо укладывается, как автоматически раскидывать под каждую прогу сорцы-либы так, как ей надо (ведь софт в чруте может между собой тоже взаимодействовать: скажем, искомая прога юзает gettext, и какая-то её зависимость, живущая в chroot, тоже его юзает — если у этих двух сущностей понятие о том, где живёт gettext, будет отличаться, жди беды; и это самый простой, приходящий сходу в голову пример).
>зы:
>ldd грузит согласно своим настройкам, а не оттуда, где лежали в момент
>компиляции и LD_LIBRARY_PATH никто пока не отменял.Согласен, ступил, прошу прощения.
>У меня пока что плохо укладывается, как автоматически раскидывать под каждую прогу сорцы-либы так, как ей надомыслите так, как её разработчик.
и тогда вдруг окажется, что вариантов не так уж и много.
Зато, если помыслить как разработчик - вдруг внезапно понимаешь что протестить закидоны всех 100500 возможных компилеров и утилсов нихрена не выйдет. Поэтому можно или тупо потребовать гнутый набор утилей и просто отшивать совсем если его нет, или предоставить юзерам экзотов вытоптать баги. А что, есть еще какие-то осмысленные варианты действий?
о чем и речь.
а создать в черуте окружение (хоть для гнутых, хоть для выгнутых) и собирать в песочнице - вполне можно.
причем параметры это песочницы могли бы в свои порты запихнуть для каждой проги в отдельности и парочку по умолчательных по выбору (к примеру - штатная сборка проги из ппа убунты).
но они предпочли писать патчи к конфигуре - их право, но в конце концов и их проблемы.
>о чем и речь.
>а создать в черуте окружение (хоть для гнутых, хоть для выгнутых) и
>собирать в песочнице - вполне можно.
>причем параметры это песочницы могли бы в свои порты запихнуть для каждой
>проги в отдельности и парочку по умолчательных по выбору (к примеру
>- штатная сборка проги из ппа убунты).
>но они предпочли писать патчи к конфигуре - их право, но в
>конце концов и их проблемы.<много мата skipped>
Ещё раз повторяю то, что вы упорно не понимаете: autoconf просит GNU-окружение НЕ для себя, а для конечной программы. Которую — ну вот собрали в chroot с GNU-прогами. А потом установили в собственно систему без GNU. То есть в ДРУГОЙ СИСТЕМЕ. Вы понимаете, что вы бред предлагаете? Смысл использования autoconf ТЕРЯЕТСЯ если его таким образом обманывать!
Программа может действительно зависеть от GNU окружения. А может и не зависеть. В любом случае, это уже отдельный разговор.
И autoconf (это, опять же, понятно любому нормальному человеку, кроме вас), если он называет себя средством для портирования приложений, должен проверять только одно: есть ли в конечной системе всё необходимое для работы _программы_. Иначе это не средство портирования, а механизм для внедрения GNU-окружения. Пусть честно это так называют. И претензий тогда, что с autoconf программы портировать сложно, не будет возникать: это ж не средство для портирования, а так, довесок.
>бред предлагаете? Смысл использования autoconf ТЕРЯЕТСЯ если его таким образом
>обманывать!ИМХО, смысл использования автоконфа - чтобы он проверил что у вас есть нужное окружение и собрал важные для сборки параметры типа размеров типов данных и прочая. При этом никто и ни в каком месте не гарантирует что произвольно взятое окружение с какими-то левыми утилями (типа упомянутых TAR с архаичным лимитом на путь в 100 символов) - всенепременно подойдет для сборки. А то я могу написать свой TAR который вообще ни с чем не совместим а потом истекать - а чойта его автотулсы не нашли?! Как же так?! Ведь его функционал - достаточный! Пусть узнают о его существовании и командных параметрах методом телепатии! (а как еще они это могут сделать? oO)
>Зато, если помыслить как разработчик - вдруг внезапно понимаешь что протестить закидоны
>всех 100500 возможных компилеров и утилсов нихрена не выйдет. Поэтому можно
>или тупо потребовать гнутый набор утилей и просто отшивать совсем если
>его нет, или предоставить юзерам экзотов вытоптать баги. А что, есть
>еще какие-то осмысленные варианты действий?Самое интересное, что любители экзотики даже версию подменить не смогут - ибо априори в курсе, что если оно вдруг где-то откажется работать (а оно не имеет всего функционала GNU-окружения однозначно) - их закидают тухлыми помидорами. Поэтому ждут, что начнут подстраиваться под них. Ан фиг. Отсюда и вопли.
>Поверьте (а хотите — проверьте), разбираться в нутре pf проще, чем дебрях
>этого крапа.ой ли... netfilter куда проще и понятнее, чем pf. в нем хоть номера тегов стали статическими, или при каждой перезагрузке правил новые номера? :)
И прохождения пакета по правилам pf'а всё ещё лочит целиком ядро? :)
>>Поверьте (а хотите — проверьте), разбираться в нутре pf проще, чем дебрях
>>этого крапа.
>
>ой ли... netfilter куда проще и понятнее, чем pf.Исходники netfilter не ковырял, сравнить не могу. А что вам в исходниках pf не понравилось?
> в нем хоть
>номера тегов стали статическими, или при каждой перезагрузке правил новые номера?
>:)А вам, простите, зачем? В ioctl для имён используются текстовые строки.
>И прохождения пакета по правилам pf'а всё ещё лочит целиком ядро? :)
Это уже не к самому pf. Впрочем, даже с этими локами пропускной способности более чем хватает.
Согласен с "одним из разработчиков OpenBSD" - такая привязка есть, и могу его порадовать: и не только в Autoconf. :)Сам сколько писал - так и поступал - требовал наличие gnu coreutils & etc.
Ну на кой мне разбираться что там у него в системе еще есть? Проше указать в требованиях то что я знаю и использую. Кроме *BSD есть еще куча unix-ов, с корявым System5, тот же solaris :)
В одном скрипте я даже версию bash требовал!!!
Я не понимаю такой паталогии - избавляться от gnu utils.
если есть замена гнутым тузлам, то нафига они нужны?
да они просто банально лучше.
вот тотже "негнутый" tar до сих пор больше 100 символов путь не понимает (из солярки)
егрип не егрипит и т.д.а разработчикам аутоконф теперь что, солярку ставить и проверять все эти глюки?
кому надо, тот пусть и патчи пишет или своё выпускает.
либо пусть ставит всё скопом и работает.
>да они просто банально лучше.
>вот тотже "негнутый" tar до сих пор больше 100 символов путь не
>понимает (из солярки)это стандарт вобще-то.
пруф на стандарт, где я не могу создать файл с именем больше 100.
зы:
это не стандарт, это какашки мамонта.
>>да они просто банально лучше.
>>вот тотже "негнутый" tar до сих пор больше 100 символов путь не
>>понимает (из солярки)
>
>это стандарт вобще-то.Стандарт — это pax. Если о птичках. Правда, любитель GNU о нём, похоже, не слышал. :)
да?!! с нетерпением жду продолжения, посмеёмся :D
зы:
а то любителей щёки дуть и пальцы гнуть хватает.
но вы же не такой? всё разъясните, покажете и расскажете, и с пруфлинком на 100 символов выйдете победителем? не? :D
>да?!! с нетерпением жду продолжения, посмеёмся :D
>зы:
>а то любителей щёки дуть и пальцы гнуть хватает.
>но вы же не такой? всё разъясните, покажете и расскажете, и с
>пруфлинком на 100 символов выйдете победителем? не? :DПревышение этих самых 100 символов приводит к проблемам с совместимостью, вы в курсе? Файлы, созданные GNU tar в итоге может гарантированно читать только GNU tar. Вам это не напоминает, случайно, тактику известной мелкомягкой конторы? ;)
Что вам разъяснить-то? Что в SUS нет утилиты tar?
достаточно пруфа из pax
>Превышение этих самых 100 символов приводит к проблемам с совместимостью, вы в курсе? Файлы, созданные GNU tar в итоге может гарантированно читать только GNU tar.ну всё. ж..па пришла - в файловой системе такие файлы создавать можно, а вот архивные копии на ленту - ни-ни.
победа ума над разумом.
>достаточно пруфа из pax
>>Превышение этих самых 100 символов приводит к проблемам с совместимостью, вы в курсе? Файлы, созданные GNU tar в итоге может гарантированно читать только GNU tar.
>
>ну всё. ж..па пришла - в файловой системе такие файлы создавать можно,
>а вот архивные копии на ленту - ни-ни.
>победа ума над разумом.В третий раз тыкаю: tar не есть POSIX-утилита. Есть pax, умеющий, в том числе, и читать-записывать tar-архивы. Так же pax умеет и формат cpio, в котором таких ограничений нет. Но линуксоидам это не известно, во многих дистрибутивах cpio и pax вообще изначально отсутствуют. Это самые натуральные двойные стандарты. Так что прежде чем требовать патчей для вашего софта, сначала приведите его в порядок. Глядишь, и велосипеды изобретать не придётся.
>В третий раз тыкаю: tar не есть POSIX-утилита.в третий раз говорю, если тар - это не посих, то какого хрена в солярном дистре тар не умеет больше 100 символов?
из-за стандарта нельзя? тогда из-за какого стандарта нельзя?
>>В третий раз тыкаю: tar не есть POSIX-утилита.
>
>в третий раз говорю, если тар - это не посих, то какого
>хрена в солярном дистре тар не умеет больше 100 символов?
>из-за стандарта нельзя? тогда из-за какого стандарта нельзя?Из-за такого, что другие реализации tar не поймут такой файл.
Это как MS OpenXML реализовала в Office 2007, потом спецификации опубликовала, оформила как стандарт — а потом выясняется, что в стандарте одно, а в файлах, которые Office создаёт, — другое. И вместо открытого стандарта опять получается привязка к конкретному производителю.
Может быть, вам это нравится — тогда умолкаю, спорить не о чем.
стандарт батенька. приведите стандарт.зы:
и это косвенным образом подтверждает правильность требований аутоконфа к гну/тару.
а то распакуют так другим и не соберётся - опять аутоконф будет виноват.
man cpio
...
STANDARDS
There is no current POSIX standard for the cpio command; it appeared in
ISO/IEC 9945-1:1996 (“POSIX.1”) but was dropped from IEEE Std 1003.1-2001
(“POSIX.1”).The cpio, ustar, and pax interchange file formats are defined by IEEE Std
1003.1-2001 (“POSIX.1”) for the pax command.HISTORY
The original cpio and find utilities were written by Dick Haight while
working in AT&T's Unix Support Group. They first appeared in 1977 in
PWB/UNIX 1.0, the “Programmer's Work Bench” system developed for use
within AT&T. They were first released outside of AT&T as part of System
III Unix in 1981. As a result, cpio actually predates tar, even though
it was not well-known outside of AT&T until some time later.This is a complete re-implementation based on the libarchive(3) library.
BUGS
The cpio archive format has several basic limitations: It does not store
user and group names, only numbers. As a result, it cannot be reliably
used to transfer files between systems with dissimilar user and group
numbering. Older cpio formats limit the user and group numbers to 16 or
18 bits, which is insufficient for modern systems. The cpio archive for‐
mats cannot support files over 4 gigabytes, except for the “odc” variant,
which can support files up to 8 gigabytes.FreeBSD 8.0 December 21, 2007 FreeBSD 8.0
man pax
...
STANDARDS
The pax utility is a superset of the IEEE Std 1003.2 (“POSIX.2”) stan‐
dard. The options -z, -B, -D, -E, -G, -H, -L, -P, -T, -U, -Y, -Z, the
archive formats bcpio, sv4cpio, sv4crc, tar, and the flawed archive han‐
dling during list and read operations are extensions to the POSIX stan‐
dard.HISTORY
The pax utility appeared in 4.4BSD.AUTHORS
Keith Muller at the University of California, San DiegoBUGS
The pax utility does not recognize multibyte characters.FreeBSD 8.0 July 3, 2004 FreeBSD 8.0
где там про 100? и про tar?
вот блин любители лапшу на уши вешать!
>где там про 100? и про tar?
>вот блин любители лапшу на уши вешать!Это техническое ограничение, вызванное самой структурой заголовка. Проще всего глянуть на педивикии: http://en.wikipedia.org/wiki/Tar_(file_format)
статья мягко говоря устарела. например из того же заголовка следует:
>Thus although there are 12 bytes reserved for storing the file size, only 11 octal digits can be stored. This gives a maximum file size of 8 gigabytes on archived files.8 гб для архива?
ну и наконец добрались до моего первоначального вопроса.
какого хера санки не выпустят новую версию тара без этих дурных ограничений?
и я даже отвечу - лень. и так работает. и без встроеного gzip/bzip2/итд
так что заменить тот же гнутар автоконфигу нудо сразу несколькими утилитами. а в случае с bzip2 - так ещё и его поставить. а дальше ещё другие параметры, кодировки,.....
логично, что проще сразу установить гнутый тар и не иметь проблем.
>Это техническое ограничение, вызванное самой структурой заголовка.Лимит на 100 символов в пути в 2010 году - это совершенно неадекватная некромансия. Даже в всеми обосраном маздае лимит символов обычно хотя-бы 255...
консультации по пользованию гуглем - 50$/час
то же, но с использованием ключевого слова Solaris - 300$/час.
ха! да я тебе и бесплатно консультацию дам - нет такого стандарта.
а все отмазки, что "старые тары не поймут" решаются просто - используй новую версию тар.к тому же, если вы хотите собрать опенсорсный проект, в котором используется гнутый тар, то тогда требования автоконфа справедливы - ваш же "стандартный тар" и не поймёт.
>ха! да я тебе и бесплатно консультацию дам - нет такого стандарта.
>жжоте, товарищ :)
IEEE Std 1003.1, стало быть, так таки и нету?
ну так прочитай его! :D
нету там никаких 100 символов.
Бегло пробежал стандарт и исходники. 100 в стадарте не нашел. Зато нашел, что сандарт во всю ссылается на PATH_MAX (что есть длина пути без файла).
Solaris нет, у кого есть пусть глянут
FreeBSD 8.0 - /usr/include/sys/syslimits.h:
#define NAME_MAX 255 /* max bytes in a file name */
#define PATH_MAX 1024 /* max bytes in pathname */И POSIX тоже есть:
/usr/include/limits.h:#define _POSIX_PATH_MAX 256Итого 1024+255=1275 (минус 2 байта на \0 в каждой переменной + 1 байт на \0 в результирующей) - длина пути с именем файла 1274.
Но там же, есть еще объявление:
/usr/include/limits.h:#define _POSIX_PATH_MAX 256CentOS 5.4 Чесное слово - зоопарк. Там этих define штук 30. Взял из тех же limits (как наиболее похожих на системное):
/usr/include/linux/limits.h:
#define PATH_MAX 4096 /* # chars in a path name including nul */Тут тоже Posix есть:
/usr/include/bits/posix1_lim.h:
#define _POSIX_PATH_MAX 256NAME_MAX или нечто подобное не искал - и так ясно, что длинее, чем в том же FreeBSD и posix.
Сам tar (ни posix ни bsd) не ковырял на предмет откуда они лимиты берут из системы или сами придумывают (в этом случае вообще тушите свет).Итого, POSIX по сути лимиты особо не регламентирует (по крайней мере определения PATH_MAX я не нашел, смотрел бегло, так что может оно и есть) - что хош, то и пользуй (по крайней мере в Linux и FreeBSD использются свои лимиты), хотя в обеих системах какое-то определение есть (256). И тут дело похоже не в реализации tar (gnu/bsd), а системных лимитах. Если gnu tar написан нормально и он использует системные определения лимитов (что вобщем логично), то на BSD допустимая длина пути в архиве созданном gnu tar-ом будет меньше, чем на linux.
Кстати, получается Windows со своим лимитов в 256 байтов на длину был более posix совместим :) Не знаю, может уже и увеличили, не слежу...
Но вот что забавно, на том CentOS, я выкопал:
/usr/include/linux/un.h:#define UNIX_PATH_MAX 108
/usr/include/linux/un.h: char sun_path[UNIX_PATH_MAX]; /* pathname */И судя по словам Unix и sun - на каких-то Solaris, возможно, системный лимит был 108 байтов. Так что уважаемый, если человек что-то говорит, совсем не обязательно что это ложь, надо просто разобраться.
По сути топика.
Разница-то в основном не в лимитах, а в реализации, возможностях, ключах. И мне непонятно, почему набор инструментов, для настройки пакета под конкретную платформу (где предусмотрена поддержка не только gnu платформ!) требует определенных именно gnu utilities. Да, я знаю, что BSD find беднее GNU find, да bash не идет в базовой системе FreeBSD, но при этом, почему-то, некоторые утилиты требуют его (как и возможностей gnu-utils), хотя, им было бы достаточно функциональности простого sh.Мне кажется, что разработчикам automake/autoconf (раз уж они поддерживают не только gnu платформы) стоило бы добавить поддержку инструментов используемых по умолчанию на других распространенных платформах, при этом оставив возможность требования наличия определенной реализации инструментов конкретным пакетом. В таком случае, это уменьшит кол-во проблем при портировании, увеличит совместимость ПО на разных платформах. И вообще, решит кучу проблем.
С отправкой патчей я думаю фокус не пройдет, потому что, скорее всего, он просто менят путь с gnu на openbsd specific (например), и при внесении такого патча в код autotools все сломается на gnu. Тут нужен другой подход - нужно, чтобы разработчики autotools обратили внимание на проблему и добавили соответствующий функционал, а не просто поменяли шило на мыло. Собственно, он и обратил их внимание.
>Мне кажется, что разработчикам automake/autoconf (раз уж они поддерживают не только gnu
>платформы)может я чего не понимаю но возможно разработчики имели ввиду поддержку сборки под разные платформы именно в гну окружении?
>>Мне кажется, что разработчикам automake/autoconf (раз уж они поддерживают не только gnu
>>платформы)
>
>может я чего не понимаю но возможно разработчики имели ввиду поддержку сборки
>под разные платформы именно в гну окружении?Вот и спросите у них, если то, что написано у них на сайте, вы считаете нечётко сформулированным.
>Бегло пробежал стандарт и исходники. 100 в стадарте не нашел. Зато нашел, что сандарт во всю ссылается на PATH_MAXмакпас этот не что иное, как длина в той фс, где запускается. т.е. искать надо не в исходниках, а в рантайме той системы, где работает. видите ли, такому символьному устройству, как лента - всё равно.
лишь бы архивы были не битые. так что искали вы не там.
>Мне кажется, что разработчикам automake/autoconf (раз уж они поддерживают не только gnu платформы) стоило бы добавить поддержку инструментов используемых по умолчанию на других распространенных платформах,угу. а ещё точно узнать какой макспас будет у каждого собирающего и какая фс.
а ведь там ещё и масса других различий. например, тот же сановский так не поддерживает ни gzip, ни bzip2. там предлагается использовать пайп из одноимённых команд. а ещё бывают глюки с кодировками. и iconv там не такой.
честное слово, проще взять утиль из того же набора, что и autoconf. да и посикс гнушные итили поддерживают лучше остальных ($ getconf _POSIX_VERSION выдаёт у меня 200809)
не, вы друг степей однозначно. почитайте описание утилиты pax, формат ustar.
я вам не друг.
и обороты вашей речи на меня не действуют.когда автосонф потребует pax, а не gnu/tar (который держит gzip и bzip2) - тогда и приходите.
>когда автосонф потребует paxХвати уже? Они слили, так фигли-то сопли размазывать?
Марк-опенбэсэдэшник : опеннет -- 228 : YHBT*228
см.посты ##184 и 227 + самостоятельный поиск "yhbt" по этой странице
(*Да, и кста, мне тоже окулиста: я не вижу _автора новости -- кого "благодарить" за такой "годный вброса"??? ЗАКАПЫВАЙТЕ, ВЫКЛЮЧИТЕ ВЕНТИЛЯТОР*)
да! знатные посиделки вышли!
>я вам не друг.
>и обороты вашей речи на меня не действуют.
>
>когда автосонф потребует pax, а не gnu/tar (который держит gzip и bzip2)
>- тогда и приходите.Выдержки из tar(1) в OpenBSD:
<...>
SYNOPSIS
tar {crtux}[014578befHhjLmOoPpqsvwXZz]
[blocking-factor | archive | replstr] [-C directory] [-I file]
[file ...]
tar {-crtux} [-014578eHhjLmOoPpqvwXZz] [-b blocking-factor]
[-C directory] [-f archive] [-I file] [-s replstr] [file ...]
<...>
-z Compress archive using gzip(1).
<...>
-j Compress archive using bzip2. The bzip2 utility must be in-
stalled separately.
<...>Внимание, вопрос: если функционал ЕСТЬ, то какого чёрта autoconf утверждает, что его нет? Какого чёрта он пишет "checking if <утилита> supports <фича>", а в реальности проверяет, GNU-тая ли она? Пусть хотя бы честно пишет: "checking if GNU <утилита> installed", будет сразу понятно, что аффтар ничего другого признавать не хочет (что есть разговор отдельный). А текущая ситуация выглядит крайне превратно.
а чёрт её знает?
может потому шта ни одному бздишнегу не пришла в голову мысль сесть и исправить.
всё по форумам да по форумам, вот и замотались?
>а чёрт её знает?
>может потому шта ни одному бздишнегу не пришла в голову мысль сесть
>и исправить.В том-то и дело, что исправлять постоянно приходится, если вы ещё не поняли. Косяк за косяком…
>всё по форумам да по форумам, вот и замотались?
Согласен, я дурак, что постоянно ведусь на провокации людей вроде вас…
я уже говорил что и где исправлять надо.
а не патчи к конфигуре.ин
>я уже говорил что и где исправлять надо.Ну, нипанимають ани разницы между автоконфом и его "данными"+++
>а не патчи к конфигуре.ин
.ac
Файл: configure.ac Строка 1 Позиция 0 24249 байт 4%
# -*- Autoconf -*-
# Process this file with autoconf to produce a configure script.
да-а-а. заболтался я что-то.
>В третий раз тыкаю: tar не есть POSIX-утилита.в порядке аллаверды - гну тар если его как след попросить запишет вполне себе ustar архив. но для этого же надо, чтоб народ об этом хоть бы задумывался.
проблема-то не в этом. проблему выше кто-то прекрасно озвучил: некоторым разработчикам начхать на проблемы пользователей, возникающие при установке/работе/etc. "И вот так у них все"(ТМ) это вполне работающий подход, пока основной пользователь - сам девелопер, но у него есть и определенные минусы, в частности, мирового доминирования достичь труднее :)
>Стандарт — это pax. Если о птичках. Правда, любитель GNU о нём,
>похоже, не слышал. :)Покажите иной тулчейн компилеров способный сожрать столько же платформ сколько GCC? А раз так - имхо пользоваться фичами гнутых компилеров и тулзов все-таки не позорно (благо, оно работает под *bsd если не переть на принцип "все вокруг под bsdl" что как-то у некоторых хреново получается 1 фиг). Хотя последствия этого стоит понимать.
>>вот тотже "негнутый" tar до сих пор больше 100 символов путь не
>>понимает (из солярки)
>это стандарт вобще-то.Пусть убьются веником с таким "стандартом". TAR - это утилита архивирования файловой системы, для начала. На файловой системе путь может быть и больше 100 символов. Нахрена нужна утилита которая не сможет справиться с своими прямыми обязанностями? А то может мы еще должны имена в стиле 8.3 использовать? oO
>да они просто банально лучше.если пользователю не нужна гнутая утилита, а программе достаточно не гнутой, то зачем автоконф её должен требовать?
>вот тотже "негнутый" tar до сих пор больше 100 символов путь не
>понимает (из солярки)
>егрип не егрипит и т.д.
>
>а разработчикам аутоконф теперь что, солярку ставить и проверять все эти глюки?само собой разработчики автоконфа никому ничего не должны, но их программа не совсем правильно делает то для чего она предназначена, и речь идёт о том чтобы они обратили внимание на это.
>если пользователю не нужна гнутая утилита, а программе достаточно не гнутой, то зачем автоконф её должен требовать?аутосонф - и есть гнутая утилита. она вам нужна?
>само собой разработчики автоконфа никому ничего не должны, но их программа не совсем правильно делает то для чего она предназначена, и речь идёт о том чтобы они обратили внимание на это.The GNU build system, also known as the Autotools, is a suite of programming tools produced by the GNU project.
The GNU build system comprises the GNU utility programs Autoconf, Automake, and Libtool [3]. Other related tools frequently used with the GNU build system are GNU’s make program, GNU gettext, pkg-config, and the GNU Compiler Collection, also called GCC.
надеюсь что разработчики автоконфа в здравом уме в отличии от Вас, и примут к сведению замечания.
а вы всегда так хамить начинаете? вас вроде слабоумным никто не называл?для сборки приложений необходим инструментарий.
гну/аутоконф из состава гну/буилд/систем, которой нужен для работы корэутилс.
вы хотите выдрать пару утилит и чтобы оно работали? да ещё чтобы это кто-то сделал?ну и если вы такой умный - напишите патч и исправьте ситуацию.
если бы вы фанатично не отстаивали недостатки автоконфа, а приняли бы критику достойно, никто бы не засомневался в Вашем здравом смысле.
если бы каждый, кому нужно что-то исправить в той или иной утилите делал и высылал патч, то их тоже не называли бы идиотами.
>если бы каждый, кому нужно что-то исправить в той или иной утилите
>делал и высылал патч, то их тоже не называли бы идиотами.
>не сомневаюсь что кто-нибудь да напишет патч, Марк обосновал необходимость внесения таких изменений, а мы обсуждаем прав он или нет, будут ли внесены эти изменения или нет, это второй вопрос.
Ну так если ему нужен патч - пусть берет и пишет, а то его спичем он столько развел эпичное трололо как минимум на опеннете :-/
>если пользователю не нужна гнутая утилита, а программе достаточно не гнутой, то зачем автоконф её должен требовать?Просто автор проги даже НЕ знает про вашу не гнутую утилиту!!!
а пользователю наплевать - если ему нужна прога, он поставит для ее сборки нужное окружение (читай gnu utils & gcc) и получит то что хотел.
После подсистемы linux во freebsd это все такие мелочи :))))))))
Ну вот, теперь и линукс наводнился недалекими разработчиками...
>Я не понимаю такой паталогии - избавляться от gnu utils.избавляться? wtf
от них приходится не избавляться, а ставить в систему.ваш ответ - прекрасная иллюстрация топика. мир состоит из одного линя, остальных систем не существует. в результате мейкфайлы без gnu make не работают, тары с линукс системы на аиксе не распаковываются, и так далее.
Just as planned
>Just as plannedУгу. Та же вирусная тактика, в которой обвиняли MS и иже с ней.
так разницы же действительно никакой. о двуличности линуксоидов было исписано мегабайты текстов.
по принципу "наши - разведчики, чужие - шпионы"
>Угу. Та же вирусная тактика, в которой обвиняли MS и иже с ней.А у бздунов какая тактика? Поюзать что есть а потом при возможности выкинуть? Тоже как-то не очень кооперативная тактика, отдающая вирусностью/борьбой за чистоту рядов и до кучи двухстандартностью (ну вон с ZFS - пока своего нормального нет, и CDDL сойдет, а было бы - наверняка обосрали бы и выкинули, как обычно). Оно чем-то принципиально лучше такое? oO
>>Угу. Та же вирусная тактика, в которой обвиняли MS и иже с ней.
>
>А у бздунов какая тактика? Поюзать что есть а потом при возможности
>выкинуть? Тоже как-то не очень кооперативная тактика, отдающая вирусностью/борьбой за чистоту
>рядов и до кучи двухстандартностью (ну вон с ZFS - пока
>своего нормального нет, и CDDL сойдет, а было бы - наверняка
>обосрали бы и выкинули, как обычно). Оно чем-то принципиально лучше такое?
>oOВ ходе юзания, между прочим, помогают фиксить всплывающие баги. Так что польза исходному проекту тоже есть. Честно говоря, не вижу криминала в том, чтобы перейти с тулкита A на тулкит B по лицензионным причинам. Вы же переходите по возможности с пропиетарного ПО на GPL'ное? ;)
да не вопрос. переходите, ктож мешает то.
вот только заявы вида "вот эту утиль из гну я хочу, а вот эту нет" и "нука исправьте" - выглядят смешно. хочешь своего буратину? пили сам.
>Вы же переходите по возможности с пропиетарного ПО на GPL'ное? ;)Да, но строго говоря, BSDL в софте не является для меня каким-то абсолютно фатальным условием для его юзежа - я юзаю некоторое количество софта под BSDL или дуальными лицензиями и не ставлю целью выпилить его "потому что он под BSDL", а хотя-бы и предпочел бы GPL. Вот проприетарность - хороший повод обойти сторонкой при первой же возможности (не люблю лишний геморрой). Просто я считаю что GPL лучше защищает мои интересы и дает потенциально больше шансов на развитие проекта вместо расхапа. Но это не мешает существованию хорошего софта. Да, кстати, можно я поворчу про вашу любимую прогу? Глядя на OpenSSH (вы очень любите его хвалить), хочу сказать: этот монстр начинает напрягать. Лично мне от ssh надо как правило секурный шелл. Отвертку грубо говоря. Желательно кушающую поменьше ресурсов. А мне по дефолту целый швейцарский нож впаривают. Тут вам и SFTP как правило включенный по дефолту зачем-то, и всякие форварды портов куда попало, etc. Все, конечно, круто, кроме того что за таким количеством активных по дефолту сущностей следить геморройно и можно продолбаться, позволив некоему ограниченному юзвергу сильно больше чем хотелось бы, если быть хоть немного невнимательным. Вот такое свойство секурного сервиса как-то напрягает.
>>Вы же переходите по возможности с пропиетарного ПО на GPL'ное? ;)
>
>Да, но строго говоря, BSDL в софте не является для меня каким-то
>абсолютно фатальным условием для его юзежа - я юзаю некоторое количество
>софта под BSDL или дуальными лицензиями и не ставлю целью выпилить
>его "потому что он под BSDL", а хотя-бы и предпочел бы
>GPL. Вот проприетарность - хороший повод обойти сторонкой при первой же
>возможности (не люблю лишний геморрой). Просто я считаю что GPL лучше
>защищает мои интересы и дает потенциально больше шансов на развитие проекта
>вместо расхапа. Но это не мешает существованию хорошего софта.Дык дело не в существовании хорошего софта, а в том, что проект использовать сложнее, когда различные его составные части из разных лицензий. С этим-то спорить не будете? :)
> Да, кстати,
>можно я поворчу про вашу любимую прогу? Глядя на OpenSSH (вы
>очень любите его хвалить), хочу сказать: этот монстр начинает напрягать. Лично
>мне от ssh надо как правило секурный шелл. Отвертку грубо говоря.
>Желательно кушающую поменьше ресурсов. А мне по дефолту целый швейцарский нож
>впаривают. Тут вам и SFTP как правило включенный по дефолту зачем-то,Ну отключите вы его поддержку (которая, к слову, обычно вообще отдельной прогой реализуется, а не самим sshd). А я включу fish:// в KDE, и поимею то же самое, пусть и чуть медленнее. :) Вот как раз шелл отключать, оставляя только SFTP, иногда имеет смысл.
>и всякие форварды портов куда попало, etc.
В разных ОС разные дефолты, к слову. По умолчанию — да, форвард портов разрешён. Поскольку если уж человеку доверяют шелл, опять же, он может и сам проксю прикрутить какую-нибудь.
> Все, конечно, круто, кроме
>того что за таким количеством активных по дефолту сущностей следить геморройно
>и можно продолбаться, позволив некоему ограниченному юзвергу сильно больше чем хотелось
>бы, если быть хоть немного невнимательным. Вот такое свойство секурного сервиса
>как-то напрягает.А если не быть внимательным с правами на папки и поставить где-нибудь 0777 вместо 0755, то вообще страшные вещи могут случиться. :) Если не уверены в результате своих действий - у sshd есть параметр -T, почитайте. ;)
>>Угу. Та же вирусная тактика, в которой обвиняли MS и иже с ней.
>
>А у бздунов какая тактика? Поюзать что есть а потом при возможности
>выкинуть? Тоже как-то не очень кооперативная тактика, отдающая вирусностью/борьбой за чистоту
>рядов и до кучи двухстандартностью (ну вон с ZFS - пока
>своего нормального нет, и CDDL сойдет, а было бы - наверняка
>обосрали бы и выкинули, как обычно). Оно чем-то принципиально лучше такое?
>oO"Вирусная инвазия" — это когда что-то заражается чем-то, болеет долго и страдальчески. С ZFS страдальческой болезни у FreeBSD никакой, только линуксоиды почему-то ноют, что им тяжко от этого.
iZEN, ты тут страдаешь больше всех. У тебя вирус? :)
да нифиг уже zfs не вперлась линуху.
года бы 3-и назад - да. а сейчас даже "на_посмотреть" не нужна.
зы:
носитесь с ней как с писанной торбой. лучше бы tar в соляре к божескому виду привели.
а то с ним половины сырцов не собирается
>>Я не понимаю такой паталогии - избавляться от gnu utils.
>
>избавляться? wtf
>от них приходится не избавляться, а ставить в систему.
>
>ваш ответ - прекрасная иллюстрация топика. мир состоит из одного линя, остальных
>систем не существует. в результате мейкфайлы без gnu make не работают,
>тары с линукс системы на аиксе не распаковываются, и так далее.
>А кто должен проверить допустимость использования не-gnu утилиты для сборки данной на маргинальной платформе? Разработчик??? А нахрена ему это надо? Это задача майтейнера программы на данной платформе или конечного пользователя. И сопли майтейнера из OpenBSD абсолютно непонятны... Он должен выполнять взятые на себя обязательства или уйти со своего поста.
>А кто должен проверить допустимость использования не-gnu утилиты для сборки данной на маргинальной платформе? Разработчик??? А нахрена ему это надо?ггг кто бы говорил о маргинальной платформе :)))
не, не вопрос. если интересует, чтобы продукт работал только на своей машине, то такой подход вполне прокатит.
>>А кто должен проверить допустимость использования не-gnu утилиты для сборки данной на маргинальной платформе? Разработчик??? А нахрена ему это надо?
>
>ггг кто бы говорил о маргинальной платформе :)))
>
>не, не вопрос. если интересует, чтобы продукт работал только на своей машине,
>то такой подход вполне прокатит.Спасение утопающих - дело рук самих утопающих. Маргинальных платформ как грязи и это забота пользователей этих платформ помочь автору патчами или не использовать данную программу.
> не, не вопрос. если интересует, чтобы продукт работал только на своей машине,Ну так все только орут что автотулсы крап, но менее грабельной системы почему-то никто не предложил. То что сватают - еще хреновее по портабельности и грабельнее.
>не, не вопрос. если интересует, чтобы продукт работал только на своей машине,
>то такой подход вполне прокатит.А может проще? гну утилс портированы практически на все платформы, поэтому я пишу в расчете на них, более того, целевая платформа, после Linux конечно, Unix-ы, а не OpenBSD.
зы. вообще-то за мою работу платят деньги, и поэтому ставят условия - поддерживаемые системы: RHEL/Centos, OpenSUSE/SLES, Debian. Иногда всплывают Solaris/HP-UX/Irix, но не разу не было OpenBSD.
вот и я поражаюсь этой (не побоюсь этого слова :D) наглости.
мало того, что прогу нахаляву получают, так еще и требуют - "чтоб вот так собиралась, а вот так я не хочу!"
ладно если бы она вообще не собиралась. или криво. или с багами.
а то чисто из-за красноглазия - "нихочу так! сделай вот так"
>вот и я поражаюсь этой (не побоюсь этого слова :D) наглости.
>мало того, что прогу нахаляву получают, так еще и требуют - "чтоб
>вот так собиралась, а вот так я не хочу!"
>ладно если бы она вообще не собиралась. или криво. или с багами.
>
>а то чисто из-за красноглазия - "нихочу так! сделай вот так"Если конфигуратор требует GNU-тую утилиту, то он требует его не для себя, а для проги. Если проге в реальности не нужна именно GNU-версия, а конфигуратор всё равно требует только GNU — это кривость конфигуратора. Как это можно упорно отвергать — не понимаю.
>Если конфигуратор требует GNU-тую утилиту, то он требует его не для себя,
>а для проги. Если проге в реальности не нужна именно GNU-версия,
>а конфигуратор всё равно требует только GNU — это кривость конфигуратора.
>Как это можно упорно отвергать — не понимаю.еще раз для тех кто в танке :)
Просто автор проги даже НЕ знает про вашу не гнутую утилиту!!! он тестировал свою прогу с GNU utils, потому что знает что GNU utils & gcc работает везде, еще он знает, что со старыми SystemV utis его прога не будет работать/собираться - так там нет НУЖНОГО ему функционала.
А вы........ просто не целевая группа для него. ;)
И пользователю наплевать - если ему нужна прога, он поставит для ее сборки нужное окружение (читай gnu utils & gcc) и получит то что хотел. И наверно это лучший выход, чем перепахивать исходники, подгоняя их к вашим любимым утилитам. Хотя некоторые делают еще радикальнее - меняют систему на один из Linux-ов, как это было во многих конторах, где так любили bsd.
>вот и я поражаюсь этой (не побоюсь этого слова :D) наглости.
>мало того, что прогу нахаляву получают, так еще и требуют - "чтоб
>вот так собиралась, а вот так я не хочу!"
>ладно если бы она вообще не собиралась. или криво. или с багами.
>
>а то чисто из-за красноглазия - "нихочу так! сделай вот так"Именно криво и с багами. В чёрт-знает-уже-который раз повторяю, что дело НЕ ограничивается одними лишь GNU-утилитами (которые, к слову, тоже надо портировать… замкнутый круг?). GNU toolchain то не находит нужные библиотеки, то цепляет лишние (из-за этого софт, собираемый GNU libtool, нормально не соберёшь, если другая версия этого софта уже есть в системе; предвосхищая ваши вопли «напишите свой libtool» — уже написали), то не те заголовочные файлы ищет, то вообще оказывается по ошибке привязанным, скажем, к распоследней версии GCC…
как тяжело быть бздишнегом.
вот вам дружеское плечо, поплачьте.
>как тяжело быть бздишнегом.
>вот вам дружеское плечо, поплачьте.Когда вы научитесь вместо сочувствия выказывать уважение, тогда и разговор будет вменяемый.
уважение? помнится торвальдсу не понравились системы контроля версий, так он сказал, что пока не сделает свою нового ядра не ждите.
через 3-е недели вышло новое ядро.другими словами, я вам сочувствую. искренне.
>уважение? помнится торвальдсу не понравились системы контроля версий, так он сказал, что
>пока не сделает свою нового ядра не ждите.
>через 3-е недели вышло новое ядро.
>
>другими словами, я вам сочувствую. искренне.Речь про лично вас, а не про Торвальдса.
лично я вам уже посочувствовал. при чем и лично вам, и вместе с Марком.
что вам еще нужно?
зы:
и лично о себе речи в новости я не видел. вы что-то путаете.
>лично я вам уже посочувствовал. при чем и лично вам, и вместе
>с Марком.
>что вам еще нужно?От вас — уже ничего. Раз вы читать не умеете.
>зы:
>и лично о себе речи в новости я не видел. вы что-то
>путаете.Путаете вы. Перечитайте конкретно эту беседу.
>[оверквотинг удален]
>>ваш ответ - прекрасная иллюстрация топика. мир состоит из одного линя, остальных
>>систем не существует. в результате мейкфайлы без gnu make не работают,
>>тары с линукс системы на аиксе не распаковываются, и так далее.
>>
>
>А кто должен проверить допустимость использования не-gnu утилиты для сборки данной на
>маргинальной платформе? Разработчик??? А нахрена ему это надо? Это задача майтейнера
>программы на данной платформе или конечного пользователя. И сопли майтейнера из
>OpenBSD абсолютно непонятны... Он должен выполнять взятые на себя обязательства или
>уйти со своего поста.Уйми свои сопли. Есть слово posix, да и слово разработчика - если он заявляет что это работает на платформе XXX - то будь добр все проверять, а не только GNU утилиты на этой платформе. Иначе это не разработчик, а дерьмо не умеющее отвечать за свои слова.
>[оверквотинг удален]
>>маргинальной платформе? Разработчик??? А нахрена ему это надо? Это задача майтейнера
>>программы на данной платформе или конечного пользователя. И сопли майтейнера из
>>OpenBSD абсолютно непонятны... Он должен выполнять взятые на себя обязательства или
>>уйти со своего поста.
>
>Уйми свои сопли. Есть слово posix, да и слово разработчика - если
>он заявляет что это работает на платформе XXX - то будь
>добр все проверять, а не только GNU утилиты на этой платформе.
>Иначе это не разработчик, а дерьмо не умеющее отвечать за свои
>слова.Нее, я понимаю что поклонникам BSD думать головой не обязательно, но при чем тут posix? Разработчик написал прогу под своей любимой операционкой и поручил контроллировать достаточность сборочной среды системе autotools. Сексуальные проблемы маргиналов его не волнуют. Программа, написанная исключительно с использование posix, не сильно превосходит по сложности и восстребованности helloworld.c и в сборочной системе на основе autotools не нуждается.
И еще, к слову о портируемости - это фетиш авторов самого autotools, а автору конкретной программы, использующей autotools для сборки на портируемость может быть насрать с высокой колокольни.
>И еще, к слову о портируемости - это фетиш авторов самого autotools,
>а автору конкретной программы, использующей autotools для сборки на портируемость может
>быть насрать с высокой колокольни.Пардон, а зачем тогда нужны autotools?
>>И еще, к слову о портируемости - это фетиш авторов самого autotools,
>>а автору конкретной программы, использующей autotools для сборки на портируемость может
>>быть насрать с высокой колокольни.
>
>Пардон, а зачем тогда нужны autotools?Я пишу исключительно под Linux(т.е. код в принципе не проверяется на возможность сборки и запуска под xBSD) и autotools использую только для контроля достаточности сборочной среды и настройки путей к конкретным заголовочным файлам и/или библиотекам.
>Пардон, а зачем тогда нужны autotools?Чтобы проверить что у вас есть подходящие для сборки тулы. При том никто не обещал что все существующие в мире тулы - подходящие для сборки. Более того - разработчик загнется прогибаться под все существующие в мире тулзы и их закидоны. К портабельности сие тоже имеет слабое отношение: гнутые утилсы наверное рекордсмены по числу поддерживаемых платформ и архитектур.
дело в том что это не корректная проверка, я могу скомпилировать bsd-tar который будет сообщать не правдивую версию ( якобы он является GNU ). Корректная проверка это проверка необходимой функции, то есть если приложению нужна поддержка более 100 симолов в имени файла, то автоконф должен создать файл попробовать запаковать его, затем распаковать в другое место, проверить существует ли он, а также проверить не модифицирован ли файл, вот это была бы корректная проверка.
>есть если приложению нужна поддержка более 100 симолов в имени файла, то автоконф должен создать файл попробовать запаковать его, затем распаковать в другое место, проверить существует ли он,вот тогда и придёт соурбэйзед дистрам виндакапец.
есть комментарии по теме?
а что-то не понятно?
ну представьте сколько с такими проверками (по каждой утилите) будет собираться ВСЯ система?
у убунты быстрее новая версия выйдет.
>а что-то не понятно?
>ну представьте сколько с такими проверками (по каждой утилите) будет собираться ВСЯ
>система?
>у убунты быстрее новая версия выйдет.есть тесты?
>а что-то не понятно?
>ну представьте сколько с такими проверками (по каждой утилите) будет собираться ВСЯ
>система?Во-первых, у autoconf есть кэш (сюрприз!).
>у убунты быстрее новая версия выйдет.
Во-вторых, вы в любом случае сильно переоцениваете время.
>дело в том что это не корректная проверка, я могу скомпилировать bsd-tar
>который будет сообщать не правдивую версию ( якобы он является GNU
>).ССЗБ :)
в конце концов - это же не управление термоядерным синтезом, это лично твоя проблема.
>ССЗБ :)
>
>в конце концов - это же не управление термоядерным синтезом, это лично
>твоя проблема.
>зачем вообще версию проверять? это что гарантирует хоть что-то?
>>ССЗБ :)
>>
>>в конце концов - это же не управление термоядерным синтезом, это лично
>>твоя проблема.
>>
>
>зачем вообще версию проверять? это что гарантирует хоть что-то?ДА! Версия гарантирует конкретный набор фич. Если на вашей платформе это не так - я вам сочувствую.
>>>ССЗБ :)
>>>
>>>в конце концов - это же не управление термоядерным синтезом, это лично
>>>твоя проблема.
>>>
>>
>>зачем вообще версию проверять? это что гарантирует хоть что-то?
>
>ДА! Версия гарантирует конкретный набор фич. Если на вашей платформе это не
>так - я вам сочувствую.Я вот вам и тов. минона задам один простой вопрос.
Вот собираю я, скажем, bash — возможно, для линуксоидов это будет открытием, но bash тоже стоит далеко не везде.
Для установки bash я использую конфиг-скрипт, сделанный autoconf.
Этот конфиг скрипт не работает корректно в чём-то кроме bash. Потому что поклал на SUS и использует фичи, специфические для bash.
Ну и чо делать? Как я установлю те самые ваши GNU tools? М-м? :)
>Ну и чо делать? Как я установлю те самые ваши GNU tools?
>М-м? :)Вы еще GCC с бутстрапа пособирайте. Что за идиотская привычка создавать самому себе проблемы? Во-первых, проще найти платформу, на которой можно собрать все и перенести. Если даже точно такой платформы нет - кросс-компиляцию никто не отменял.
>>Ну и чо делать? Как я установлю те самые ваши GNU tools?
>>М-м? :)
>
>Вы еще GCC с бутстрапа пособирайте. Что за идиотская привычка создавать самому
>себе проблемы? Во-первых, проще найти платформу, на которой можно собрать все
>и перенести. Если даже точно такой платформы нет - кросс-компиляцию никто
>не отменял.Кросс-компиляция, отлично! То есть мне надо поставить Linux, или что там ещё, чтобы собрать одну-единственную несчастную прогу?!
>[оверквотинг удален]
>>>не отменял.
>>
>>Кросс-компиляция, отлично! То есть мне надо поставить Linux, или что там ещё,
>>чтобы собрать одну-единственную несчастную прогу?!
>
>Вы же не жалуетесь, что для запуска одного-единственного несчастного PF вам надо
>ставить целую бздю? Так и видится "ПАЧИМУ НЕТ ПФ ПАД ЛИНУГЗ.
>БЗДИШНИКИ УРОДЫ ДАЙТЕ ПФ ПАД ЛИНУГЗ!!!". Вот примерно так и выглядит
>ваше желание получить отвязанный от GNU autoconf. С той разницей, что
>PF на Linux никому не сдался.1. Вы разницу между частью ядра и каким-нибудь калькулятором чувствуете? Если сравнивать, то тогда с тем же netfilter. А обычный BSD-шный софт под Linux'ом бегает.
2. Почему я должен вопить об отсутствии pf под Linux? Если кто-то захочет портировать и спросит моей помощи — буду рад помочь, мне не жалко, я не красноглазик. :)
>[оверквотинг удален]
>>Иначе это не разработчик, а дерьмо не умеющее отвечать за свои
>>слова.
>
>Нее, я понимаю что поклонникам BSD думать головой не обязательно, но при
>чем тут posix? Разработчик написал прогу под своей любимой операционкой и
>поручил контроллировать достаточность сборочной среды системе autotools. Сексуальные проблемы маргиналов его
>не волнуют. Программа, написанная исключительно с использование posix, не сильно превосходит
>по сложности и восстребованности helloworld.c и в сборочной системе на основе
>autotools не нуждается.
>Ошибаешся. подумай еще раз - дам подсказку - пути при инсталяции внутри makefile - задаются automake который входит в autotools.
>И еще, к слову о портируемости - это фетиш авторов самого autotools,
>а автору конкретной программы, использующей autotools для сборки на портируемость может
>быть насрать с высокой колокольни.Только почему авторы этих самых программ пишут что оно работает не только в GNU linux.
>Только почему авторы этих самых программ пишут что оно работает не только в GNU linux.так оно и работает.
устанавливаешь необходимое и работает.
>>[оверквотинг удален]
>Ошибаешся. подумай еще раз - дам подсказку - пути при инсталяции внутри
>makefile - задаются automake который входит в autotools.Ошибаешься именно ты. Autotools - это часть платформы и вендор отвечает за "подгонку" умолчаний в своей платформе. Если эта подгонка может быть выполнена как долнение, не ломающее поведение autotools на других платформах, то оформляется патч и предлагается к включению апстриму. Стенание о том, какие мерзавцы, разработчики autotools - это сопли.
>
>
>
>>И еще, к слову о портируемости - это фетиш авторов самого autotools,
>>а автору конкретной программы, использующей autotools для сборки на портируемость может
>>быть насрать с высокой колокольни.
>
>Только почему авторы этих самых программ пишут что оно работает не только
>в GNU linux.Так ставишь gnu-utils и спокойно собираешь в таком случае. Не хочешь ставить? Не используй данную программу или попроси кого-то другого ее собрать, кто не страдает алергией от буквосочетания gnu!
>[оверквотинг удален]
>>ваш ответ - прекрасная иллюстрация топика. мир состоит из одного линя, остальных
>>систем не существует. в результате мейкфайлы без gnu make не работают,
>>тары с линукс системы на аиксе не распаковываются, и так далее.
>>
>
>А кто должен проверить допустимость использования не-gnu утилиты для сборки данной на
>маргинальной платформе? Разработчик??? А нахрена ему это надо? Это задача майтейнера
>программы на данной платформе или конечного пользователя. И сопли майтейнера из
>OpenBSD абсолютно непонятны... Он должен выполнять взятые на себя обязательства или
>уйти со своего поста.Это и есть задача конфигуратора. autotools с ней НЕ справляются.
>[оверквотинг удален]
>>>тары с линукс системы на аиксе не распаковываются, и так далее.
>>>
>>
>>А кто должен проверить допустимость использования не-gnu утилиты для сборки данной на
>>маргинальной платформе? Разработчик??? А нахрена ему это надо? Это задача майтейнера
>>программы на данной платформе или конечного пользователя. И сопли майтейнера из
>>OpenBSD абсолютно непонятны... Он должен выполнять взятые на себя обязательства или
>>уйти со своего поста.
>
>Это и есть задача конфигуратора. autotools с ней НЕ справляются.В каком месте не справляется? Они говорят что после установки gnu-utils сборка на OpenBSD пройдет успешно, если сам код написан портируемо. Майтейнер OpenBSD утверждает, что это слишком жесткие требования и неопределенному (по его мнению большинству) программ для сборки хватит bsd-utils. Кто должен проверить все проекты с autotools на предмет их собираемости на OpenBSD с использованием bsd-utils? Что делать авторам программ, которые не собираются на OpenBSD с использованием bsd-utils?
автоконф должен проверять необходимый функционал существующей утилиты, а не наличие конкретной утилиты от конкретного разработчика
>автоконф должен проверять необходимый функционал существующей утилиты, а не наличие конкретной утилиты
>от конкретного разработчикаКакой функционал утилиты tar вы считаете достаточным? А утилиты make?
Autotools позволяет разработчику не медитировать над тем, что он может, а чего не может он сделать родным tar в Solaris, а отдать это на откуп соотвествующим макросам. Если разработчики xBSD системы уверены, что их tar ничем не хуже gnutar и готовы написать соотвествующий код на m4 - я думаю его с радостью включат в апстрим и будут применять... До первого сбоя при сборке, после чего выльют ведро помоев на авторов горе-патча и будут абсолютно правы.
сходите по ссылке наконец
+500
>Какой функционал утилиты tar вы считаете достаточным? А утилиты make?
>
>Autotools позволяет разработчику не медитировать над тем, что он может, а чего
>не может он сделать родным tar в Solaris, а отдать это
>на откуп соотвествующим макросам. Если разработчики xBSD системы уверены, что их
>tar ничем не хуже gnutar и готовы написать соотвествующий код на
>m4 - я думаю его с радостью включат в апстрим и
>будут применять... До первого сбоя при сборке, после чего выльют ведро
>помоев на авторов горе-патча и будут абсолютно правы.Вы, похоже, об autotools имеете слишком смутное представление. Они именно что проверяют наличие набора конкретных фич и функций, нужных программе, а не наличие/отсутствие какой-то либы или софтины целиком.
>[оверквотинг удален]
>>не может он сделать родным tar в Solaris, а отдать это
>>на откуп соотвествующим макросам. Если разработчики xBSD системы уверены, что их
>>tar ничем не хуже gnutar и готовы написать соотвествующий код на
>>m4 - я думаю его с радостью включат в апстрим и
>>будут применять... До первого сбоя при сборке, после чего выльют ведро
>>помоев на авторов горе-патча и будут абсолютно правы.
>
>Вы, похоже, об autotools имеете слишком смутное представление. Они именно что проверяют
>наличие набора конкретных фич и функций, нужных программе, а не наличие/отсутствие
>какой-то либы или софтины целиком.Хватит кормить нас своими фантазиями, прочитайте же наконец что может проверять стандартными тестами autotools!!!
>[оверквотинг удален]
>
>Какой функционал утилиты tar вы считаете достаточным? А утилиты make?
>
>Autotools позволяет разработчику не медитировать над тем, что он может, а чего
>не может он сделать родным tar в Solaris, а отдать это
>на откуп соотвествующим макросам. Если разработчики xBSD системы уверены, что их
>tar ничем не хуже gnutar и готовы написать соотвествующий код на
>m4 - я думаю его с радостью включат в апстрим и
>будут применять... До первого сбоя при сборке, после чего выльют ведро
>помоев на авторов горе-патча и будут абсолютно правы.дарю hint - в RedHat tar построен на базе той же библиотеки libarchive что и в BSD.
даже больше - эта библиотека была разработана в FreeBSD team.
просто свои опции при сборке и своя внешная обветка.
Так что закладываться на gnu tar это по меньшей степени глупо.
Ты или дурак или сознательно врешь - в RHEL 5.x и 4.x GNU tar.
возможны и оба варианта.
Он спиди-гонщик, это его фирменный стиль :)
>дарю hint - в RedHat tar построен на базе той же библиотеки
>libarchive что и в BSD.
>даже больше - эта библиотека была разработана в FreeBSD team.
>просто свои опции при сборке и своя внешная обветка.
>Так что закладываться на gnu tar это по меньшей степени глупо.Проверил у себя - в системе нету. Так что gnu tar рулит :)
зы а я дальше буду делать скрипты которые используют GNU utils, всё остальное на ваш страх и риск. Т.к. вы не целевая группа.
>[оверквотинг удален]
>>
>>Это и есть задача конфигуратора. autotools с ней НЕ справляются.
>
>В каком месте не справляется? Они говорят что после установки gnu-utils сборка
>на OpenBSD пройдет успешно, если сам код написан портируемо. Майтейнер OpenBSD
>утверждает, что это слишком жесткие требования и неопределенному (по его мнению
>большинству) программ для сборки хватит bsd-utils. Кто должен проверить все проекты
>с autotools на предмет их собираемости на OpenBSD с использованием bsd-utils?
>Что делать авторам программ, которые не собираются на OpenBSD с использованием
>bsd-utils?Если б дело ограничивалось только GNU utils… Да, и вас не смущает наличие двух идентичных утилит в системе? В два раза больше уязвимостей, в четыре раза больше проблем — вы это предлагаете?
Если программа хочет, скажем, поддержку какой-то функции, а autotools не может найти нужный заголовочный файл, кто виноват, м?
>[оверквотинг удален]
>>на OpenBSD пройдет успешно, если сам код написан портируемо. Майтейнер OpenBSD
>>утверждает, что это слишком жесткие требования и неопределенному (по его мнению
>>большинству) программ для сборки хватит bsd-utils. Кто должен проверить все проекты
>>с autotools на предмет их собираемости на OpenBSD с использованием bsd-utils?
>>Что делать авторам программ, которые не собираются на OpenBSD с использованием
>>bsd-utils?
>
>Если б дело ограничивалось только GNU utils… Да, и вас не смущает
>наличие двух идентичных утилит в системе? В два раза больше уязвимостей,
>в четыре раза больше проблем — вы это предлагаете?А вы собираете пакеты на боевых серверах, да еще и рутом? Тогда мы идем к вам!
>
>Если программа хочет, скажем, поддержку какой-то функции, а autotools не может найти
>нужный заголовочный файл, кто виноват, м?Autotools не выдвигает требований к среде исполнения программы, которая получается в итоге сборки, а только к среде сборки, если мне не изменяет склероз, в xBSD доступен chroot(1), где можно поставить любые, даже самые экстравагантные сборочные зависомости, и получив бинарник, все это г... удалить
>[оверквотинг удален]
>>>с autotools на предмет их собираемости на OpenBSD с использованием bsd-utils?
>>>Что делать авторам программ, которые не собираются на OpenBSD с использованием
>>>bsd-utils?
>>
>>Если б дело ограничивалось только GNU utils… Да, и вас не смущает
>>наличие двух идентичных утилит в системе? В два раза больше уязвимостей,
>>в четыре раза больше проблем — вы это предлагаете?
>
>А вы собираете пакеты на боевых серверах, да еще и рутом? Тогда
>мы идем к вам!На прошлом месте работы приходилось, специфика отрасли. Впрочем, я-то уязвимостей не боюсь, слежу худо-бедно, а вот клиенты…
>>Если программа хочет, скажем, поддержку какой-то функции, а autotools не может найти
>>нужный заголовочный файл, кто виноват, м?
>
>Autotools не выдвигает требований к среде исполнения программы, которая получается в итоге
>сборки, а только к среде сборки, если мне не изменяет склероз,
>в xBSD доступен chroot(1), где можно поставить любые, даже самые экстравагантные
>сборочные зависомости, и получив бинарник, все это г... удалитьМожно. Осталось только всё это говно поставить. И убедиться, что проблем не возникло. Хорошо, если у вас восемь ядер и четыре гигабайта — а если это MIPS?
Опять же, ладно зависимости — в портах они легко указываются и далее всё (теоретически) автоматом ставится… а вот хрен. То configure не может что-то найти (потому что ищет только в /usr/lib , например). То всплывает какой-то ключик компилятора, доступный только в новейшей версии. То ещё подобная хрень. Хуже того: нередко появляются зависимости, которые в configure не видны, и выясняются, в лучшем случае, только при (к счастью, в OpenBSD такое есть) автоматизированной проверке на тему используемых библиотек.
Я не раз сталкивался, например, с тем, что configure говорит: «парень, а у тебя компилятор-то не умеет создавать разделяемые библиотеки!». И ковыряешься, ищешь ошибку, и в итоге выясняется, что тест цепляет какой-то левый заголовок и вполне резонно обламывается.
>[оверквотинг удален]
>что-то найти (потому что ищет только в /usr/lib , например). То
>всплывает какой-то ключик компилятора, доступный только в новейшей версии. То ещё
>подобная хрень. Хуже того: нередко появляются зависимости, которые в configure не
>видны, и выясняются, в лучшем случае, только при (к счастью, в
>OpenBSD такое есть) автоматизированной проверке на тему используемых библиотек.
>
>Я не раз сталкивался, например, с тем, что configure говорит: «парень, а
>у тебя компилятор-то не умеет создавать разделяемые библиотеки!». И ковыряешься, ищешь
>ошибку, и в итоге выясняется, что тест цепляет какой-то левый заголовок
>и вполне резонно обламывается.Вот для того, чтобы такие ситуации не возникали и рекомендуется использовать именно стандартные макросы autotools для стандартных проверок, а не строить свои велосипеды. А задача пользователей xBSD и других не-GNU систем проверять адекватность этих стандартных тестов и закидывать какашками разрабочиков, которые самостоятельно пытаются проверить наличие библиотек и делают это только специфично для известной им системы, хотя зачем-то прицепили autotools и назвали свое поделие портируемым.
Если я захочу собрать дистрибутив линукс с библиотеками в /Linux/system32, то для нормальных проектов с autotools мне будет достаточно изменить стандартные тесты, а перед сборкой вызвать autoreconf -fisv. Для програм, использующих SCons, CMake и прочий, типа портируемый, булшит, придется править каждую из них своим, уникальным способом.
>Для програм, использующих SCons, CMake и
>прочий, типа портируемый, булшит, придется править каждую из них своим, уникальным
>способом.Это, мягко говоря, ложь. Достаточно будет только заменить пути в *.cmake совершенно аналогичным образом. Если в скриптах проекта жестко прописаны левые пути, сломается и autotools и cmake.
>>Для програм, использующих SCons, CMake и
>>прочий, типа портируемый, булшит, придется править каждую из них своим, уникальным
>>способом.
>
>Это, мягко говоря, ложь. Достаточно будет только заменить пути в *.cmake совершенно
>аналогичным образом. Если в скриптах проекта жестко прописаны левые пути, сломается
>и autotools и cmake.Чукча не читатель, чукча писатель?
Повторяю медленно и по буквам, для особо продвинутых:
1. Если проект на autotools сделан чисто, для его пересборки в новых условиях достаточно выполнить autoreconf -fisv.
2. Каждый честный проект на CMake нужно будет править РУКАМИ.PS: ничего против cmake не имею, иногда использую, но родовых травм у него не меньше, чем в autotools.
> 1. Если проект на autotools сделан чисто, для его пересборки в новых условиях достаточно выполнить autoreconf -fisv.и долго материться если версия чего-то входящего в autotools изменилась напомнить что то что написано под autoconf 1.7 не соберется с autoconf 1.8, а 1.10 вобще выдает чудеса ?
у cmake с таким хоть проблем нету :-)
>Можно. Осталось только всё это говно поставить. И убедиться, что проблем не
>возникло. Хорошо, если у вас восемь ядер и четыре гигабайта —
>а если это MIPS?мм. а что, нет руутстрапа? я вроде как собирал на x86 под arm, про mips правда не знаю, не пробовал
а как вы думаете много ли места на устройствах с МИПСом?
>а как вы думаете много ли места на устройствах с МИПСом?А перекрестную сборку уже отменили? autoconf c ней, кстати, отлично справляется. Ну а BSD на MIPS можно закапывать, все равно драйверов нет.
> Ну а BSD на MIPS можно закапывать, все равно драйверов нет.Каких драйверов?
Ну знаете, БСДя уже может работать на dir-320. Сопли подберут и будет все ок.
>> Ну а BSD на MIPS можно закапывать, все равно драйверов нет.
>
>Каких драйверов?
>Ну знаете, БСДя уже может работать на dir-320. Сопли подберут и будет
>все ок.как она работает? точнее что уже работает стабильно?
...ибудет... вот когда будет приходите.
>а как вы думаете много ли места на устройствах с МИПСом?ну так поставьте тулчейн, рутстрап на x86 и соберите всё там
Правильно сказал Марк, autoconf должен помогать портированию ПО, а на самом деле autoconf превратился в менеджер зависимостей для GNU.
Кстати вспомнился забавный баг autoconf в GNU окружении на win32 - он не верно понимал концы строк :)
бедные опеньбсдэшники опять жалуются на то, что им почему-то все должны, а сами оне не местные, кто-бы подал...
это GNU build system -- кому не нравится подход всегда могут написать свои истенно верные core-tools,autoconf,automake и остальных бледджеков с поитессами.
>бедные опеньбсдэшники опять жалуются на то, что им почему-то все должны, а
>сами оне не местные, кто-бы подал...
>
>
>это GNU build system -- кому не нравится подход всегда могут написать
>свои истенно верные core-tools,autoconf,automake и остальных бледджеков с поитессами.Дык есть альтернативы. Это вопрос НЕ к опёнковцам, а к тем, кто этими autotools пользуется, чисто по инерции. Как многие люди виндой, например, пользуются.
>>бедные опеньбсдэшники опять жалуются на то, что им почему-то все должны, а
>>сами оне не местные, кто-бы подал...
>>
>>
>>это GNU build system -- кому не нравится подход всегда могут написать
>>свои истенно верные core-tools,autoconf,automake и остальных бледджеков с поитессами.
>
>Дык есть альтернативы. Это вопрос НЕ к опёнковцам, а к тем, кто
>этими autotools пользуется, чисто по инерции. Как многие люди виндой, например,
>пользуются.дело за малым -- напишите мануал на десятке языков о том как удобно и красиво использовать ВАШ любимый инструмент.
почему Debian/kFreeBSD делают и не плачут? -- потому что не стали делать вид что умнее всех и прикрутили базу на ядро FreeBSD а не стали портировать всё и вся под своё видение -- но опёнковцы.... им же нужно и на уйх сеть и рыбку съесть.
>[оверквотинг удален]
>>>
>>>это GNU build system -- кому не нравится подход всегда могут написать
>>>свои истенно верные core-tools,autoconf,automake и остальных бледджеков с поитессами.
>>
>>Дык есть альтернативы. Это вопрос НЕ к опёнковцам, а к тем, кто
>>этими autotools пользуется, чисто по инерции. Как многие люди виндой, например,
>>пользуются.
>
>дело за малым -- напишите мануал на десятке языков о том как
>удобно и красиво использовать ВАШ любимый инструмент.http://www.openbsd.org/porting.html , далее везде. Переводы имеются.
>почему Debian/kFreeBSD делают и не плачут? -- потому что не стали делать
>вид что умнее всех и прикрутили базу на ядро FreeBSD а
>не стали портировать всё и вся под своё видение -- но
>опёнковцы.... им же нужно и на уйх сеть и рыбку съесть.Ну захотели и делают, рад за них. Причём тут autocrap?
>Дык есть альтернативы. Это вопрос НЕ к опёнковцам, а к тем, кто
>этими autotools пользуется, чисто по инерции. Как многие люди виндой, например,
>пользуются.Чем хотят тем и пользуются, какое бдунам дело? Я написал програму хочу аutotuls юзаю хочу нет
>>Дык есть альтернативы. Это вопрос НЕ к опёнковцам, а к тем, кто
>>этими autotools пользуется, чисто по инерции. Как многие люди виндой, например,
>>пользуются.
>
>Чем хотят тем и пользуются, какое бдунам дело? Я написал програму хочу
>аutotuls юзаю хочу нетНу, если вас не волнует, будет ли программа популярной, то вы вольны поступать как хотите… Правда, с таким отношением к ней она вряд ли станет популярной. Ну да это никого не волнует. :)
Да autotools вообще одна большая проблема. Заменить на cmake и забыть как страшный сон. CMake под BSD, между прочим.
Ваша cmake умеет брать _неработающий ./configure и делать "хорошо"? Нет?? Как, разве Вы не об этом говорите!?......................................
>Ваша cmake умеет брать _неработающий ./configure и делать "хорошо"? Нет?? Как, разве
>Вы не об этом говорите!?......................................Бгыгы. Неработающий configure - это ключевая фраза.
>Бгыгы. Неработающий configure - это ключевая фраза.См.выше, в #121
/usr/ports/misc/mc/patches/patch-configure-
/usr/ports/misc/mc/patches/patch-configure:- test -z "$ac_cv_path_ZIP" && ac_cv_path_ZIP="/usr/bin/zip"
/usr/ports/misc/mc/patches/patch-configure-+ ac_cv_path_ZIP="${LOCALBASE}/bin/zip"
/usr/ports/misc/mc/patches/patch-configure- ;;Я правильно понял, что Вы предлагаете дяденьке Марку из этой новости порешать его и подобные вот этим---^^^ проблемы, "просто добавив" cmake?
Вот я и говорю -- кругом ОНИ.
>Да. Кругом они:
>>только переходом на CMake, и говорить тут не о чем.
>Ваша cmake умеет брать _неработающий ./configure и делать "хорошо"? Нет?? Как, разве
>Вы не об этом говорите!?......................................у него понятия .configure нету ;-) у него есть свой язык - который выполняется в момент вызова cmake :)
не зачет по предмету.
>;-) у него есть свой язык -
>который выполняется в момент вызова cmake :)
>не зачет по предмету.Таки у автаконфа "есть свой язык", тока проекты таскают с собой "компилированный" в #!/bin/sh "бинарник" ./configure.
Но Вы все эти, которые "cmake решаить!", не _поняли же! Г-н Марк в новости писал (чтение новости и по ссылке _вслух. образец! никаких гарантий! следующие дозы - платно++), что замахался я со _своими портами - какой апстрим пакет ни возьму, кругом кривые проверки не на функциональность, а на версии гнутых тулзоф, аааа-блин! "пусть кто-нибудь ещё!"(с)Симпон Г. скажет этим сволочам в апстримах, что на авфтаконфе _надо писать правильно (=надо - Марку, писать - дяденькам), а то на самостийно-позиксвейных порто-зборщиках оно __само__ не собирается примерно в "40-50% случаев и больше"(тама выше из ваших - _считал).
То есть в нашей самостийной самоструганой скриптосборной Системе всё _Крутааа, жаль тока клятые москали постоянно же ж подкладывают какие-то _кривые исходники, хотят _задушить Маладую Димакратию гнутыми афтатулзами и ценами на газ. Самое время начинать "дружить" с заморско-артеллирийским рассадником Ценностей... Вот тут рядом шустрый такой с бегающими глазками вэстудиями приторговывает -- начинайте ею собирать Парты?! Никакого афтацымейка не надо -- __ВСЁОО__ в комплекте.
:/
И да, Вы^Wмы не поняли №№1: дядя Марк написал махонькими пукафками - "joke", а вы все тут кинулись коромыслами махать - "жпэль переписать", "симейк решаить!", "гну хоронить-закопать"... Марк : опеннет -- Тонко! : YHBT___
Блин, opennet наводнен фанатиками-даунами. Одни про лицензии пищать начали, другие предлагают переписать autotools. Да нельзя его переписать, этот мусор уже зашит во все проекты, которые им собираются. Мне тут некоторые это еще и за плюс выдавали - мол, как замечательно - метр мусора на шелле в каждом пакете, зато не нужны зависимости. Они может быть и переписали бы autotools, будь он снаружи. Но он же внутри, и ничего с этим не сделаешь. Поэтому проблема решается только переходом на CMake, и говорить тут не о чем.
>Блин, opennet наводнен фанатиками-даунами.Да. Кругом они:
>только переходом на CMake, и говорить тут не о чем.
Вам таки есть что сказать по делу? С удовольствием послушал бы ваше мнение на тему сильных с слабых сторон autotools и cmake. Особенно учитывая общий уровень ваших высказываний.
автотулс УГ, с удовольствием посмотрю на ваши потуги опровергнуть это.
Вы это мне? Я вобщем-то именно это и сказал.
>автотулс УГ, с удовольствием посмотрю на ваши потуги опровергнуть это.Автотулс УГ, просто с остальными грабель еще больше. В частности - извините, а CMake это отдельная сущность которая должна быть в системе а не скриптик. Спасибо если ее под систему портировали. Иначе вы попадете на трах с этим мероприятием до кучи.
В итоге портабельность за которую так борятся бздуны оказывается в еще большей заднице. Такое ощущение что бздуны ратуют за "портабельность" аж на целый i386 и BSD. Вот и вся "портабельность" так сказать.
> Автотулс УГ, просто с остальными грабель еще больше.Это неправда. С CMake меньше, статистику по количеству патчей для сборочных скриптов для портов, использующих autotools, cmake и scons я уже приводил. Под нелюбимую вами BSD cmake - единственное, что способно собрать софт из коробки. configure минимум требует указания CPPFLAGS="-I${LOCALBASE}/include" LDFLAGS="-L${LOCALBASE}/lib" в 100% случаев. Обычно еще кучи патчей. Со SCons больше, но его использовать никто и не советует, и, надеюсь, не будет.
> В частности - извините, а CMake это отдельная сущность которая должна быть в системе а не скриптик.
И слава тебе господи, потому что портировать один раз CMake гораздо проще, чем портировать каждый "скриптик". То, что ты предлагаешь, пованивает подходом проприетарщиков - "таскай с собой все нужное, собирай статически, не важно сколько в итоге в системе окажится копий тухлых и дырявых версий одной библиотеки".
> В итоге портабельность за которую так борятся бздуны оказывается в еще большей заднице. Такое ощущение что бздуны ратуют за "портабельность" аж на целый i386 и BSD. Вот и вся "портабельность" так сказать.
Ну да, и невежество свое сдобрил щедрой щепоткой слюнявого фанатизма. Привет.
Все проблемы решаются переходом на qmake ^_^
>Все проблемы решаются переходом на qmake ^_^QT-specific и убожество.
Аналоги утилит GNU могут в чём-то отличаться, и если при конфигурировании вместо утилиты из проекта GNU будет использовано что-то другое, то не исключена ситуация, что проект не соберётся. И даже если утилиты из *BSD поддерживают весь нужный функционал, в этом ещё нужно убедиться, то есть потратить время на тестирование. То есть фактически разработчикам из проекта GNU предлагается потратить дополнительное время, и создать потенциальные проблемы разработчикам, использующим утилиты GNU (их проекты могут собраться на меньшем числе систем), и ради чего - чтобы легче было выпиливать утилиты GNU :-) В общем, разработчик OpenBSD фактически недоволен тем, что проект GNU не помогает ему бороться с проектом GNU :-)
BSDуны берут и пишут аналог autoconf/automake. Или парсер результата работы оного в свою расово верную систему. Если им так хочется.Предположим я пишу софт. Пишу изначально под Linux. Мне autoconf удобен, я знаю, что он у меня будет работать в GNU/Linux и прочих совместимых, и в MS Windows под GNU-окружением (Cygwin, MinGW) - благо сделаны твики. Портабельности на другие платформы я не заявляю, и все борцуны за расовую верность своих микро-платформ идут лесом или делают патчи, если им так хочется.
>BSDуны берут и пишут аналог autoconf/automake.Аналоги есть.
>Или парсер результата работы оного
Есть откорректированные autoconf/automake, которые по возможности используются. Без них количество патчей к configure возросло бы на порядок.
>Предположим я пишу софт. Пишу изначально под Linux. Мне autoconf удобен, я
>знаю, что он у меня будет работать в GNU/Linux и прочих
>совместимых, и в MS Windows под GNU-окружением (Cygwin, MinGW) - благо
>сделаны твики. Портабельности на другие платформы я не заявляю, и все
>борцуны за расовую верность своих микро-платформ идут лесом или делают патчи,
>если им так хочется.Если не заявляете, то пожалуйста. Обычно ситуация другая: разработчики пишут, мол, работает под *nix.
А вообще позиция «я пишу под Linux, на остальных мне покласть» не только сама по себе как-то не слишком open-source friendly, но и вообще попахивает зажранностью, как у пропиетарщиков-монопольщиков:
«Хотите офисный пакет, хорошо читающий самые распространённые форматы офисных документов? — Ставьте MS Windows и MS Office»
«Хотите смотреть видео онлайн? — Ставьте Adobe Flash»
«Хотите, чтобы игры работали? — Ставьте вот эти, ничем не проверяемые и отваливающиеся при каждом втором обновлении системы драйвера»И так далее. Линуксоиды громче всех кричали: «Мы не микроплатформа, а если и так, всё равно поддерживайте нас!». А теперь, когда набрали какой-то вес, начали сами кичиться: «Мы крутые, а вам всем место на помойке, микроплатформы!». Не стыдно?
Я пишу не под Linux, я пишу под GNU-окружение, благо оно есть даже под виндец. А на остальных, кто на инфраструктуру GNU по каким-то религиозным соображениям поклал, мне аналогично покласть. По крайней мере до тех пор, пока они мне за поддержку их инфраструктур не начнут платить.
И - хотите самый-то прикол - open-source friendly не подразумевает какой-либо портируемости. Тем более, под нежизнеспособные ветки.
>Если не заявляете, то пожалуйста. Обычно ситуация другая: разработчики пишут, мол, работает
>под *nix.Обычно пишут - тестировалось на RHEL5/.... , возможно будет работать на других unix-like системах. Где OpenBSD вообще-то 100-я в очереди, после System-V
>А вообще позиция «я пишу под Linux, на остальных мне покласть» не
>только сама по себе как-то не слишком open-source friendly, но иЭто предрассудки. Фактически, Linux это то чем мог стать Unix, если б у него была лицензия GPL.
А тут речь вообще идет о GNU utils & gcc, и autoconf есть часть этой системы. И работает эта система везде, но только вместе.
>BSDуны берут и пишут аналог autoconf/automake. Или парсер результата работы оного в
>свою расово верную систему. Если им так хочется.
>
>Предположим я пишу софт. Пишу изначально под Linux. Мне autoconf удобен, я
>знаю, что он у меня будет работать в GNU/Linux и прочих
>совместимых, и в MS Windows под GNU-окружением (Cygwin, MinGW) - благо
>сделаны твики. Портабельности на другие платформы я не заявляю, и все
>борцуны за расовую верность своих микро-платформ идут лесом или делают патчи,
>если им так хочется.Видишь ли какое дело, GNU/Linux позиционируется производителями и вендорами как "почти" Unix.
Слово "почти" для хомяков чаще означает "совсем", а не "неполноценный". Да-да, здесь ещё идеология примешивается с прямой рекламой некогда легендарного Unix. Но когда хомячки узнают, что GNU/Linux это совсем не Unix (GNU is Not Unix после обмана), то им становится обидно и они начинают истерику в стиле: какая Sun проклятая, что не дала им ZFS под GPL.
А причем тут вообще сферические кони в вакууме, можно уточнить?
Ну как, понятно же -- товарищу танцору постом выше ZFS _жмёт и мешает, терпежу нет. Вот он об этом и пишит к месту и не к месту-----
> Видишь ли какое дело, GNU/Linux позиционируется производителями и вендорами как "почти" Unix.Может это было когда-то раньше, но теперь многие о UNIX узнают как о части истории Linux. Посмотри, сколько страниц находят поисковики на запросы UNIX и Linux (в Google и Яндексе страниц по слову "Linux" нашлось раза в три больше, чем по слову "UNIX"). Однажды я даже услышал, как про FreeBSD сказали, что это "Линукс с другим ядром"... Это конечно неверно, но показывает, в каком порядке человек узнавал про Linux и другие UNIX-подобные системы.
ты лучше скажи что у тебя на "настоящем" юниксе выдает
$ getconf _POSIX_VERSION
у?зы:
zfs можете не открывать. не нужна.
>ты лучше скажи что у тебя на "настоящем" юниксе выдает
>$ getconf _POSIX_VERSION
>у?"200112" на FreeBSD 8.0-STABLE.
сравни с убунтой:
$ getconf _POSIX_VERSION
200809
$ getconf POSIX2_C_DEV
200809
Для всех защитников автокнфа приведу другой пример, хотя он слегка преувеличен но вполне отражает суть поднятого вопроса, итак:
допустим у вас установлен веб-сервер nginx, который отдаёт статиские страницы, но в определённый момент вы захотели использовать php, как вы отреагируете если при установке php конфигуратор потребует установить apache?
поставлю linuxps:
дурацкий вопрос - дурацкий ответ.
когда пыхпых станет требовать апач (и зачем будет требовать), тогда и поговорим.
допустим дело происходит на linux.PS я сталкивался с таким веб приложением на php которе требует апач, автору выговор сделан и баг пофикшен.
человеческий фактор как говорится на лицо.
ну и при чем тут аутоконф?
тот же самый человеческий фактор, вместо того чтобы написать проверку необходимой фичи, они пишут проверку версии (что собственно только косвенно подтверждает наличие фичи)
>тот же самый человеческий фактор, вместо того чтобы написать проверку необходимой фичи,
>они пишут проверку версии (что собственно только косвенно подтверждает наличие фичи)
>Я почти уверен, что в бздях (поскольку порты собираются черт-те-кем и черт-те-как, по велению левой задней ноги) версия только косвенно подтверждает наличие фичи. Но в GNU, где в основном весь софт поддерживается "родными" майнтейнерами - версия означает наличие конкретных фич, заявленных в данной версии. Отсюда и проверка.
то есть я используя линукс, не имею права снести к чёртовой матери гнутый тар, и установить вместо него бсдшный? даже если по функционалу он не уступает гнутому.
>то есть я используя линукс, не имею права снести к чёртовой матери
>гнутый тар, и установить вместо него бсдшный? даже если по функционалу
>он не уступает гнутому.Имеешь. Но работоспособность системных утилит после - сугубо на твоей совести.
почему автоконф не проверяет функционал, а проверяет версию?
>Я почти уверен, что в бздях (поскольку порты собираются черт-те-кем и черт-те-как,
>по велению левой задней ноги) версия только косвенно подтверждает наличие фичи.По влению левой ноги софт собирается только под Linux. В FreeBSD дерево портов согласованно в каждый момент времении и из него можно собрать рабочее окружение хоть для десктопа, хоть для сервера.
>Но в GNU, где в основном весь софт поддерживается "родными" майнтейнерами
Ты заблуждаешься насчёт роли мантейнеров. Их дело не разработка софта, а портирование и адаптация чужого софта — вещи принципиально разные.
> At some point in the past, autoconf was *meant* to simplify porting programs.
> These days, it's more a "use gnu-linux, or die" (no wonder bsd is dying).Этот параграф просто восхитителен, классический Amiga Persecution Complex (http://catb.org/jargon/html/A/Amiga-Persecution-Complex.html) в действии.
> This is utter complacency from the part of the guys who write these tests.
> They can ask *us* if they want to support other OSes, instead of silently
> going over to GNU-make/GNU-bash/GNU-tar/GNU-m4/GNU-mkdir...Похоже он действительно считает что полтора пользователя OpenBSD являются центром мироздания и все им что-то должны.
> I have a simple request for you: each time you run into software that does
> this idiotic kind of test, please interact with the idiots upstream for
> whom all the world is linux, and try to get them to replace their "joke"
> of an autoconf macro with actual genuine tests that actually CHECK FOR THE
> FUCKING FEATURE.Тоже хорошо. "Я за вас свою работу делать не буду !"
И ведь казалось бы любому кто в курсе как разрабатывается свободное ПО должно быть известно, что есть только один продуктивный метод общения with the idiots upstream и называется он отправка патчей.
В общем, если коротко, всё скатилось к разработке не переносимых с платформы GNU/Linux программ, в лучших традициях закрытых систем. Помню как всё радужно выглядело году 93ем, жаль что так всё закончилось... Коммерциализация за прошедшие столетия привела к упадку движений борющихся за модернизацию существующего миропорядка, что в очередной раз и происходит.
>В общем, если коротко, всё скатилось к разработке не переносимых с платформы GNU/Linux программ, в лучших традициях закрытых систем.вы в своем уме?
программы собираются и работают.
просто некоторым не нравится чем они собираются.
>>В общем, если коротко, всё скатилось к разработке не переносимых с платформы GNU/Linux программ, в лучших традициях закрытых систем.
>
>вы в своем уме?
>программы собираются и работают.
>просто некоторым не нравится чем они собираются.Он в своем. Когда линуксоиды были совсем маргиналами, то поддерживали стандарты и портируемость. Теперь считают, что их должны поддерживать. А документацию не переписали. Линуксоидам, как пользующимися двойными стандартами - пофигу. Все остальные немного в шоке от такого инфантильного поведения. БСДшников поражает, что линуксоиды в свою очередь на майкрософт срали кирпичами по тем же причинам. Теперь ведут себя также. Впрочем, это опять двойной стандарт, почти как американская демократия. Сказанного достаточно.
да хватит уже языком трепать. говорите конкретно, о каких стандартах идет речь.
и какие проблемы с портируемостью - у вас posix софт не собирается? или работает не правильно?
или вы хотите, чтобы ребята из проекта гну написали вам софт под лицензией бзд? :Dзы:
из линуксов даже не любимая убунта поддерживает самую последнюю версию posix.
и гнушные утилиты соответственно тоже.
кто же виноват, что все остальные отстают от стандарта? неужели гнушные утилиты?
>[оверквотинг удален]
>и какие проблемы с портируемостью - у вас posix софт не собирается?
>или работает не правильно?
>или вы хотите, чтобы ребята из проекта гну написали вам софт под
>лицензией бзд? :D
>
>зы:
>из линуксов даже не любимая убунта поддерживает самую последнюю версию posix.
>и гнушные утилиты соответственно тоже.
>кто же виноват, что все остальные отстают от стандарта? неужели гнушные утилиты?
>Идиот! (в третий раз).
Ни ubuntu, ни любой другой дистрибутив Linux POSIX не поддерживают, и в ближайшие 10-20 лет не смогут с таким подходом к разработке.
Вы видели код большинства Linux-oriented софта? Наверняка видели, раз понаписали тут кучу простыней о портируемости приложений. Так вот, вам известно, что такое грязный код? И почему FreeBSD превратился (с одной стороны, а с другой -- стал говном в архитектурном плане) в Linux под BSDL, гонясь за "поддержкой" приложений и популярностью и став мусором практически во всех подсистемах (иначе, omg, как бы смог Ardour, н-р, работать под ним)? Смешно..
ОС с чистым, вылизанным кодом и _корректными_ проверками функционала перед компилёжкой софта -- единицы, и OpenBSD -- в их числе.
Когда меня спрашивают, чем Linux идеологически плох, я выдаю 2 линка, и после этого все вопросы пропадают. Линки следующие:
http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/lib/lib...
http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/string/str...
Да, действительно, все вопросы отпадают. Как к BSD'шникам, так и к Вам, как к программистам.В Linux GLIBC на самом деле реализован очень красивый алгоритм, который требует в 4-8 раз меньше операций, чем его "аналог" в BSD, да еще и учитывает требования выравнивания на современных процессорах.
А тех, кто в библиотеке, просто обязанной быть быстрой - влияющей на производительность ВСЕХ приложений, реализует алгоритмы "в лоб", лишь бы работало - закопать.
>Да, действительно, все вопросы отпадают. Как к BSD'шникам, так и к Вам,
>как к программистам.
>
>В Linux GLIBC на самом деле реализован очень красивый алгоритм, который требует
>в 4-8 раз меньше операций, чем его "аналог" в BSD, да
>еще и учитывает требования выравнивания на современных процессорах.Вот только не нужно все BSD под "одну гребёнку" карнать. То ли в силу молодого возраста, то ли ещё по каким-либо причинам, но ты ещё не видел ВЕСЬ код под BSDL.
>>Да, действительно, все вопросы отпадают. Как к BSD'шникам, так и к Вам,
>>как к программистам.
>>
>>В Linux GLIBC на самом деле реализован очень красивый алгоритм, который требует
>>в 4-8 раз меньше операций, чем его "аналог" в BSD, да
>>еще и учитывает требования выравнивания на современных процессорах.
>
>Вот только не нужно все BSD под "одну гребёнку" карнать. То ли
>в силу молодого возраста, то ли ещё по каким-либо причинам, но
>ты ещё не видел ВЕСЬ код под BSDL.Ну... strlen достаточно, если учесть, что в GLIBC оптимизация сделана еще в 2005.
Как-то не тянет к ретроградным системам и их коду, извини.
>Как-то не тянет к ретроградным системам и их коду, извини.Строго говоря использование strlen само по себе ретроградство. нормальные люди всегда знают длину строки когда это действительно необходимо.
Кстати да, вот оно и видно, как раз на Вашем примере - реальное ИДЕОЛОГИЧЕСКОЕ преимущество Linux-кода.Признайтесь честно - Вы просто не осилили код, и решили его представить в неблаговидном свете - в расчете, что аудитория не поймет?
>Кстати да, вот оно и видно, как раз на Вашем примере -
>реальное ИДЕОЛОГИЧЕСКОЕ преимущество Linux-кода.
>
>Признайтесь честно - Вы просто не осилили код, и решили его представить
>в неблаговидном свете - в расчете, что аудитория не поймет?Сколько много комментариев (пока целых 3: этот, один выше и один ниже), и все не по делу..
То, что вы называете оптимизацией в примере -- костыль. Таким образом закапываются и забываются баги из-за каких-то изменений в функциях, необходимых для этой. А потом через несколько лет умные люди находят баги в ядре, да такие страшные.. :-( Не там, увы, они эти оптимизации проводили, ох, не там.. это как раз тот случай, когда нечто временное стало постоянным.
Запомните пару фраз: всё гениальное -- просто, унификация -- мать порядка. На первые пару лет вам хватит.
Прежде чем давать запоминалки, ответьте на простой вопрос: вы поедете на метро, или предпочтете добираться на работу 40-60км пешком?Метро - точно такой же костыль, призванный ускорить определенные процессы. И у него точно так же есть свои минусы. Но он в любом случае оптимальнее "унификации" для медленных двуногих созданий.
>Прежде чем давать запоминалки, ответьте на простой вопрос: вы поедете на метро,
>или предпочтете добираться на работу 40-60км пешком?
>
>Метро - точно такой же костыль, призванный ускорить определенные процессы. И у
>него точно так же есть свои минусы. Но он в любом
>случае оптимальнее "унификации" для медленных двуногих созданий.да.. бредовее сравнения я ещё не видел :-)
поди, вы уверены, что C лучче, чем Python.. :-)
>поди, вы уверены, что C лучче, чем Python.. :-)Смотря для чего. Идите, напишите на Python GLIBC, и заюзайте. А мы поржем. Ну или на VB.NET.
>Идите, напишитеЭх.. а я думал, вы поймёте мой тонкий юмор.. :-) ну да ладно..
>>Идите, напишите
>
>Эх.. а я думал, вы поймёте мой тонкий юмор.. :-) ну да
>ладно..Ваш тонкий юмор оказался слегка толстоват и жирноват.
>>> Не там, увы, они эти оптимизации проводили, ох, не там..Мда. Я бы вас в рабочую группу не включил однозначно - фанатизм перекрыл мозг.
"НЕ ТАМ"?!!!!!!!! Это процедура, которая в обычных приложениях может несколько миллионов раз вызываться. Что же у вас тогда "там"?
Пример: берем Apache, делаем поиск по strlen. Что, число вхождений уже ужасает? А теперь делаем поиск по вызовам процедур, в которые он входит...
Это именно "ТАМ", и "ТАМ, ГДЕ НАДО". А вы можете хоть на PHP системные библиотеки писать, все равно ими никто пользоваться не будет.
>>>> Не там, увы, они эти оптимизации проводили, ох, не там..
>
>Мда. Я бы вас в рабочую группу не включил однозначно - фанатизм
>перекрыл мозг.
>
>"НЕ ТАМ"?!!!!!!!!да что же вы так разнервничались :-)
и правильно! не включайте! нечего мне там делать ;-P
>да что же вы так разнервничались :-)
>
>и правильно! не включайте! нечего мне там делать ;-PПрошу прощения, у меня возник эпичный баттхерт при виде кода в BSD.
Я и раньше не любил BSD-подобные системы, но теперь меня от них будет просто тошнить. Спасибо за ссылочку, кстати.
>> Таким образом закапываются и забываются баги из-за каких-то изменений в функциях, необходимых для этой.Интересно, какие функции необходимы этой? Я не обнаружил не одной.
Толстоваты батенька, идите читать учебники по системному программированию. Когда прикладники, с трудом освоившие C#, лезут в системный код - добра не жди.
>>> Таким образом закапываются и забываются баги из-за каких-то изменений в функциях, необходимых для этой.
>
>Интересно, какие функции необходимы этой? Я не обнаружил не одной.а кто говорил о конкретно _этой_? :-)
>>>> Таким образом закапываются и забываются баги из-за каких-то изменений в функциях, необходимых для этой.
>>
>>Интересно, какие функции необходимы этой? Я не обнаружил не одной.
>
>а кто говорил о конкретно _этой_? :-)У вас склероз? Или не вы ссылки давали?
Кстати да, лучше ткнуться сюда:http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/string/str...
В предыдущей ревизии одна оптимизация была сделана с сохранением старого кода - как раз таки #if 0 - вероятно, для чисто визуального сравнения. В этой ревизии она глаз не мозолит.
>http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/lib/lib...
>
>http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/string/str...Что интересно, и очень показательно - в FreeBSD этот код слизали ровно в марте этого года, в то время, как в Linux он появился не позднее, чем в 2005 (а вероятно - ранее), судя по коммитам.
>Когда меня спрашивают, чем Linux идеологически плох, я выдаю 2 линка, и
>после этого все вопросы пропадают. Линки следующие:
>
>http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/lib/lib...
>
>http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/string/str...Ещё вот этот выдай:
http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/string/st.../*
* Portable strlen() for 32-bit and 64-bit systems.
...
>[оверквотинг удален]
>>http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/lib/lib...
>>
>>http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/string/str...
>
>Ещё вот этот выдай:
>http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/string/st...
>
>/*
> * Portable strlen() for 32-bit and 64-bit systems.
>...Буквально постом выше написано, откуда дровишки. Слизали ровно в марте этого года.
http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/string/st...
Revision 1.8: download - view: text, markup, annotated - select for diffs
Fri Mar 12 21:14:56 2010 UTC (40 hours, 14 minutes ago) by delphijЧто радует - хотя бы указали, откуда взяли - дык, вестимо, откуда:
[1] http://vger.kernel.org/~davem/cgi-bin/blog.cgi/2010/03/08#st...
спасибо! :D
я бы сам более убедительно преимущества линукса не смог в одном посте так доказать, как это сделали вы.зы:
я не надеюсь что вам поможет, но - уже традиционно последние лет 10 именно линукс в наиболее полном объеме поддерживает посикс. и сам этот стандарт - стандарт интерфейсов, а не их реализаций.
>В общем, если коротко, всё скатилось к разработке не переносимых с платформы
>GNU/Linux программ, в лучших традициях закрытых систем. Помню как всё радужно
>выглядело году 93ем, жаль что так всё закончилось... Коммерциализация за прошедшие
>столетия привела к упадку движений борющихся за модернизацию существующего миропорядка, что
>в очередной раз и происходит.Проблема только в том, что GNU есть практически везде, даже под проприетарщиной. Ну, кроме мелких религиозно-фанатичных дистров некоего подобия *nix.
>Проблема только в том, что GNU есть практически везде, даже под проприетарщиной.
>Ну, кроме мелких религиозно-фанатичных дистров некоего подобия *nix.Где "везде"? На 2% линуксов из общего числа десктопов? На солярке, маках и виндовс GNU нет — а это большая часть десктопного и серверного оборудования.
>>Проблема только в том, что GNU есть практически везде, даже под проприетарщиной.
>>Ну, кроме мелких религиозно-фанатичных дистров некоего подобия *nix.
>
>Где "везде"? На 2% линуксов из общего числа десктопов? На солярке, маках
>и виндовс GNU нет — а это большая часть десктопного и
>серверного оборудования.Все, слив засчитан. MinGW или Cygwin в гугле вбить, и читать до просветления.
>>Где "везде"? На 2% линуксов из общего числа десктопов? На солярке, маках
>>и виндовс GNU нет — а это большая часть десктопного и
>>серверного оборудования.
>
>Все, слив засчитан. MinGW или Cygwin в гугле вбить, и читать до
>просветления.Ни разу на Windows не встречал ни MinGW , ни Cygwin (Eclipse RCP распространена более, чем эти). Если только в качестве маргинальных окружений оторванных от жизни пользователей.
Так что вбивать ничего не нужно.
догадайся чем именно Eclipse CDT/RCP компилит
>догадайся чем именно Eclipse CDT/RCP компилитEclipse RCP — это конечная программная платформа, на которой строятся десктопные приложения. Собирается при помощи javac (код) и GCC 4.2.1 (нативная библиотека для SWT).
Eclipse CDT — это среда для разработки на C/C++. На Windows встречается реже, чем где бы то ни было ещё.
>>Проблема только в том, что GNU есть практически везде, даже под проприетарщиной.
>>Ну, кроме мелких религиозно-фанатичных дистров некоего подобия *nix.
>
>Где "везде"? На 2% линуксов из общего числа десктопов? На солярке, маках
>и виндовс GNU нет — а это большая часть десктопного и
>серверного оборудования.Ну изи ты и жжешь!!! И так, "виндовс" не posix, забыли - не про него речь, хотя, как правильно указали, gnu есть.
соляркa - любой админ ставит диск sunfreeware, хотя bash идет уже с базовой системой. Так что мимо.
мак Х - тут кончено чуть по другому, но bash идет как главный шел - вызывается из меню, а остальное, если ты девелопер, ставится отсюда: http://coreutils.darwinports.com/, тем более в основном софт портируют с Linux, а не с bsd.
>>>Проблема только в том, что GNU есть практически везде, даже под проприетарщиной.
>>>Ну, кроме мелких религиозно-фанатичных дистров некоего подобия *nix.
>>
>>Где "везде"? На 2% линуксов из общего числа десктопов? На солярке, маках
>>и виндовс GNU нет — а это большая часть десктопного и
>>серверного оборудования.
>
>соляркa - любой админ ставит диск sunfreeware, хотя bash идет уже с
>базовой системой. Так что мимо.Для чего? Чтобы поиграть в линукс?
>мак Х - тут кончено чуть по другому, но bash идет как
>главный шел - вызывается из меню, а остальное, если ты девелопер,
>ставится отсюда: http://coreutils.darwinports.com/, тем более в основном софт портируют с Linux,
>а не с bsd.В Mac OS X оболочка вообще не Bash, а csh — основная оболочка BSD. На Bash перешли только в Mac OS X 10.3 в 2003 году, когда GNU-окружение стало более-менее юзабельно.
>Для чего? Чтобы поиграть в линукс?для чего?
чтобы не чувствовать себя идиотом.
чтобы поставить screen, gtar, gzip, bzip2...
и да! тот самый баш. т.к. устаревший шел без истории - путешествие в 60-е
>В Mac OS X оболочка вообще не Bash, а csh — основная оболочка BSD. На Bash перешли только в Mac OS X 10.3 в 2003 году, когда GNU-окружение стало более-менее юзабельно.вот любитель манипулировать и перевирать! :D
гну окружение стало рабочим задолго до того момента, когда макось стала тоже никсами.
пример? пожалуйста - оракловые субд к "рождению" десятой макоси уже крутились в основном на линухе.
и да, баш таки на макоси есть. и по умолчанию. и почему то именно он.
>>Для чего? Чтобы поиграть в линукс?
>
>для чего?
>чтобы не чувствовать себя идиотом.
>чтобы поставить screen, gtar, gzip, bzip2...Зачем нужен screen, когда есть tmux?
Зачем нужен gtar, когда есть tar? (Учитесь наслаждаться малым)
Зачем нужен bzip2, когда есть xz?>и да! тот самый баш. т.к. устаревший шел без истории - путешествие
>в 60-еtcsh имеет историю.
>гну окружение стало рабочим задолго до того момента, когда макось стала тоже
>никсами.Mac OS X 10.2 не была Unix? Ну вы даёте. :D
>пример? пожалуйста - оракловые субд к "рождению" десятой макоси уже крутились в
>основном на линухе.А также на Windows Server, Solaris, UP-UX и AIX. И что? :D
>и да, баш таки на макоси есть. и по умолчанию. и почему то именно он.
Сама Mac OS X собирается GNU GCC. Сюрприз?
>Зачем нужен screen, когда есть tmux?Затем, что у tmux проблемы с UTF-8.
>Зачем нужен gtar, когда есть tar? (Учитесь наслаждаться малым)
Затем, что большинство - не мазохисты.
>Зачем нужен bzip2, когда есть xz?
Приличная часть XZ - под GPL/LGPL, так что мимо тазика. Насчет bz2 - согласен, формат убогий в плане производительности, если надо быстро - gzip, совместимо - zip, если плотно - xz/7z (все, что с LZMA).
>>и да! тот самый баш. т.к. устаревший шел без истории - путешествие
>>в 60-е
>tcsh имеет историю.Повторяюсь - большинство - не мазохисты. bash - очень удобен для консоли, и этим все сказано.
>>пример? пожалуйста - оракловые субд к "рождению" десятой макоси уже крутились в
>>основном на линухе.
>А также на Windows Server, Solaris, UP-UX и AIX. И что? :DА то, что под *BSD их нет. Официально не поддерживается.
>>и да, баш таки на макоси есть. и по умолчанию. и почему то именно он.
>Сама Mac OS X собирается GNU GCC. Сюрприз?Не, не сюрприз, а вполне понятная закономерность.
>>Зачем нужен screen, когда есть tmux?
>
>Затем, что у tmux проблемы с UTF-8.Давно на сайте tmux.sourceforge.net был? :D
>>Зачем нужен gtar, когда есть tar? (Учитесь наслаждаться малым)
>
>Затем, что большинство - не мазохисты.Миллионы мух тоже не могут ошибаться.
>>Зачем нужен bzip2, когда есть xz?
>
>Приличная часть XZ - под GPL/LGPL, так что мимо тазика.Версия 5.0 XZ будет в Public Domain сразу, как только выйдет. Следи за новостями.
>>tcsh имеет историю.
>
>Повторяюсь - большинство - не мазохисты. bash - очень удобен для консоли,
>и этим все сказано.Для кого удобен, тот пользуется. Для меня не удобен — я использую tcsh. Этим всё сказано.
Перестань навязывать мне свою идеологию.>>>пример? пожалуйста - оракловые субд к "рождению" десятой макоси уже крутились в
>>>основном на линухе.
>>А также на Windows Server, Solaris, UP-UX и AIX. И что? :D
>
>А то, что под *BSD их нет. Официально не поддерживается.Oracle работает только с коммерческими партнёрами. Их СУБД официально не поддерживается, например, в Debian. И что?
>>>и да, баш таки на макоси есть. и по умолчанию. и почему то именно он.
>>Сама Mac OS X собирается GNU GCC. Сюрприз?
>
>Не, не сюрприз, а вполне понятная закономерность.Закономерность обусловлена отсутствием альтернативного компилятора для унаследованного кода. Вот и всё.
Удел GCC — поддерживать сопровождение СТАРОГО кода. Ничего нового в GCC больше не появится.
Всё новое (удобные механизмы кросс-компиляции, оптимизации и т.д.) появляются и появятся только для LLVM. Необходимый вектор развития уже задан индустрией инноваций. GCC старичок, он уже не способен удовлетворить КАЧЕСТВЕННЫЕ запросы разработчиков.
>[оверквотинг удален]
>>>Сама Mac OS X собирается GNU GCC. Сюрприз?
>>
>>Не, не сюрприз, а вполне понятная закономерность.
>
>Закономерность обусловлена отсутствием альтернативного компилятора для унаследованного кода. Вот и всё.
>Удел GCC — поддерживать сопровождение СТАРОГО кода. Ничего нового в GCC больше
>не появится.
>Всё новое (удобные механизмы кросс-компиляции, оптимизации и т.д.) появляются и появятся только
>для LLVM. Необходимый вектор развития уже задан индустрией инноваций. GCC старичок,
>он уже не способен удовлетворить КАЧЕСТВЕННЫЕ запросы разработчиков.это у тебя весеннее?
>Давно на сайте tmux.sourceforge.net был? :DКогда баловался федоркой. Сейчас пофиг абсолютно - в дистре RPM с screen, необходимости в чем-то ином не вижу.
>Закономерность обусловлена отсутствием альтернативного компилятора для унаследованного кода. Вот и всё.
>Удел GCC — поддерживать сопровождение СТАРОГО кода. Ничего нового в GCC больше
>не появится.Сказал iZEN, покосившись на Java. GCC развивается непрерывно - см. gcc.gnu.org
>Всё новое (удобные механизмы кросс-компиляции, оптимизации и т.д.) появляются и появятся только для LLVM.
Может быть прекратим пороть чушь? В LLVM логично, что многое появляется - там появляется бетой то, что давно есть в GCC, и вполне вменяемо.
А вообще LLVM использует парсеры GCC, так что его удел (имхо) - быть плагином инфраструктуры GCC. В перспективе. Как самостоятельный проект он интересен лишь в академических целях.
>>соляркa - любой админ ставит диск sunfreeware, хотя bash идет уже с
>>базовой системой. Так что мимо.
>Для чего? Чтобы поиграть в линукс?Ну поиграйте, если что.
А остальные просто используют в работе :))>>мак Х - тут кончено чуть по другому, но bash идет как
>>главный шел - вызывается из меню, а остальное, если ты девелопер,
>>ставится отсюда: http://coreutils.darwinports.com/, тем более в основном софт портируют с Linux,
>>а не с bsd.
>
>В Mac OS X оболочка вообще не Bash, а csh — основная
>оболочка BSD. На Bash перешли только в Mac OS X 10.3
>в 2003 году, когда GNU-окружение стало более-менее юзабельно.Ой не надо завирать! Я первый раз OS X смотрел еще году в начале 2002 или даже 2001, короче, магазин еще на евро переходил :), первым делом разыскал консоль (похоже на konsole ) - там был bash!!! И куча костылей от ос9 :)))))))))))))) Долго смеялся.
Да здравствует OpenNet'овский спор, бессмысленный и беспощадный! Прочь логические аргументы, пережиток прошлого! Наступило новых решений!Здравый смысл? Вы о чём! Здравый смысл заключается в том, чтобы каждый забоился о себе. Именно в этом настоящий смысл сообщества open source!
Не можете возразить по существу? — Не беда! Перейдите на личности. Спросите «а где патчи?». Уведите разговор на тему Java, это всегда актуально! Если вас ткнут носом — бездоказательно что-нибудь утверждайте, пусть ваш оппонент парится, ища опровержения. Когда опровергнет — придумайте что-нибудь ещё! Рано или поздно он сдастся и вы ощутите вкус победы!
В конце концов, что может сказать BSD-шник о GNU-той утилите, если ему сразу сказать, что он — BSD-шник?
И не забудьте упомянуть, что лицензия, которой придерживаетесь вы — самая правильная. Если оппонент разделяет с вами это мнение — перейдите на конкретные ОС/дистрибутивы.
Ваш оппонент упомянул вскользь о production? Обсмеивайте ретроградом. Сказал, что любит Fedora Core или FreeBSD-CURRENT? Поиздевайтесь над вечными глюками. В итоге вы наверняка окажетесь правы, а, значит, и исходный тезис тоже, безусловно, будет доказан!
Смелее! Оттачивайте искусство спора! И рано или поздно мы сможем доказать сами себе, что мы все занимаемся важным делом!
(спасибо Михаилу Жванецкому за идею)
>(спасибо Михаилу Жванецкому за идею)Забыли в свой текст добавить: "Кончились буквы? Вспомните тексты Жванецкого!"
учавствующие в дискуссии холи^W беэсдешники путуют понятие opensource с понятием "сделайте мне заебись" -- отсюда вечное непонимание. БЕЭСДЕШНИК -- помни если ты не подписывал договор и не платил за его выполнение денег -- тебе никто ничего не должен. можете дальше настаивать что ваши оси самые.... и все должны равняться исключительно на вас, но этого не произойдёт до тех пор пока вы не станете популярны,чтобы ваши голоса учитывались. последнему судя по всему не суждено случиться, потому что вместо того чтобы работать в кооперативе (как это делает GNU -- да блин именно благодаря GNU лицензии) вы всё время стараетесь делать свои вылысыпеды, чем постоянно оттягиваете решение более насущных проблем.ИТОГ: замкнутый круг - из которого выход очевиден но так ненавистен BSD сообществом, а именно больше использовать GNU -- ведь оно ничуть не мешает ВАМ разрабатывать/продавать пропиетарные решения -- достаточно лишь вовремя открывать исходники модифицируемого GNU кода.
>учавствующие в дискуссии холи^W беэсдешники путуют понятие opensource с понятием "сделайте мне
>заебись"Где это требование озвучено в исходном тексте?
> -- отсюда вечное непонимание. БЕЭСДЕШНИК -- помни если ты не
>подписывал договор и не платил за его выполнение денег -- тебе
>никто ничего не должен. можете дальше настаивать что ваши оси самые....Где это требование озвучено в исходном тексте?
>и все должны равняться исключительно на вас, но этого не произойдёт
>до тех пор пока вы не станете популярны,чтобы ваши голоса учитывались.(возвращаемся на 10 лет назад)
"Можете и дальше настаивать, что Linux самый .... и все должны равняться исключительно на него, но этого не произойдёт, пока вы не станете популярны, чтобы ваши голоса учитывались."
Господа линуксоиды, вы ЗАЗНАЛИСЬ! Linux — хорошая вещь. Но немалая часть линуксоидов вызывает всё больше отвращения по мере того как у них появляется всё больше понтов.
Про передёргивания вроде "исключительно на вас" я вообще молчу. Классическая попытка приписать оппоненту заведомо ложное утверждение. Идите знаете куда?
>последнему судя по всему не суждено случиться, потому что вместо того
>чтобы работать в кооперативеЭто BSD-то не работает в кооперативе?! Ну здрасьте-приехали. Даже не отвлекаясь на обмен кодом между BSD-системами, вам напомнить, что именно BSD, а не что-то GNU-образное, представили публичный CVS-репозиторий?
> (как это делает GNU -- да блин именно благодаря GNU лицензии)
Которых, кстати, много. И скорее благодаря LGPL, нежели GPL.
> вы всё время стараетесь делать свои вылысыпеды,
>чем постоянно оттягиваете решение более насущных проблем.То есть когда GNU изобретает свои велосипеды — это хорошо и правильно, да?
Свои велосипеды делают по мере необходимости, когда имеющиеся аналоги окончательно перестают справляться с определёнными задачами. Либо когда лицензионные вопросы встают остро. Точно то же делают все остальные, включая GNU, это _нормальная_ практика.
>ИТОГ: замкнутый круг - из которого выход очевиден но так ненавистен BSD
>сообществом,BSD-сообщество не имеет ничего против существования GNU, пока GNU не имеет ничего против существования BSD-сообщества. Не BSD начало эти войны. Это FSF/GNU не понравилась имевшаяся ситуация.
> а именно больше использовать GNU -- ведь оно ничуть не
>мешает ВАМ разрабатывать/продавать пропиетарные решения -- достаточно лишь вовремя открывать исходники
>модифицируемого GNU кода.Я вот прямо сплю и вижу, как Тео де Раадт мечтает закрыть GCC…
… Короче, эти споры — переливание из пустого в порожнее. GNU хочет стать монополией в мире open source — это их проблемы. Раздражает, что они плодят зомби (порой из весьма неглупых людей), которые слепо помогают им в этом. Вот это уже неприятно. Больше мне добавить нечего. Я ухожу из этой дискуссии, у меня ещё libtorrent (который под BSDL, но с autoconf) не портирован… Всем удачи.
>Господа линуксоиды, вы ЗАЗНАЛИСЬ!только не нужно путать линуксоидов и упоротых линуксоидов, я линуксоид, и в этой дискуссии я принял сторону бсдшников, потому что только упоротые фанаты могут слепо доказывать свою правоту, когда их неправота очевидна.
>>Господа линуксоиды, вы ЗАЗНАЛИСЬ!
>
>только не нужно путать линуксоидов и упоротых линуксоидов, я линуксоид, и в
>этой дискуссии я принял сторону бсдшников, потому что только упоротые фанаты
>могут слепо доказывать свою правоту, когда их неправота очевидна.согласен -- только упоротые не могут осилить того что Вам никто ничего не должен -- вам надо -- вы и пилите.
честно говоря, мне не надо. просто я могу отличить хороший софт от плохого.
>честно говоря, мне не надо. просто я могу отличить хороший софт от плохого.Господин линуксоид, вы ЗАЗНАЛИСЬ!
Ну и в чём правота? Утилиты из GNU и из разного рода *BSD могут отличаться. Если проверяется наличие утилит GNU, то это не имеет значения, а если вместо утилит GNU использовать аналоги, появляется возможность получить ошибку при сборке на BSD-системе. То есть если поступить так, как хотят бсдшники, то качество работы autoconf ухудшится. И кого в этом посчитают виноватым? Те же бсдшники наверняка начнут кричать, что autoconf не кроссплатформенный и работает только в окружении GNU, и что нужно переходить на их аналоги...Кому-то важнее, чтобы скрипт configure работал на разных платформах, кому-то - чтобы легче было выпиливать утилиты GNU. Первых явно больше, чем вторых.
Суть вопроса в том что нужно проверять не версию а функционал. Всё.
>Суть вопроса в том что нужно проверять не версию а функционал. Всё.Проверка версии самая простая проверка функционала. Всё Точка. :)
>>Суть вопроса в том что нужно проверять не версию а функционал. Всё.
>
>Проверка версии самая простая проверка функционала. Всё Точка. :)ну так версию подделать можно, а функционал либо есть либо нету.
>>>Суть вопроса в том что нужно проверять не версию а функционал. Всё.
>>
>>Проверка версии самая простая проверка функционала. Всё Точка. :)
>
>ну так версию подделать можно, а функционал либо есть либо нету.Опять же - всем пофиг. Тот, кто подделывает версию - делает это на свой страх и риск.
ну что, пойдем по 101 разу?подделал версию? - значишь ТЫ ГАРАНТИРУЕШЬ совместимость прог, в противном случаи - ССЗБ.
Это надеюсь понятно?
полная проверка функционала - это 100 кратное увеличения кода, со своими глюками - кому надо? Надеюсь, тут разобрался.
Для затравки, посмотри на перловские "test" - сколько там усилий для проверки заявленного функционала, более того самими разработчиками. А пользователь иной раз и не догадывается какой функционал он задействовал - у него маке/тар работает, а в какой-то системе нет. Оказывается это gnu-фича.
Поэтому, самый простой путь - гну-утилита требует наличия полноценного гну-окружения, как самый простой способ наличия нужного функционала.
Так, в чем еще есть вопросы?
> Суть вопроса в том что нужно проверять не версию а функционал. Всё.Проверять функционал намного сложнее, чем просто проверить наличие программы и, возможно, версию.
Есть простое решение - использовать окружение GNU. Как я понимаю, его можно использовать и в системах, распространяемых под лицензией BSD, не переводя их под GPL, и в закрытых коммерческих проектах тоже (свободными должны оставаться сами программы под GPL, включая их модификации). Желание исключить окружение GNU сложно объяснить рациональными причинами, это скорее какое-то неприятие на субъективном уровне.
>Есть простое решение - использовать окружение GNU. Как я понимаю, его можно
>использовать и в системах, распространяемых под лицензией BSD, не переводя их
>под GPL, и в закрытых коммерческих проектах тоже (свободными должны оставаться
>сами программы под GPL, включая их модификации). Желание исключить окружение GNU
>сложно объяснить рациональными причинами, это скорее какое-то неприятие на субъективном уровне.
>Всё это уже обсуждалось в этом топике, повторятся не вижу смысла.
Можно было по крайней мере указать ссылки на те сообщения. Каких-то серьёзных аргументов я не увидел, правда я и не перебирал все сообщения.
>Утилиты из GNU и из разного рода *BSD могут отличаться.даю гарантию, что бинарно они отличаются
>Если проверяется наличие утилит GNU
"не читал но обсуждаю"
>если поступить так, как хотят бсдшники, то качество работы autoconf ухудшится
"если проверять реальную функциональность вместо декларируемой версии, то качество теста ухудшится"
гениально
> >Если проверяется наличие утилит GNU
> "не читал но обсуждаю"Что не так? В новости именно про это и написано: "Иными словами, вместо полноценной поддержки других систем, многие тесты при оценке возможностей системного окружения просто полагаются на наличие или отсутствие GNU-make, GNU-bash, GNU-tar, GNU-m4, GNU-mkdir и т.п."
>"если проверять реальную функциональность вместо декларируемой версии, то качество теста ухудшится"
>гениальноЕсли проверять лишь наличие сходной программы - то качество ухудшится. А проверять функционал может оказаться излишне сложной задачей.
Сравниваю http://www.lissyara.su/doc/man/tar/ и man tar в Debian Lenny. Не вижу в BSD'шной версии например ключей --diff, --delete, имя файла, указываемое при помощи ключа -f в GNU tar, судя по документации, может включать имя хоста, то есть архив может находиться на другом компьютере, назначение ключа -W у них разное - в BSD через него могут передаваться длинные опции, а в GNU он означает проверку архива после записи и т.д. Функционал различается. Хотя есть и много общего. Ну так что, проверять каждую используемую опцию - понимает ли её система, на которой выполняется компиляция, и правильно ли понимает? Намного проще и для разработчика, и для того, кто ставит программу, просто проверять наличие GNU tar.