From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on sa.int.altlinux.org X-Spam-Level: * X-Spam-Status: No, score=1.7 required=5.0 tests=BAYES_00,FUZZY_XPILL, RCVD_IN_BL_SPAMCOP_NET, RCVD_IN_SORBS_WEB, SPF_PASS autolearn=no version=3.2.5 X-Authenticated: #3271302 X-Provags-ID: V01U2FsdGVkX18v05BgNLUvU+KXKEeipF6gjeRczi7RCVCaCv8KRe n3/nSnGaLqX2QS To: ALT Linux Sisyphus discussions References: <200907121618.11380.glebus@asd.iao.ru> <240e377b0907121513m5f3f528ev22d5db799d46247c@mail.gmail.com> From: Aleksey Cheusov Date: Mon, 13 Jul 2009 22:56:35 +0300 In-Reply-To: <240e377b0907121513m5f3f528ev22d5db799d46247c@mail.gmail.com> (Mikhail Yakshin's message of "Mon, 13 Jul 2009 02:13:18 +0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.59 Subject: Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools X-BeenThere: sisyphus@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Sisyphus discussions List-Id: ALT Linux Sisyphus discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 19:59:52 -0000 Archived-At: List-Archive: List-Post: Ух ты! А я, признаться, уже и не ожидал увидеть здесь хоть какой-то конструктив... > Perl/Python/Ruby с некоторой натяжкой есть на практических всех > современных Linux/BSD-системах. Мысль понял. Почему я не использую ЯП, вместо комбинации POSIX shell + unix tools? Ответ простой. Потому что средство подбирается не по принципу "крутости", современности или распространенности, а исходя из задачи. Система сборки -- задача простая, и для ее реализации я выбрал подходящие на мой взгляд и простые средства. Ни питон, ни руби, ни перл там не нужны. Тем более, что все они довольно громоздкие. > "POSIX shell" фактически нет нигде. С некоторой натяжкой можно > считать, что bash есть везде, но: У меня достаточно большой опыт написания портабельных скриптов на шеле, авке и прочих под разные оси. > 1. К POSIX shell он имеет довольно приблизительное отношение. shell как шел, только очень медленный по сравнению с некоторыми другими. Где список претензий к bash по части POSIX? > 2. Его поведение сильно зависит от сборки в конкретном месте. Я не пользуюсь GNU-ыми расширениями. > 3. Авторы его регулярно ломают и это поведение меняют. В части POSIX? Где? > Есть dash, он он тоже ужасен и, к тому же, относительно редок (AFAIR, > до сих пор распространение он получил только в Debian - все остальные > ставят сейчас в /bin/sh все равно bash). dash - неплохой шел в качестве системного. Почти идеальный выбор, если бы не дебильный встроенный echo, из-за которого ломается libtool. Даже не знаю, в какой момент и зачем они его так сломали ash. Заставить всех не пользоваться echo абсолютно невозможно. > Есть ash, но он не менее ужасен и исчезающие редок. /bin/sh в NetBSD и FreeBSD -- наследники ash. Равно как и dash. Так что никуда он не исчезающий. > Под красивым словосочетанием "POSIX shell" вы еще, насколько я вижу из > исходников, понимаете sed, awk, grep и еще кучу всяких утилит. Нет. Я, слава богу, вижу разницу между шелом, авком и прочими утилитами. Я надеюсь в этом нет сомнений? > Их BSD-аналоги, скажем, тоже, как ни странно, плохо совместимы с > GNU-реализациями. Я не сажался на иглу GNU и BSD расширений. В программах, которые создаются, чтобы быть портабельными, расширения не использую. О том, где что и какое, я, опять же, в курсе. Много моих PR по поводу NetBSD-ного userspace-а можно найти у них в BTS. Там и shell и xargs и прочее. Сколько патчей я слал или просто репортил на nawk имени bwk я уже просто не помню -- кучу. К сожалению Брайн Керниган, по-моему, их проигнорил с объяснением "у меня так работает 30 лет, поэтому ничего менять не буду". По крайней мере ответа на вопрос "а как же посикс..." я от него так и не дождался. В NetBSD же все приняли, приложили и починили (ну, почти все, есть еще парочка проблем). Арноль Роббинс последний раз исправлял багу от меня в gawk примерно месяц назад, может два. В dash тоже есть мой патч, правда касался сборки. По секрету могу расказать о проблеме в /usr/xpg4/bin/awk. Никуда не репортил, потому что не знаю куда, и не уверен, имеет ли смысл репортить что-то для десятки. Про соляроидный /bin/sh и /usr/bin/awk я ничего не скажу, потому без матюков не смогу. С моей подачи недавно пофиксили одну багу во FreeBSD-ом /bin/sh, любопытные сами найдут. Короче, народ, давайте жить дружно. Я знаю, что можно и чего нельзя сделать на шеле и юниксовых приблудах. И где заложены грабли я тоже знаю. Не все, конечно, но очень многие. > Любой, кто пишет на "POSIX shell" приобретает в удобстве и скорости > написания, но здорово теряет в первую очередь в портабельности. Я ничего нигде не теряю. Я знаю, что я делаю. > Потеря портабельности для системы сборки - смерти подобна. Именно поэтому все пишется на POSIX shell и POSIX unix tools. Напомню, я не выпускаю версии, пока не проверю на всех имеющихся у меня системах. У всех моих проектов есть довольно немаленькое количество тестов. > "NetBSD make", если понимать это буквально, еще более исчезающе редок. Этот аргумент я принимаю, но только как маркетоидный, но не как технический. NetBSD make нужно именно буквально понимать. bmake -- это портированный на другие платформы NetBSD make. Об-autotools-еный. Регулярно синкается с репозиторием NetBSD. Где он не работает я просто не знаю. Наверное, только на нативной винде. Не в курсе. > С GNU make он пересекается плохо. Только в той части, которая POSIX make, на котором ничего сделать нельзя. Не зря примерно треть любителей autoconf сползают на GNU make. Незаметно для себя... В остальном GNU make и NetBSD абсолютно разные. Почему я не использую GNU make? Этот вопрос надо добавить в FAQ: - потому что для GNU make я не нашел аналога mk-files (возможно, плохо искал) - потому что меня воротит от уродливой комбинации foreach/eval/call вместо простого и элегантного bsdmake-овского .for/.endfor, который, кстати, повсеместно используется в mk-configure. - потому что bmake проще и понятнее, чем GNU make. Спасибо за идею насчет FAQ-а. Я таки его заведу. В остальном же GNU make и NetBSD make по возможностям примерно сопоставимы. Теоретически систему аналогичную mk-configure можно написать и на GNU make, я видел по крайней мере одну попытку -- MOBS (a la automake). Жаль, померла. Если найдется желающий, с радостью приму такую реализацию. Пока же занимаюсь поддержкой только NetBSD make, на большее сил нет. > Если будете пытаться генерировать Makefiles так, чтобы "работало > везде" - и на bmake, и на GNU make - потеряете массу > возможностей. Даже при поверхностном прочтении тех ссылок, что я давал, станет очевидно, что кодогенерация -- это как раз то, от чего я отказался. Там прямо так и написано. > Будете поддерживать только bmake - сильно осложняете > использование своего продукта для Linux-пользователей. Тут согласен. Но не так уж "сильно" и только на первых порах. Думаю, не секрет, что пишущие на autoconf как правило очень плохо знают m4. Ну и пакетирование, к примеру, пакетов для pkgsrc тоже не требует глубинных знаний bmake-а, хотя все Makefile-ы пакетов написаны на нем. Есть несколько шаблонных конструкций, которые легко выучить и оперивать ими буквально годами, не вникая в детали bmake. Кроме того (повторюсь) bmake проще GNU make-а, поэтому изучить его значительно легче. Т.о. проблема обучения имеет место, но не очень серьёзная. Сравнивать же bmake/mk-configure с scons/waf (python!) по сложности обучения я просто не буду. Это вообще не серьезно. И не надо говорить, что питон уже все знают. > Сейчас по факту оно несовместимо не только с GNU make С какой стати все должны быть совместимы с каким-то там GNU make? ;-) >, но еще и с FreeBSD/OpenBSD make. Эти make-и в одних местах поломаны. В других сильно недоразвиты по сравнению с bmake. В третьих -- несовместимы, я не в курсе, кто "первый начал", но есть такой печальный факт. > Одно это, в общем-то, хоронит напрочь любую идею, сколько бы хорошей >она ни была. Все, что выше я принимаю. Да, с точки зрения маркетинга выбор не очень удачный. Инструменты малоузнаваемы. Некоторые особо молодые воспринимают в штыки любое незнакомое слово. А если в нем есть BSD, тогда вообще... > Критика любых make-подобных программ всё так же применима к нему > (полагаю, Вы с ней знакомы, но эту точку зрения не разделяете). С чем-то согласен, с чем-то нет. К критике make-ов я отношусь спокойно, без истерик. Альтернативы типа scons игнорирую, виду их чрезмерной массивности. python для реализации альтернативных make-ов -- выбор неудачный. Уж больно он толтый. Естественно, это тоже субъективно. > Я сейчас как раз нахожусь на перепутии проектировании некоей > достаточно сложной configure-подобной системы для своего проекта и > анализирую массу информации на эту тему, но к mk-configure, к > сожалению, пока я серьезно рассматривать не могу. О! А можно списком набор требований к искомой системе? > Даже если закрыть глаза на bmake, который предлагается заставлять > ставить всех пользователей, то фатальные, с моей точки зрения, > недостатки существующей системы такие: > * Подмена понятий при разделении хотя бы на 2 шага: интерактивный > (configure, пользователь долго взаимодействует с опциями и подбирает > нужную ему комбинацию) и неинтерактивный (make, пользователь пошел > пить кофе). То, что вы называете "configure" на практике просто > занимается проверками и кое-что строит на лету, а реальная > конфигурация на самом деле передается вместе с запуском bmake. На мой взгляд это совершенно несущественно. Я лично не вижу никакой двухстадийности. Стадия одна -- построить проект, учитывая особенности системы. Все. Запускаешь, к примеру bmake PREFIX=/usr/pkg и СРАЗУ идешь пить кофе. Но можно сделать и фейковый таргет configure. Еще одно спасибо, включу в TODO. Для тех, у кого ностальгия. В общем, подумаю. > * Отсутствие возможности (насколько я могу судить - принципиальное) > даже в каком-то далеком будущем организовать пользователю красивый > TUI/GUI для сборки. В cmake и scons оно есть. В waf оно планируется в > виде внешнего конфигуратора. А зачем ГУИ для сборки??? Мы же в юниксе. Может его еще и во все цвета радуги раскрасить? :-) Это делается внешними алиасами. У меня, почти все команды цветные, включая make. colorit(1). Цветной make мне даром не нужен. ГУИ тем более. Над строго форматированным текстовым выводом подумаю. И за это спасибо, включу в todo "на подумать". > * Достаточно медленная работа, отсутствие адекватного кэширования > результатов configure. В некотором смысле - это следствие используемых > инструментов - в том числе см. выше про критику всех make. Здесь просто полное несоответствие фактам. В mk-configure кеширование как раз есть, а нет его как раз в autoconf-е (между проектами). Медленно работает? Глупости. Все работает быстро. Настолько быстро, насколько это вообще возможно. Количество fork(2)-ов можно даже посчитать. > * Отсутствие хоть сколько-нибудь минимального набора модулей, умеющих > поддерживать распространенные языки, библиотеки и пакеты - насколько я > могу видеть, даже C/С++-программы сейчас собирать проблематично (ни > pkg-config, ни Qt/KDE, ни boost сходу не подключишь). Это у меня уже в todo, но все равно спасибо. Про pkg-config и qt мне прожужали все уши еще на lvee. Будут модули mkc.pkg-config.mk и mkc.qt.mk. > * Крайне плохо масштабируемая модель синтаксиса входных файлов. Здесь не понял. Можно развернуть? > Нет и я не очень представляю как в представленной парадигме > реализовать подпроекты, Подпроекты есть. См. mkc.subdir.mk Довольно примитивно, но для маленьких и средних проектов достаточно. Для ОЧЕНЬ больших я собирался сделать что-то, очнованное на графах. Опять же, легко все это пишется. Идея родилась в результате очередного флейма. > группы, иерархию опций, зависимости между ними > и т.п. Что имеется ввиду под группами и иерархией опций? > * Отсутствие (насколько я вижу по Вашим ответам - принципиальное) > каких-то средств интеграции в deployment, Можно конкретнее? Чего конкретно хочется? > continuous integration и Я тоже знаю много страшных слов. Но CI не имеет никакого отношения к системе сборки, насколькоя его понимаю. > unit testing. unit testing добавить как раз не проблема. Пишется отдельный модуль mkc.test.mk, включай и используй. bmake test и оно поехало. Записал в todo "на подумать", низкий поклон. Хотя, конечно, unit тестирование -- это явно не задача mk-configure. Авторы приложений и библиотек сами могут себе написать подходящую для них систему. Есть образцы для подражания? > * Модель эмбеддинга системы сборки в продукт. В mk-configure эмбендинга как раз нет. mk-configure должен быть поставлен на систему ПЕРЕД сборкой. Об этом явно говорится в README. > Учитывая выбранные средства программирования - в пределе это дает на > порядок более bloated, чем autotools решение. Как следствие предыдущего пункта -- нет. Таким жирным, как autobloat mk-configure не будет никогда. Именно в силу заложенных в него принципов. > Извините, но оно уже сейчас занимает 35 килобайт - и при этом не умеет > делать практически ничего. Для сравнения - waf занимает 80 и умеет > очень много всего. Я посмотрю на забытый всеми waf и сравню, что он может и чего нет. -- Best regards, Aleksey Cheusov.