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: V01U2FsdGVkX1/a4WoYgVDaiVOTBJrGAl3jha6YC6K0WWP1U9qIw3 D3E7qRSEXIPP6y To: ALT Linux Sisyphus discussions References: <200907121618.11380.glebus@asd.iao.ru> <240e377b0907121513m5f3f528ev22d5db799d46247c@mail.gmail.com> <240e377b0907141613s2b596ca6q72b23b9ac08e4c24@mail.gmail.com> From: Aleksey Cheusov Date: Wed, 15 Jul 2009 22:23:36 +0300 In-Reply-To: <240e377b0907141613s2b596ca6q72b23b9ac08e4c24@mail.gmail.com> (Mikhail Yakshin's message of "Wed, 15 Jul 2009 03:13:36 +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.5 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: Wed, 15 Jul 2009 19:26:33 -0000 Archived-At: List-Archive: List-Post: >>> "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 >> >> и СРАЗУ идешь пить кофе. > И, вернувшись через полчаса, узнаешь, что сборка проработала две > минуты и упала где-то в начале из-за неправильно указанной опции. 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.