From: Mikhail Yakshin <greycat@altlinux.org> To: ALT Linux Sisyphus discussions <sisyphus@lists.altlinux.org> Subject: Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools Date: Wed, 15 Jul 2009 03:13:36 +0400 Message-ID: <240e377b0907141613s2b596ca6q72b23b9ac08e4c24@mail.gmail.com> (raw) In-Reply-To: <s933a90bbm4.fsf@chen.chizhovka.net> Приветствую, >> Perl/Python/Ruby с некоторой натяжкой есть на практических всех >> современных Linux/BSD-системах. > Мысль понял. Почему я не использую ЯП, вместо комбинации POSIX shell + > unix tools? Ответ простой. Потому что средство подбирается не по > принципу "крутости", современности или распространенности, а исходя из > задачи. Система сборки -- задача простая, и для ее реализации я выбрал > подходящие на мой взгляд и простые средства. Ни питон, ни руби, ни перл > там не нужны. Тем более, что все они довольно громоздкие. Система сборки - на мой взгляд - одна из самых сложных частей рабочего окружения. Python/Ruby/Perl >> "POSIX shell" фактически нет нигде. С некоторой натяжкой можно >> считать, что bash есть везде, но: > У меня достаточно большой опыт написания портабельных скриптов на шеле, > авке и прочих под разные оси. Позвольте в этом усомниться. >> 1. К POSIX shell он имеет довольно приблизительное отношение. > shell как шел, только очень медленный по сравнению с некоторыми другими. > Где список претензий к bash по части POSIX? > >> 2. Его поведение сильно зависит от сборки в конкретном месте. > Я не пользуюсь GNU-ыми расширениями. > >> 3. Авторы его регулярно ломают и это поведение меняют. > В части POSIX? Где? Обсуждение этого вопроса достаточно объемно и, думаю, выходит за рамки тематики системы сборки и обсуждения в этом списке рассылки. Если хотите - можно продолжить это обсуждение приватно. Вашу точку зрения на портабельность POSIX shell, utilities и святую веру в то, что там и правда всё хорошо и одинаково работает я понял. Странно, что вы сами себе противоречите - перечислили столько исключений, которые сами патчили >> "NetBSD make", если понимать это буквально, еще более исчезающе редок. > Этот аргумент я принимаю, но только как маркетоидный, но не как > технический. > > NetBSD make нужно именно буквально понимать. bmake -- это портированный > на другие платформы NetBSD make. Об-autotools-еный. Регулярно синкается > с репозиторием NetBSD. Где он не работает я просто не знаю. Наверное, > только на нативной винде. Не в курсе. Собственно, нежелание поддерживать ничего, кроме POSIX, тоже вряд ли приведет к чему-то хорошему. "Конкуренты" уже давно признали существование Windows, OS X, Symbian. Зачем мне выбирать систему, которая будет заведомо работать только на POSIX, когда я могу выбрать систему, которая будет работать на еще 3 дополнительных платформах? Даже если я не поддерживаю их сейчас - может быть я захочу облегчить себе жизнь в будущем. > Почему я не использую GNU make? Этот вопрос надо добавить в FAQ: > - потому что для GNU make я не нашел аналога mk-files > (возможно, плохо искал) > - потому что меня воротит от уродливой комбинации foreach/eval/call вместо > простого и элегантного bsdmake-овского .for/.endfor, который, кстати, > повсеместно используется в mk-configure. > - потому что bmake проще и понятнее, чем GNU make. Все 3 объяснения, мягко говоря, субъективны. Я, например, поверхностно знаком с bmake - никаких восторгов от него не испытываю. Если вдаваться в функционально-декларативную идею make - то конструкции вида foreach вообще противоестественны. >> Если будете пытаться генерировать Makefiles так, чтобы "работало >> везде" - и на bmake, и на GNU make - потеряете массу >> возможностей. > Даже при поверхностном прочтении тех ссылок, что я давал, станет > очевидно, что кодогенерация -- это как раз то, от чего я отказался. > Там прямо так и написано. Описался, извините. "Писать Makefiles". >> Будете поддерживать только bmake - сильно осложняете >> использование своего продукта для Linux-пользователей. > Тут согласен. Но не так уж "сильно" и только на первых порах. Думаю, не > секрет, что пишущие на autoconf как правило очень плохо знают m4. Ну и > пакетирование, к примеру, пакетов для pkgsrc тоже не требует глубинных > знаний bmake-а, хотя все Makefile-ы пакетов написаны на нем. Есть > несколько шаблонных конструкций, которые легко выучить и оперивать ими > буквально годами, не вникая в детали bmake. Кроме того (повторюсь) bmake > проще GNU make-а, поэтому изучить его значительно легче. Т.о. проблема > обучения имеет место, но не очень серьёзная. Сравнивать же > bmake/mk-configure с scons/waf (python!) по сложности обучения я просто > не буду. Это вообще не серьезно. И не надо говорить, что питон > уже все знают. Субъективно - scons/waf/cmake - проще, чем то, что я вижу в mk-configure. И да, perl/python/ruby, как ни странно, прилично знают действительно значительно большее количество человек, чем прилично знают shell и Makefiles. >> Критика любых make-подобных программ всё так же применима к нему >> (полагаю, Вы с ней знакомы, но эту точку зрения не разделяете). > С чем-то согласен, с чем-то нет. К критике make-ов я отношусь спокойно, > без истерик. Альтернативы типа scons игнорирую, виду их чрезмерной > массивности. python для реализации альтернативных make-ов -- выбор > неудачный. Уж больно он толтый. Естественно, это тоже субъективно. Единственное, чего не очень понимаю - в каком отношении "толстый". Много места занимает? Давно проверяли? Медленно работает? Вообще-то быстрее и эффективнее любых известных мне shell- и make-based решений. >> Я сейчас как раз нахожусь на перепутии проектировании некоей >> достаточно сложной configure-подобной системы для своего проекта и >> анализирую массу информации на эту тему, но к mk-configure, к >> сожалению, пока я серьезно рассматривать не могу. > О! А можно списком набор требований к искомой системе? Боюсь, что это будет опять же оффтопиком в этом постинге, но Система состоит из 2 больших частей: "клиент" и "сервер". Сборка возможна в 4 вариантах. "Варианты" - это набор из десятка-другого типизированных опций и процедуры сборки: 1. Configure, собирается клиент, собирается сервер, все вместе в каком-то виде пакуется в один бинарный пакет. 2. Configure, собирается клиент, пакуется отдельно, собирается сервер, пакуется отдельно. 3. Configure, собирается клиент, пакуется в пакет, собирается root (из кучи пакетов заданного дистрибутива + собранного пакета клиента). Собирается bootstrap-пакет из серверной части. Копируется и устанавливается на целевой сервер, тем самым производя его начальные настройки. Собранный root копируется на целевой сервер (он будет раздаваться по nfs, nfs-демон к этому моменту уже настроен bootstrap-пакетом). Собирается серверная часть системы в несколько пакетов. Пакеты передаются на сервер и там устанавливаются. В конце (или лучше во время) производится множество тестов, призванные проверить работоспособность всего комплекса в целом и выявить проблемы на самом раннем этапе - например, выгрузили root на nfs - проверить, отдается ли по nfs что-нибудь оттуда, настроили DHCP - проверить, отдаются ли адреса в нужные сети. 4. Configure, собирается клиент, пакуется в пакет, собирается root с этим пакетом, пакуется в squashfs/aufs/что-нибудь такое-эдакое, производится магия с загрузчиком, пакуется в iso9660 => получается загрузочный образ Live CD. Сборка производится на некоей системе A (A может быть равно одному из значений типа "ALT Linux", "Debian", "Ubuntu", "SuSE", "RedHat" и т.п.). Клиент и root, в котором будет работать клиент могут быть от системы B, а сервер может работать на системе C - в общем случае A!=B!=C. Желательно, чтобы "C" кроме всего прочего мог быть равен Windows. Добавление поддержки новых вариантов A, B, C не должно быть чем-то сверхъестественным и должно быть сравнительно простым. Под словом "configure" понимается автонастройка сборочной системы - с проверкой кучи всяких мелочей - таким образом, чтобы на системе A было возможно собрать всё, что нужно, для систем B и C - плюс дается некая возможность пользователю задать несколько десятков опций, в том числе выбрать "вариант сборки" (что вытащит дефолты для "десятка-другого" опций), а затем при желании перекрыть эти дефолты. Т.к. опций много и они зависят друг от дружки (например, в зависимости от задания системы "B" могут появляться какие-то специфичные для выбранной системы опции) желательно наличие какого-то удобного конфигуратора - на уровне того, что показывают рядовому пользователю при сборке ядра Linux. Процесс "configure" вполне может быть итеративный или иметь более, чем одну стадию. Например - пользователь имеет A = ALT Linux, B = Debian. Он запускает configure, A детектится, пользователь выбирает B. Configure проверяет наличие в системе кучи всяких инструментов (всяких debhelper или dh-build, например). Если их нет - на этом месте мы прерываемся и говорим пользователю, что у него не установлено то-то. Если все нормально, то мы возвращаемся к простановке опций и даем на этот раз пользователю настроить уже опции, специфичные для A и B или их комбинации. После чего может следовать еще одна проверка и еще один цикл донастройки и т.д. Опции имеет смысл как можно скорее валидировать - если пользователь, сказал, например, "каталог для установки - такой-то", то стоит убедиться в том, что он существует и в него можно писать. Если пользователь сказал, что "целевой сервер - такой-то", то стоит зайти на этот сервер, убедиться в наличии там нужных прав и т.п. Под словами "пакуется в пакет" понимается модульная поддержка упаковки в один из возможных пакетов (в зависимости от выбранных систем B и C - ALT-specific rpm, RH-specific rpm, SuSE-specific rpm, Debian deb, Ubuntu deb и т.п.). Под словами "собирается root", "собирается LiveCD" и т.п. подразумеваются действия, которые зависят от выбранных опций - в первую очередь от выбранных систем B и C. Предполагается, что каждое из таких действий должно быть оформлено в виде некоторого семейства модулей - при сборки выбирается модуль, соответствующий системам B или C из данного семейства. Разумеется, хочется, чтобы была система отслеживания зависимостей - если пользователь задал конфигурацию #1, сказал "make all", у него что-то не собралось или незадеплоилось - он чуть-чуть подправил конфигурацию, сделав тем самым конфигурацию #2 - чтобы были перевыполнены только нужны этапы сборки. Как можно догадаться, речь явно не о file-level dependencies Хочется, чтобы у всего этого был красивый и вменяемый пользовательский интерфейс - чтобы было явно видно, на какой стадии мы находимся сейчас, какой у нас прогресс, сколько еще осталось ждать. Чтобы от всех действий по сборке сохранялись логи в каком-то иерархическом хранилище. Чтобы это всё было привязано (но при желании могло _легко_ отвязываться) к системе контроля версий - чтобы в сборочные единицы куда нужно попадали идентификаторы ревизий и т.п. На саму систему можно посмотреть в районе http://www.inquisitor.ru/ - сейчас вся сборочная система выполнена на GNU Makefiles, многого из желаемого нет. Текущая система сборки работает, но она достаточно сложна и провоцирует разработчиков делать ошибки, которые очень тяжело потом находить и исправлять. Если интересно дискутировать далее на эту тему - предлагаю опять же, в приват. >> Даже если закрыть глаза на bmake, который предлагается заставлять >> ставить всех пользователей, то фатальные, с моей точки зрения, >> недостатки существующей системы такие: > >> * Подмена понятий при разделении хотя бы на 2 шага: интерактивный >> (configure, пользователь долго взаимодействует с опциями и подбирает >> нужную ему комбинацию) и неинтерактивный (make, пользователь пошел >> пить кофе). То, что вы называете "configure" на практике просто >> занимается проверками и кое-что строит на лету, а реальная >> конфигурация на самом деле передается вместе с запуском bmake. > На мой взгляд это совершенно несущественно. Я лично не вижу никакой > двухстадийности. Стадия одна -- построить проект, учитывая особенности > системы. Все. > > Запускаешь, к примеру > > bmake PREFIX=/usr/pkg <other options here> > > и СРАЗУ идешь пить кофе. И, вернувшись через полчаса, узнаешь, что сборка проработала две минуты и упала где-то в начале из-за неправильно указанной опции. Тем не менее, перед падением была проделана масса работы впустую и ее придется всю переделать. А можно было отсечь неверно заданную опцию еще до начала сборки. >> * Достаточно медленная работа, отсутствие адекватного кэширования >> результатов configure. В некотором смысле - это следствие используемых >> инструментов - в том числе см. выше про критику всех make. > Здесь просто полное несоответствие фактам. В mk-configure кеширование > как раз есть, а нет его как раз в autoconf-е (между проектами). Прочитайте, пожалуйста, полностью - "адекватного кэширования". Вы как-то странно постоянно сравниваете себя с autotools > Медленно работает? Глупости. Все работает быстро. Настолько быстро, > насколько это вообще возможно. Количество fork(2)-ов можно даже > посчитать. Ну, для справки - именно fork(2) при выполнении configure проекта на каком-нибудь scons будет в разы меньше - просто потому, что оно не будет вызывать столько всяких внешний программ и столько раз дергать шелл. На глаз - ну посмотрите хотя бы, сколько ./EXAMPLE.configure --help выполняется. По-моему - уже на грани фола, и как это ускорить, не меняя парадигмы - я не представляю. >> * Крайне плохо масштабируемая модель синтаксиса входных файлов. > Здесь не понял. Можно развернуть? Все, что можно передать в сборку из configure, запихивается в environment и command line. Он относительно маленький и пользоваться неирархическими плоскими путями типа MODULE1_SUBMODULE2_SUBSUBMODULE3_SOMETHING_MORE_HERE_OPTION=2 при наличии нескольких сотен опций неудобно. Кроме того, и command line, и environment не резиновые. [...] Остальное почти всё пропустил, надеюсь, про группы, иерархию опцию и деплоймент я понаприводил примеров выше. >> continuous integration и > Я тоже знаю много страшных слов. Но CI не имеет никакого отношения к > системе сборки, насколькоя его понимаю. Вообще-то самое непосредственное. Тоже система, тоже сборки, только работающая не здесь и сейчас по толчку пользователя, а висящая неким демоном и реагирующая на внешние воздействия. Большинство джавных систем сборки это обеспечивают. >> unit testing. > unit testing добавить как раз не проблема. Пишется отдельный модуль > mkc.test.mk, включай и используй. bmake test и оно поехало. Записал в > todo "на подумать", низкий поклон. Хотя, конечно, unit тестирование -- > это явно не задача mk-configure. Авторы приложений и библиотек сами > могут себе написать подходящую для них систему. Есть образцы для > подражания? Речь не о том, чтобы на пустом месте придумать что-то суперновое и супергениальное. Есть масса сложившихся подходов к тестированию - людьми написаны миллионы тестов под JUnit, CUnit, RUnit, Test::More и т.п. Есть "стандарт" TAP (Test Anything Protocol). Идея в том, чтобы обеспечить легкий запуск тестов всех этих форматов и хоть какую-то их интеграцию в сборочную среду. То же самое по сути относится к инструментам code coverage и генерации документации. Современные сборочные фреймворки дают пользователю возможность сделать "что-нибудь test", "что-нибудь coverage" или "что-нибудь doc" и получить вменяемые результаты без написания единой строчки кода, кроме, собственно, самих тестов и документации. >> * Модель эмбеддинга системы сборки в продукт. > В mk-configure эмбендинга как раз нет. mk-configure должен быть > поставлен на систему ПЕРЕД сборкой. Об этом явно говорится в README. Тогда, вероятно, я не так понял роль shell-скрипта "configure". Он не распространяется с продуктом? -- WBR, Mikhail Yakshin
next prev parent reply other threads:[~2009-07-14 23:13 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 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 ` Mikhail Yakshin [this message] 2009-07-15 19:23 ` [sisyphus] " 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=240e377b0907141613s2b596ca6q72b23b9ac08e4c24@mail.gmail.com \ --to=greycat@altlinux.org \ --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