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: Wed, 15 Jul 2009 22:23:36 +0300 Message-ID: <s937hy9da2v.fsf@chen.chizhovka.net> (raw) In-Reply-To: <240e377b0907141613s2b596ca6q72b23b9ac08e4c24@mail.gmail.com> (Mikhail Yakshin's message of "Wed, 15 Jul 2009 03:13:36 +0400") >>> "POSIX shell" фактически нет нигде. С некоторой натяжкой можно >>> считать, что bash есть везде, но: >> У меня достаточно большой опыт написания портабельных скриптов на шеле, >> авке и прочих под разные оси. > Позвольте в этом усомниться. В своем прошлом письме Вы наглядно продемонстрировпли, что ваше представление о userspace-ах, отличных от GNU, в некоторой дымке, мягко говоря. Поэтому кому кому, но точно не Вам судить о степени моей компетенции в этом вопросе. К тому же я что-то не припомню имени Михаил Якшин среди тех, что репортили мне хоть когда-нибудь хоть что-нибудь. В общем, оставим очень животрепещую тему моих умений и перейдем к следующей теме. Впрочем, чему я удивляюсь? Мы же русские люди. Полудикий северный народ... Подраться, побить друг другу морды, помирится и обнятся, потому вместе с битыми физиономиями пойти пить водку. >>> 3. Авторы его регулярно ломают и это поведение меняют. >> В части POSIX? Где? > Обсуждение этого вопроса достаточно объемно и, думаю, выходит за рамки > тематики системы сборки и обсуждения в этом списке рассылки. Если > хотите - можно продолжить это обсуждение приватно. Все проблемы bash, свзанные с POSIX давно описаны авторами здесь http://www.gnu.org/software/bash/manual/html_node/Bash-POSIX-Mode.html И среди них ни одной, что мешала бы писать на bash переносимые скрипты. В основном нарушения касаются интерактивного шела. К тому же есть волшебные пузырки --enable-strict-posix-default. > Вашу точку зрения на портабельность POSIX shell, utilities и святую > веру в то, что там и правда всё хорошо и одинаково работает я понял. Мою точку зрения Вы не поняли, и понять не могли, потому что не прочитали написанное. Точка. >> NetBSD make нужно именно буквально понимать. bmake -- это портированный >> на другие платформы NetBSD make. Об-autotools-еный. Регулярно синкается >> с репозиторием NetBSD. Где он не работает я просто не знаю. Наверное, >> только на нативной винде. Не в курсе. > Собственно, нежелание поддерживать ничего, кроме POSIX, тоже вряд ли > приведет к чему-то хорошему. "Конкуренты" уже давно признали > существование Windows, OS X, Symbian. MacOS-X - это нормальный UNIX, даже сертифицированный с недавних пор. Что касается Windows... Меня он действительно не интересует. Совсем. К тому же я уже сказал, что для винды есть cygwin, Interix и много чего еще, и кросс-сборка в списке моих приоритетов. Так что здесь я не вижу проблем. Хотите собирать под windows и symbian -- собирайте. > Если вдаваться в функционально-декларативную идею make - то > конструкции вида foreach вообще противоестественны. Мухи отдельно, котлеты отдельно. Эта тема уже горяче обсуждалась С Виктором Вагнером не так давно в фидо. Мой ответ на точно такой же его вопрос где-то здесь. http://groups.google.com/group/fido7.ru.unix.prog/browse_thread/thread/58ebfd29006c1afe/8944e979305bd3dc?lnk=gst&q=cheusov+wagner+%22.foreach%22#8944e979305bd3dc Вопрос Витуса искать по фразе "сливай воду". Вкратце. Декларативный уровень make-а и циклы .foreach находятся на разных уровнаях make-а, они абсолютно не пересекаются. >> И не надо говорить, что питон уже все знают. > Субъективно - scons/waf/cmake - проще, чем то, что я вижу в > mk-configure. Ок. Михаила Якшина вычеркиваем :-) > действительно значительно большее количество человек, чем прилично > знают shell и Makefiles. Если разработчики под UNIX уже не знают ни make ни shell, то мне становится страшно. >>> Я сейчас как раз нахожусь на перепутии проектировании некоей >>> достаточно сложной configure-подобной системы для своего проекта и >>> анализирую массу информации на эту тему, но к mk-configure, к >>> сожалению, пока я серьезно рассматривать не могу. >> О! А можно списком набор требований к искомой системе? > Боюсь, что это будет опять же оффтопиком в этом постинге, но > Система состоит из 2 больших частей: "клиент" и "сервер". > Сборка возможна в 4 вариантах. "Варианты" - это набор из > десятка-другого типизированных опций и процедуры сборки: > 1. Configure, собирается клиент, собирается сервер, все вместе в > каком-то виде пакуется в один бинарный пакет. По-моему это не список требований к системе сборки, а модель развертывания чего-то где-то. Слишком много частностей, среди которых я не уловил ни одной принципиальной проблемы для чего-то, основанного на bmake, в том числе mk-configure. Или я чего-то не понял за лесом несущественных мелочей? Комбайнов по развертыванию всяких систем и созданию LiveCD по-моему как грязи. > Т.к. опций много и они зависят друг от дружки (например, в зависимости > от задания системы "B" могут появляться какие-то специфичные для > выбранной системы опции) желательно наличие какого-то удобного > конфигуратора - на уровне того, что показывают рядовому пользователю > при сборке ядра Linux. Как ГУИ конфигураторы, так и проверка непротиворечивости заданных опций делаются отдельными модулями. Последнее, например можно сделать отдельным .mk модулем. Зачем городить всеумеющий саморазваливающийся комбайн? > Процесс "configure" вполне может быть итеративный или иметь более, чем > одну стадию. Моя религия: командный интефейс отдельно, диалоги с пользовалетем -- отдельно, уровнем выше. Спрашивать "А вы уверены? Точно?" это не задача системы сборки. > Опции имеет смысл как можно скорее валидировать - если пользователь, > сказал, например, "каталог для установки - такой-то", то стоит > убедиться в том, что он существует и в него можно писать. Отдельный модуль и make precheck или make validate. Это вообще не зависит от выбора системы сборки. > Если пользователь сказал, что "целевой сервер - такой-то", то стоит > зайти на этот сервер, убедиться в наличии там нужных прав и т.п. > Под словами "пакуется в пакет" понимается модульная поддержка упаковки > в один из возможных пакетов (в зависимости от выбранных систем B и C - > ALT-specific rpm, RH-specific rpm, SuSE-specific rpm, Debian deb, > Ubuntu deb и т.п.). mkc.deb.mk, mkc.altlinux-rpm.mk и тд. > Предполагается, что каждое из таких действий должно быть оформлено в > виде некоторого семейства модулей - при сборки выбирается модуль, > соответствующий системам B или C из данного семейства. Мелочи. > Разумеется, хочется, чтобы была система отслеживания зависимостей - > если пользователь задал конфигурацию #1, сказал "make all", у него > что-то не собралось или незадеплоилось - он чуть-чуть подправил > конфигурацию, сделав тем самым конфигурацию #2 - чтобы были > перевыполнены только нужны этапы сборки. Как можно догадаться, речь > явно не о file-level dependencies Нельзя этого видеть. В pkgsrc, например, после успешной стадии fetch, checksum, extract, patch, configure, build, build, ... touch-ится соответствующий файл в специальном месте. У меня есть любимый анекдот на эту тему. > Хочется, чтобы у всего этого был красивый и вменяемый пользовательский > интерфейс - чтобы было явно видно, на какой стадии мы находимся > сейчас, какой у нас прогресс, сколько еще осталось ждать. Ой. > На саму систему можно посмотреть в районе http://www.inquisitor.ru/ - гляну. > Если интересно дискутировать далее на эту тему - предлагаю опять же, в приват. "Дискутировать" на тему inquisitor я не в состоянии. Гляну -- посмотрим. Пока слушаю, но, подозреваю, Вам хочется всеумеющий комбайн, который разваливается от времени под собственным весом. Такое не может существовать без капиталовложений десятка транснациональных корпораций и тысяч человеко-часов. Надеюсь, я ошибаюсь. Если мы еще хоть косвенно о mk-configure, то таким путем он точно не пойдет. ВСЕГО он уметь не будет. Никогда. >> bmake PREFIX=/usr/pkg <other options here> >> >> и СРАЗУ идешь пить кофе. > И, вернувшись через полчаса, узнаешь, что сборка проработала две > минуты и упала где-то в начале из-за неправильно указанной опции. make precheck спасет раненого кота. Это не проблема системы сборки, это проблема писателя и запускателя Makefile-ов. >> Здесь просто полное несоответствие фактам. В mk-configure кеширование >> как раз есть, а нет его как раз в autoconf-е (между проектами). > Прочитайте, пожалуйста, полностью - "адекватного кэширования". Вы > как-то странно постоянно сравниваете себя с autotools Термин "адекватное кэширование" прямо таки требует раскрытия. > Ну, для справки - именно fork(2) при выполнении configure проекта на > каком-нибудь scons будет в разы меньше - просто потому, что оно не > будет вызывать столько всяких внешний программ и столько раз дергать > шелл. Это не принципиально. Основные потери не на шеле, и не на форках. > На глаз - ну посмотрите хотя бы, сколько ./EXAMPLE.configure --help > выполняется. По-моему - уже на грани фола, и как это ускорить, не > меняя парадигмы - я не представляю. EXAMPLE.configure -- это фейк, его нет, там пусто. Он ничего не делает вообще. Это пример нереализованного будушего. >>> * Крайне плохо масштабируемая модель синтаксиса входных файлов. >> Здесь не понял. Можно развернуть? > Все, что можно передать в сборку из configure, запихивается в > environment и command line. Он относительно маленький и пользоваться > неирархическими плоскими путями типа > MODULE1_SUBMODULE2_SUBSUBMODULE3_SOMETHING_MORE_HERE_OPTION=2 > при наличии нескольких сотен опций неудобно. Я их не вижу. Поэтому все удобно. Если хочется config файл, я уже показывал, как его сделать. bmake -f huge_amount_of_setting_here.mk -f Makefile или, например, .sinclude "local_setting.mk" внутри Makefile. > Кроме того, и command > line, и environment не резиновые. command line хватит на тысячи опций. Несчастные пользователи поломанного Irix shell, у которого лимит что-то вроде 20Kb, поставят себе нормальный shell и тоже будут счастливы. environment? Никогда не видел, чтобы его не хватило. Кроме того, см. выше про -f -f. >>> continuous integration и >> Я тоже знаю много страшных слов. Но CI не имеет никакого отношения к >> системе сборки, насколькоя его понимаю. > Вообще-то самое непосредственное. Тоже система, тоже сборки, только > работающая не здесь и сейчас по толчку пользователя, а висящая неким > демоном и реагирующая на внешние воздействия. Большинство джавных > систем сборки это обеспечивают. wikipedia описывает термин слишком общё. Он включает МАССУ разных вещей. Зачем нужен демон мне совершенно не очевидно. >> Авторы приложений и библиотек сами >> могут себе написать подходящую для них систему. Есть образцы для >> подражания? > Речь не о том, чтобы на пустом месте придумать что-то суперновое и > супергениальное. Есть масса сложившихся подходов к тестированию - > людьми написаны миллионы тестов под JUnit, CUnit, RUnit, Test::More и > т.п. Есть "стандарт" TAP (Test Anything Protocol). Идея в том, чтобы > обеспечить легкий запуск тестов всех этих форматов и хоть какую-то их > интеграцию в сборочную среду. .include "mkc.JUnit.mk" bmake test > То же самое по сути относится к инструментам code coverage и генерации > документации. mkc.man.mk и mkc.info.mk уже есть много-много лет. Они умеют делать много разного. Есть мега проект mk-latex. Все остальное -- аналогично. > Современные сборочные фреймворки дают пользователю > возможность сделать "что-нибудь test", "что-нибудь coverage" или > "что-нибудь doc" и получить вменяемые результаты без написания единой > строчки кода, кроме, собственно, самих тестов и документации. Одна строчка нужна всегда "хочу подлючить такой-то модуль". И ровно одна требуется при подходе mk-configure. >>> * Модель эмбеддинга системы сборки в продукт. >> В mk-configure эмбендинга как раз нет. mk-configure должен быть >> поставлен на систему ПЕРЕД сборкой. Об этом явно говорится в README. > Тогда, вероятно, я не так понял роль shell-скрипта "configure". Он не > распространяется с продуктом? Во-первых, shell скрипт configure -- это для тех, кого бесит bmake. Во-вторых это не реализовано, это только мысли вслух. В-третьих, это замена только для autoconf, но никак не для automake. В-четвертых -- это не "эмбеддинг", это "файл конфигурации". Сама же библиотека mkc_configure (source mkc_configure) -- ставится вместе с mk-configure. -- Best regards, Aleksey Cheusov.
next prev parent reply other threads:[~2009-07-15 19:23 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 ` [sisyphus] " Mikhail Yakshin 2009-07-15 19:23 ` Aleksey Cheusov [this message] 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=s937hy9da2v.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