From: Aleksey Cheusov <vle@gmx.net> To: ALT Linux Sisyphus discussions <sisyphus@lists.altlinux.org> Subject: Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools Date: Mon, 13 Jul 2009 22:56:35 +0300 Message-ID: <s933a90bbm4.fsf@chen.chizhovka.net> (raw) In-Reply-To: <240e377b0907121513m5f3f528ev22d5db799d46247c@mail.gmail.com> (Mikhail Yakshin's message of "Mon, 13 Jul 2009 02:13:18 +0400") Ух ты! А я, признаться, уже и не ожидал увидеть здесь хоть какой-то конструктив... > 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 <other options here> и СРАЗУ идешь пить кофе. Но можно сделать и фейковый таргет 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.
next prev parent reply other threads:[~2009-07-13 19:56 UTC|newest] Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top 2009-07-12 5:53 Aleksey Cheusov 2009-07-12 9:18 ` Gleb Kulikov 2009-07-12 14:44 ` Aleksey Cheusov 2009-07-12 17:18 ` Gleb Kulikov 2009-07-12 17:37 ` Aleksey Cheusov 2009-07-16 10:52 ` Gleb Kulikov 2009-07-12 22:13 ` Mikhail Yakshin 2009-07-13 19:56 ` Aleksey Cheusov [this message] 2009-07-13 21:02 ` Led 2009-07-13 21:18 ` Aleksey Cheusov 2009-07-14 1:49 ` [sisyphus] [JT] " Pavel N. Solovyov 2009-07-14 5:22 ` Afanasov Dmitry 2009-07-14 6:21 ` Aleksey Cheusov 2009-07-14 23:13 ` [sisyphus] " Mikhail Yakshin 2009-07-15 19:23 ` Aleksey Cheusov 2009-07-15 19:41 ` Vitaly Kuznetsov 2009-07-15 19:53 ` Aleksey Cheusov 2009-07-12 12:03 ` Alexey I. Froloff 2009-07-12 12:07 ` Alexey Gladkov 2009-07-12 13:48 ` Aleksey Cheusov 2009-07-12 14:52 ` Alexey Gladkov 2009-07-12 15:15 ` Aleksey Cheusov 2009-07-12 18:57 ` Денис Смирнов 2009-07-12 20:02 ` Aleksey Cheusov 2009-07-12 20:31 ` Alexey I. Froloff 2009-07-12 20:41 ` Aleksey Cheusov 2009-07-12 20:49 ` Alexey I. Froloff 2009-07-12 21:00 ` Aleksey Cheusov 2009-07-12 21:03 ` Aleksey Cheusov 2009-07-12 22:17 ` Alexey I. Froloff 2009-07-13 20:03 ` Aleksey Cheusov 2009-07-13 20:54 ` Alexey I. Froloff 2009-07-13 21:06 ` Aleksey Cheusov 2009-07-13 21:12 ` Alexey I. Froloff 2009-07-13 21:23 ` Aleksey Cheusov 2009-07-13 21:43 ` Alexey I. Froloff 2009-07-12 21:27 ` Alexey Rusakov 2009-07-12 21:36 ` Alexey I. Froloff 2009-07-12 22:29 ` Aleksey Cheusov 2009-07-12 23:04 ` Alexey I. Froloff 2009-07-13 5:26 ` Alexey Rusakov 2009-07-13 6:05 ` Денис Смирнов 2009-07-13 8:26 ` Afanasov Dmitry 2009-07-13 17:54 ` Денис Смирнов 2009-07-13 20:20 ` Aleksey Cheusov 2009-07-13 20:52 ` Alexey I. Froloff 2009-07-13 21:06 ` Aleksey Cheusov 2009-07-13 21:39 ` Alexey I. Froloff 2009-07-13 19:43 ` [sisyphus] mk-configure: args vs options Dmitry V. Levin 2009-07-13 20:28 ` Aleksey Cheusov 2009-07-13 20:40 ` Dmitry V. Levin 2009-07-12 16:06 ` [sisyphus] mk-configure -- lightweight replacement for GNU autotools Led 2009-07-12 16:18 ` Aleksey Cheusov 2009-07-12 16:28 ` Led 2009-07-13 20:36 ` Dmitry V. Levin 2009-07-13 20:56 ` Aleksey Cheusov 2009-07-13 21:29 ` Dmitry V. Levin 2009-07-14 6:37 ` Aleksey Cheusov 2009-07-14 6:53 ` Afanasov Dmitry 2009-07-14 18:25 ` Aleksey Cheusov 2009-07-14 18:32 ` Led 2010-06-12 14:56 ` Aleksey Cheusov 2010-06-15 3:25 ` REAL 2010-06-15 6:05 ` Aleksey Cheusov 2010-06-15 5:29 ` REAL 2010-06-15 7:19 ` Slava Semushin 2010-06-15 7:22 ` Aleksey Cheusov 2010-06-15 7:03 ` REAL 2010-06-15 7:52 ` REAL 2010-06-15 9:39 ` Aleksey Cheusov
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=s933a90bbm4.fsf@chen.chizhovka.net \ --to=vle@gmx.net \ --cc=sisyphus@lists.altlinux.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux Sisyphus discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/sisyphus/0 sisyphus/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 sisyphus sisyphus/ http://lore.altlinux.org/sisyphus \ sisyphus@altlinux.ru sisyphus@altlinux.org sisyphus@lists.altlinux.org sisyphus@lists.altlinux.ru sisyphus@lists.altlinux.com sisyphus@linuxteam.iplabs.ru sisyphus@list.linux-os.ru public-inbox-index sisyphus Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.sisyphus AGPL code for this site: git clone https://public-inbox.org/public-inbox.git