[sisyphus] mk-configure -- lightweight replacement for GNU autotools

[sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Aleksey Cheusov]

[-- Attachment #1: Type: text/plain, Size: 126 bytes --]


Мне говорят, я все-таки ошибся со списком рассылки.  Отправлю еще
сюда. Виталий Липатов уже запакетил mk-configure в сизиф.


[-- Attachment #2: Type: message/rfc822, Size: 5843 bytes --]

From: Aleksey Cheusov <vle@gmx.net>
To: community@lists.altlinux.org
Subject: [Comm] mk-configure -- lightweight replacement for GNU autotools
Date: Sat, 11 Jul 2009 20:34:27 +0300
Message-ID: <s93prc7run0.fsf@chen.chizhovka.net>


Привет всем. Скажу сразу, я не являюсь ни пользователем ни разработчиком
ALT Linux, поэтому в некотром смысле мое письмо будет здесь
offtopic-ом. Но поскольку ALT Linux - это не только компания и линейка
продуктов, но также и наиболее крупное и известное на постсоветском
пространстве русскоязычное объединение FOSS разработчиков, то, я
надеюсь, найти здесь разработчиков, с которыми интересно было бы кое-что
обсудить.  Возможно, это будет интересно не только программистам из
community ALT Linux, но и компании ALT Linux и ее full-time
разработчикам.  Если я ошибся списком рассылки, дайте знать.

Речь идет об одной из моих последних open source разработок,
mk-configure, легковесной простой использовании (да, я знаю, звучит как
маркетоидное заклинание :-) , уж простите ) альтернативе GNU
autotools. Ни много, ни мало...
Разработка совсем новая, ей всего около 4 месяцев.

Как многие, наверное, здесь знают, недавно в Беларуси проходила
конференция разработчиков и пользователей FOSS, LVEE (Linux Vacation /
Eastern Europe, http://www.lvee.org), где я впервые представил
mk-configure публике (не считая списка рассылки netbsd-users@ ).

----------------------------------------------------------------------
Прекращаю усыплять публику. Даю ссылки.

Небольшая статья на русском с описанием проблемы. Критика там же. В
общем, motivation. Описаны также общий подход и принципы моего решения
проблемы.
http://mova.org/~cheusov/pub/lvee-2009/mk-configure_article.pdf

Презентация на английском с небольшим количеством на мой взгляд вполне
наглядных и показательных примеров.
http://mova.org/~cheusov/pub/lvee-2009/mk-configure_presentation.pdf
Презентация также есть и на сайте LVEE.

README файл проекта (краткое описание, в принципе, во многом повторение
того, что выше, только на английском):
http://www.mova.org/~cheusov/pub/mk-configure/README

Официальная страница проекта:
http://sourceforge.net/projects/mk-configure/
http://freshmeat.net/projects/mk-configure/
Полная документация на английском внутри тарбола.
Сайта пока нет.

Если кого заинтересует, буду рад пообщаться на эту тему.  Ежели кто
заинтересуется настолько, что запакетирует все это добро в ALT Linux и
возьмет на себя обязательства это сопровождать, будет вообще прекрасно
:-)

-- 
Best regards, Aleksey Cheusov.
_______________________________________________
community mailing list
community@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/community

[-- Attachment #3: Type: text/plain, Size: 37 bytes --]



-- 
Best regards, Aleksey Cheusov.

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Gleb Kulikov]

В сообщении от [Воскресенье 12 июля 2009 Aleksey Cheusov] написал:

> Мне говорят, я все-таки ошибся со списком рассылки.  Отправлю еще
> сюда. Виталий Липатов уже запакетил mk-configure в сизиф.

Если не секрет, в двух словах, чем эта альтернатива лучше scons, например?
Спасибо.



-- 
      Салют, /GLeb

UIN: 15341920
jabber://gleb@asd.iao.ru
sip://2387245@sipnet.ru			(telephony)
skype://gleb_kulikov.tomsk		(telephony)
sip://20000204@sip.pctel.ru		(telephony)
netmail: 2:5005/78

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 313 bytes --]

On Sun, Jul 12, 2009 at 08:53:15AM +0300, Aleksey Cheusov wrote:
> mk-configure, легковесной простой использовании (да, я знаю, звучит как
> маркетоидное заклинание :-) , уж простите ) альтернативе GNU
> autotools. Ни много, ни мало...
Очередной велосипедист ниасилил autotools?

-- 
Regards,
Sir Raorn.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Alexey Gladkov]

12.07.2009 09:53, Aleksey Cheusov wrote:
> Речь идет об одной из моих последних open source разработок,
> mk-configure, легковесной простой использовании (да, я знаю, звучит как
> маркетоидное заклинание :-) , уж простите ) альтернативе GNU
> autotools. Ни много, ни мало...

Вопрос: зачем ?

Что даст ваша новая система обычному мантейнеру проекта (не путать с
мантейнером rpm пакета) ?

-- 
Rgrds, legion

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Aleksey Cheusov]

 >> Речь идет об одной из моих последних open source разработок,
 >> mk-configure, легковесной простой использовании (да, я знаю, звучит как
 >> маркетоидное заклинание :-) , уж простите ) альтернативе GNU
 >> autotools. Ни много, ни мало...

> Вопрос: зачем ?
Об этом достаточно подробно написано по ссылкам.

> Что даст ваша новая система обычному мантейнеру проекта (не путать с
> мантейнером rpm пакета) ?
Гораздо более простую и легкую в использовании систему.  Отсутствие
необходимости читать тонны ненужной макулатуры.  С точки зрения дизайна
mk-configure сильно отличается от других систем подобного назначения,
возможно, этот дизайн окажет влияние на проект автора.

-- 
Best regards, Aleksey Cheusov.

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Aleksey Cheusov]

> В сообщении от [Воскресенье 12 июля 2009 Aleksey Cheusov] написал:

 >> Мне говорят, я все-таки ошибся со списком рассылки.  Отправлю еще
 >> сюда. Виталий Липатов уже запакетил mk-configure в сизиф.

> Если не секрет, в двух словах, чем эта альтернатива лучше scons, например?
> Спасибо.

Если в двух словах, то mk-configure - это логическое продолжение mk
скриптов в BSD системах. Те, кто видел дерево исходников BSD систем
(базовые системы, не порты) понимают, о чем я. mk-configure -- развитие
тех же идей с добавлением ala autoconf функциональности и кое-чего
другого типа замены @полей@ в .in файлах.
Но основные идеи следующие:
- декларативный способ написания Makefile-ов;
- никакой годогенерации;
- модули пишутся на bmake и внешних скриптах на POSIX shell + unix tools,
естественно никто не запретит использовать другие средства.

-----------------
Дальше попробую по пунктам (взято из википедии).

* Configuration files are Python scripts, which means that user-written
builds have access to a complete general-purpose programming language.

Модули mk-configure пишутся на NetBSD make aka bmake + внешние скрипты.

Automatic dependency analysis built-in for C, C++ and Fortran. Unlike
make, no extra command like "make depend" or "make clean"[1]...

Этого в mk-configure нет, но это задача другого уровня -- уровня
bmake-а, а он этого не делает. Нужен 'bmake depend'.  Хотя можно
написать .mk модуль для реализации этой функциональности.
Я об этом подумаю...

Built-in support for C, C++, D, Java, Fortran, Objective-C, Yacc, Lex,
Qt and SWIG, and building TeX and LaTeX documents. Other languages or
file types can be supported through user-defined Builders.

mk-configure использует в качестве "подложки" pkgsrc mk-files или
mk-files имени Simon Gerraty. Это реализовано там: yacc, lex, C, C++,
Java, Fortran, Pascal, Modula-2, что-то еще. Есть отдельный модуль для
latex, но я не смотрел, что он из себя представляет. Надо глянуть. В чем
заключаться поддержка qt и swig я себе не представляю. Скорее, всего это
также можно реалиовать в виде модуля для mk-configure. Можно сделать
поддержку, скажем, модулей emacs или, например, модуль "а сделай ка мне
их этого всего софта deb пакет".

Building from central repositories of source code and/or pre-built
targets.

Этого я не понимаю. bmake - это make. Со всеми вытекающими.

Built-in support for fetching source files from SCCS, RCS, CVS,
Subversion, BitKeeper and Perforce.

Этого нет ни в каком виде и, на мой взгляд, не должно быть.  Это
совершенно другая задача.

Built-in support for Microsoft Visual Studio .NET and past Visual Studio
versions, including generation of .dsp, .dsw, .sln and .vcproj files.

Этого нет, как нет НИКАКОЙ кодогенерации. Меня виндоуз как плдатформа не
интересует. Кому нужен виндоуз, пусть использует cygwin или Interix и
оттуда строит нативные виндозные библиотеки и приложения.  Поддержка
кросскомпиляции тоже есть (то есть нет ничего, что ее ломало бы), пока не
идеальная, но я над этим работаю.

Detection of file content changes using MD5 signatures; optional,
configurable support for traditional timestamps.

Это задача не уровня mk-configure. Это задача bmake-а и он этого не
делает. Возможно, когда-нибудь научится.

Support for parallel builds which keeps the specified number of jobs
running simultaneously regardless of directory hierarchy.

Это опять задача bmake-а и он это умеет больше 15 лет.
Хотя "regardless of directory hierarchy" нет.
Стандартный модуль "mkc.subdir.mk" имеет ограничения.
Возможно написать другой, с более тонкими зависимостями
между подпроектами-подкаталогами.

Integrated Autoconf-like support for finding #include files, libraries,
functions and typedefs.

mk-configure умеет: определять наличие декларации типов, переменных,
функций, полей структур, дефайнов, наличие реализации функций в
библиотеках, определять размеры типов. Добавлю еще поддержку структур.
В следующей версии добавлю custom тесты с запуском приложения и без
него. В ближайшее время добавлю проверку endianess.

Global view of all dependencies, so multiple build passes or reordering
targets is not required.

Я не понимаю, о чем это.

Ability to share built files in a cache to speed up multiple builds -
like ccache but for any type of target file, not just C/C++ compilation.

Это не задача mk-configure. Это задача ccache и подобных инструментов.
Естественно, их можно использовать и с mk-configure тоже.

Designed from the ground up for cross-platform builds, and known to work
on Linux, other POSIX systems (including AIX, *BSD systems, HP-UX, IRIX
and Solaris), Windows NT, Mac OS X, and OS/2.

mk-configure работает на: NetBSD, Linux, FreeBSD, Solaris,
DragonFlyBSD.  У меня нет доступа к другим платформ. Если у кого есть,
буду весьма признателен за тесты (bmake test).
С удовольствием протестировал бы на HP-UX, QNX, Irix и прочих
AIX-ах. Пришу в подарок shell account :-) На данный момент нет поддержки
libtool, поэтому есть проблемы с Darwin в плане создания динамических
библиотек. Поддержку libtool планирую добавиь. Другой вариант -- пинать
авторов mk-files (NetBSD-шники), который ха это отвечает.
Это реализовано там.

-----------------
Вроде в двух словах так.
Но я не сравнивал очень подробно со всеми всеми всеми...

В тарболе есть примеры использования. По моему они вполне наглядны.
Разницу можно увидеть.

-- 
Best regards, Aleksey Cheusov.

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Alexey Gladkov]

12.07.2009 17:48, Aleksey Cheusov wrote:
>> Вопрос: зачем ?
> Об этом достаточно подробно написано по ссылкам.

Читал. Многое спорно, но спорить не буду.

> Гораздо более простую и легкую в использовании систему.

Run bmake for configuring and building your project and pass to it
building parameters, e.g.

env CC=pcc CFLAGS='-O0 -g' PREFIX=/home/you/software-dir \
     bmake all install

Перспектива указания всех опций руками через окружение представляется
мне сомнительным удовольствием.

Переменные окружения это конечно хорошо, но считать это альтернативой
механизму указания опций сборки, мне кажется, нельзя. Я не имею ввиду
опции компилятора, я имею ввиду опциональность поддержки библиотек и
фичей проекта.

You need not remember about configure script, their options and many
other things.

В случае configure, присутствует уровень абстракции ключей,
определяющих ту или иную особенность сборки, от конечных -DFOO=1 и -lbar.

Как в mk-configure можно описать ситуацию, когда проект в зависимости
от пользовательского параметра собирается либо с внешней библиотекой,
либо с внутренней версией этой библиотеки ?

-- 
Rgrds, legion

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Aleksey Cheusov]

 >>> Вопрос: зачем ?
 >> Об этом достаточно подробно написано по ссылкам.

> Читал. Многое спорно, но спорить не буду.

Все на свете субъективно. Критика autobloat естественно тоже.

 >> Гораздо более простую и легкую в использовании систему.

> Run bmake for configuring and building your project and pass to it
> building parameters, e.g.

> env CC=pcc CFLAGS='-O0 -g' PREFIX=/home/you/software-dir \
>      bmake all install

> Перспектива указания всех опций руками через окружение представляется
> мне сомнительным удовольствием.
Разверни "всех опций руками". Каким конкретно опций?

> Переменные окружения это конечно хорошо, но считать это альтернативой
> механизму указания опций сборки, мне кажется, нельзя.
Как раз наоборот.

bmake PREFIX=/usr/pkg MANDIR=/some/where/man

по сути своей ничем не отличется от

./configure --prefix=/usr/pkg --mandir=/some/where/man

Не вижу необходимости плодить сущности без необходимости.
Опции не нужны. На самом деле хватает указания значений переменных
make-а.

Опции же типа ./configure --lalala-includedir=yyy --lalala-libdir=yyy
я считаю, эм... скажем так, весьма сомнительным дизайнерским решением.

> Я не имею ввиду опции компилятора, я имею ввиду опциональность
> поддержки библиотек и фичей проекта.
Опциальность внешних библиотек и фич проекта делает также через указания
значений переменных make-а.

bmake USE_EXTERNAL_LIBX=1 USE_LOCALLIBY=1

Не вижу никаких принципиальных отличий от опций ./configure.

Построение же приложения с или без каких-то библиотек в зависимости от
их наличия -- натуральное зло, об этом знает каждый пакетировщик.

> You need not remember about configure script, their options and many
> other things.

> В случае configure, присутствует уровень абстракции ключей,
> определяющих ту или иную особенность сборки, от конечных -DFOO=1 и -lbar.
На мой взгляд этот уровень не нужен, как не нужен сам ./configure.

> Как в mk-configure можно описать ситуацию, когда проект в зависимости
> от пользовательского параметра собирается либо с внешней библиотекой,
> либо с внутренней версией этой библиотеки ?
Пример1 Makefile:
   ...
   .if USE_FEATURE_X
   CFLAGS+= -DUSE_FEATURE_X
   LDFLAGS+= -lX
   .endif
   ...

Полный пример Makefile (смотри строки, помеченные `!'):
    PROG=		hello_world
    SRCS=		main.c

    MAN=		hello_world.1

    INFILES=	hello_world.1
    INSCRIPTS=	hello_world2

    INTEXTS_SED+=	-e 's,@HELLO_VERSION@,${VERSION},'

    SCRIPTS=	${INSCRIPTS}

!   .if USE_LIBHELLO1
!   .include "../libhello1/linkme.mk"
!   DPLIBS+=	-lhello1
!   CFLAGS+=    -DUSE_LIBHELLO1
!   .endif

    .include "../libhello2/linkme.mk"
    DPLIBS+=	-lhello2

    .include "../Makefile.version"

    .include <mkc.intexts.mk>
    .include <mkc.prog.mk>

-- 
Best regards, Aleksey Cheusov.

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Led]

On Sunday, 12 July 2009 08:53:15 Aleksey Cheusov wrote:
>mk-configure, легковесной простой использовании (да, я знаю, звучит как
>маркетоидное заклинание :-) , уж простите ) альтернативе GNU
>autotools. Ни много, ни мало...

Есть framewerk - легковесный и, в какой-то мере, совместимый с autotools - в 
Сизифе.

-- 
Led

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Aleksey Cheusov]

> On Sunday, 12 July 2009 08:53:15 Aleksey Cheusov wrote:
 >>mk-configure, легковесной простой использовании (да, я знаю, звучит как
 >>маркетоидное заклинание :-) , уж простите ) альтернативе GNU
 >>autotools. Ни много, ни мало...

> Есть framewerk - легковесный и, в какой-то мере, совместимый с autotools - в 
> Сизифе.

Спасибо. Обязательно гляну.

P.S.
На сайте проекта написано "New BSD license".
На странице пакета сизифа - GPLv2.
Кто неправ?

-- 
Best regards, Aleksey Cheusov.

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Led]

On Sunday, 12 July 2009 19:18:02 you wrote:
> > On Sunday, 12 July 2009 08:53:15 Aleksey Cheusov wrote:
>  >>mk-configure, легковесной простой использовании (да, я знаю, звучит как
>  >>маркетоидное заклинание :-) , уж простите ) альтернативе GNU
>  >>autotools. Ни много, ни мало...
> >
> > Есть framewerk - легковесный и, в какой-то мере, совместимый с autotools
> > - в Сизифе.
>
> Спасибо. Обязательно гляну.
>
> P.S.
> На сайте проекта написано "New BSD license".
> На странице пакета сизифа - GPLv2.
> Кто неправ?

Не знаю. Я ориентируюсь на COPYING в пакете. Других указаний на лицензию в 
пакете я не обнаружил.

-- 
Led

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Gleb Kulikov]

В сообщении от [Воскресенье 12 июля 2009 Aleksey Cheusov] написал:

> Если не секрет, в двух словах, чем эта альтернатива лучше scons, например?
>
> > Спасибо.
>
> Если в двух словах, то mk-configure - это логическое продолжение mk
> скриптов в BSD системах. Те, кто видел дерево исходников BSD систем
> (базовые системы, не порты) понимают, о чем я. mk-configure -- развитие
> тех же идей с добавлением ala autoconf функциональности и кое-чего
> другого типа замены @полей@ в .in файлах.
> Но основные идеи следующие:
> - декларативный способ написания Makefile-ов;
> - никакой годогенерации;
> - модули пишутся на bmake и внешних скриптах на POSIX shell + unix tools,

Понятно, спасибо.

На мой взгляд --- архаичный, тупиковый путь. Без обид, просто "машина должна 
работать, а человек думать" (c). 

-- 
      Салют, /GLeb

UIN: 15341920
jabber://gleb@asd.iao.ru
sip://2387245@sipnet.ru			(telephony)
skype://gleb_kulikov.tomsk		(telephony)
sip://20000204@sip.pctel.ru		(telephony)
netmail: 2:5005/78

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Aleksey Cheusov]

 >> Но основные идеи следующие:
 >> - декларативный способ написания Makefile-ов;
 >> - никакой годогенерации;
 >> - модули пишутся на bmake и внешних скриптах на POSIX shell + unix tools,

> Понятно, спасибо.

> На мой взгляд --- архаичный, тупиковый путь. Без обид, просто "машина должна 
> работать, а человек думать" (c). 

А конкретнее? Здоровый консерватизм и разумная критика - это нормально.
Я другого и не ожидал.  Но высказывания типа "машина должна работать, а
человек думать" - это очень некрасивый в приличных местах демагогический
прием, не более.

-- 
Best regards, Aleksey Cheusov.

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 2200 bytes --]

On Sun, Jul 12, 2009 at 06:15:15PM +0300, Aleksey Cheusov wrote:
 AC> Как раз наоборот.
 AC> bmake PREFIX=/usr/pkg MANDIR=/some/where/man
 AC> по сути своей ничем не отличется от
 AC> ./configure --prefix=/usr/pkg --mandir=/some/where/man
 AC> Не вижу необходимости плодить сущности без необходимости.
 AC> Опции не нужны. На самом деле хватает указания значений переменных
 AC> make-а.
 AC> Опции же типа ./configure --lalala-includedir=yyy --lalala-libdir=yyy
 AC> я считаю, эм... скажем так, весьма сомнительным дизайнерским решением.

Простой пример -- libgsm у нас и в некоторых других дистрибутивах
находится в разных includedir. Вопрос -- как решается эта проблема?
autotools позволяют создать configure который автоматически обнаружит эту
библиотеку.

AC> bmake USE_EXTERNAL_LIBX=1 USE_LOCALLIBY=1
AC> Не вижу никаких принципиальных отличий от опций ./configure.
AC> Построение же приложения с или без каких-то библиотек в зависимости от
AC> их наличия -- натуральное зло, об этом знает каждый пакетировщик.

Если делается приложение которое предназначено только для опакечивание --
это так. Увы, не всегда это правило верно. К примеру Asterisk подавляющее
большинство пользователей собирают сами, увы. При этом в нем несколько
десятков модулей, и для некоторых из них нужны сторонние библиотеки. И
многие из этих модулей большинству пользователей не нужны.

AC> На мой взгляд этот уровень не нужен, как не нужен сам ./configure.

Вы пробовали написать приложение, которое бы:
а) пользовалось большим количеством сторонних библиотек;
б) использовало бы некоторые ОС-специфичные функции (к примеру системные
вызовы);
в) собиралось бы под хотя бы 2-3 разных ОС;
г) собиралось бы под несколько аппаратных архитектур (с учетом того что
некоторые типы данных в C на этих архитектурах имеют разный размер в
байтах)

?

Я понимаю зачем может быть полезен некоторый уровень абстракции _над_
autotools. Понимаю что у autotools есть много недостатков. Но не понимаю
зачем нужна система которая позволяет _меньше_ чем autotools.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Aleksey Cheusov]

 AC>> Как раз наоборот.
 AC>> bmake PREFIX=/usr/pkg MANDIR=/some/where/man
 AC>> по сути своей ничем не отличется от
 AC>> ./configure --prefix=/usr/pkg --mandir=/some/where/man
 AC>> Не вижу необходимости плодить сущности без необходимости.
 AC>> Опции не нужны. На самом деле хватает указания значений переменных
 AC>> make-а.
 AC>> Опции же типа ./configure --lalala-includedir=yyy --lalala-libdir=yyy
 AC>> я считаю, эм... скажем так, весьма сомнительным дизайнерским решением.

> Простой пример -- libgsm у нас и в некоторых других дистрибутивах
> находится в разных includedir. Вопрос -- как решается эта проблема?

Я пока не понял, в чем именно заключается проблема. В том, что каталогов
с инклюдами и библиотеками больше одного? Это не проблема.

   LDFLAGS='-Ldir -Ldir2' CPPFLAGS='-Idir1 -Idir2' ./configure
   make

Точно также, только короче на одну команду делается в mk-configure

   LDFLAGS='-Ldir -Ldir2' CPPFLAGS='-Idir1 -Idir2' bmake

Для этого не нужны опции --foo-includedir и --bar-includedir.
Это просто лишний, ничего не добавляющий к функциональности, код (жир).

> autotools позволяют создать configure который автоматически обнаружит эту
> библиотеку.
Проблема в том, что autotool не должен ИСКАТЬ библиотеку с которой
приложение может затребовать. autotools должен ОБНАРУЖИТЬ библиотеку там
и только там, где указал тот, кто приложение собирает.  То есть логика
configure.ac, который работает примерно так "а дайте ка я посмотрю в
каталоге /usr/local/include, может я там найду что-нибудь полезное", в
корне ошибочна и вызывает огромные проблемы при сборке софта на
платформах и хостах, отличных от той, на которой софт разрабатывался.
Именно такую логику я называю "сверхестественным недоинтеллектом".  Это
одна из распространенных ошибок писателей на autotools -- слишком велик
соблазн дернуть за какую-нибудь ручку.
Их слишком много (shell для настройки проекта -- это примерно как
граната у обезьяны в руках).

Во избежание неправильного понимания повторю: configure.ac должен искать
заголовки и библиотеки только в системных каталогах и там, куда
указывают LDFLAGS и CPPFLAGS/CFLAGS. Всё. Заглядывать в
/usr/X11R999/{include,lib}, /usr/local/{include,lib},
/opt/application/{include,lib} -- категорически неправильно.
Собирающий софт человек знает свою платформу и хост гораздо лучше автора
приложения в подавляющем большинстве случаев.

Пример: есть одно старое древнее приложение xsokoban, которое я собирал
для pkgsrc.
http://www.cs.cornell.edu/andru/xsokoban.html
Его чудовищный
configure.ac может наблюдать каждый, скачав тарбол.  Здесь можно видеть,
что мне пришлось с ним сделать (кастрировать, по-другому не назовешь),
чтобы привести его в чувство.
http://pkgsrc-wip.cvs.sourceforge.net/viewvc/pkgsrc-wip/wip/xsokoban/patches/patch-ab?hideattic=0&revision=1.1.1.1&view=markup
Обратить внимание на удаленную секцию про поиски libXpm.

 AC>> bmake USE_EXTERNAL_LIBX=1 USE_LOCALLIBY=1
 AC>> Не вижу никаких принципиальных отличий от опций ./configure.
 AC>> Построение же приложения с или без каких-то библиотек в зависимости от
 AC>> их наличия -- натуральное зло, об этом знает каждый пакетировщик.

> Если делается приложение которое предназначено только для опакечивание --
> это так. Увы, не всегда это правило верно. К примеру Asterisk подавляющее
> большинство пользователей собирают сами, увы. При этом в нем несколько
> десятков модулей, и для некоторых из них нужны сторонние библиотеки. И
> многие из этих модулей большинству пользователей не нужны.
Скажем так. В настоящее время большинство программ поступают к конечному
пользователю в виде уже готового пакета в его родной системе. И среди
программистов и среди админов в последнее время распранен такой подход:
"если программы нет в моей системе, значит это она мне не нужна".
Это говорит о том, расстояние между автором и конечным пользвателем из
года в год увеличивается. Лично я не вижу смысла заботиться о постоянно
уменьшающейся доле пользователей, собирающих софт руками, оправдывая
этой заботой нарушение правильного подхода к настройке и сборке софта,
то есть нарушением нормального дизайна.

 AC>> На мой взгляд этот уровень не нужен, как не нужен сам ./configure.

> Вы пробовали написать приложение, которое бы:
> а) пользовалось большим количеством сторонних библиотек;
Нет. Любой дурак может написать большое приложение. Попробуй написать
маленькое ;-) У меня довольно много проектов в open source, и все они
невелики по объему исходного кода. Много сторонних библиотек я тоже не
использую.

> б) использовало бы некоторые ОС-специфичные функции (к примеру системные
> вызовы);
Да. Например dictd, древняя версия которого есть в репозитории
ALT Linux. Есть и другие.

> в) собиралось бы под хотя бы 2-3 разных ОС;
Естественно. dictd, runawk, paexec...

> г) собиралось бы под несколько аппаратных архитектур (с учетом того что
> некоторые типы данных в C на этих архитектурах имеют разный размер в
> байтах)
Само собой. Примеры те же. Почти все, что мной создано. Я тестирую свой
софт на всех ОС и любом железе, которое мне доступно. В данный момент
это NetBSD, Linux, FreeBSD, Solaris, Darwin.  По железу:
alpha,x86,x86-64. Периодически "проскакивает" другое железо.

Список проектов можно найти на {sourceforge,freshmeat}.net и в
репозитории pkgsrc-wip (там pkgsrc специфичные проекты, например
распределенная, устойчивая к сбоям система пакетной сборки (bulk
builder) для пакетов pkgsrc, примерный аналог вашего hasher-а).

> Я понимаю зачем может быть полезен некоторый уровень абстракции _над_
> autotools. Понимаю что у autotools есть много недостатков. Но не понимаю
> зачем нужна система которая позволяет _меньше_ чем autotools.
Я был бы весьма признателен за список того, чего не хватает в
mk-configure. На данный момент реализованы в полном объеме все
возможности, необходимые в 95% случаев. Напомню, проекту 4 месаца. Менее
критичные вещи я отложил "на потом". Одним словом проект развивается и
не стоит на месте, например, только что сделал я поддержку custom тестов
(a la AC_TRY_COMPILE).

Но начинается любой проект с концепции...  Зачем я сюда и
пришел. Выслушать "фи" насчет идеологии и, приняв к сведению, учесть при
разработке.

-- 
Best regards, Aleksey Cheusov.

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 417 bytes --]

On Sun, Jul 12, 2009 at 11:02:22PM +0300, Aleksey Cheusov wrote:
> Я пока не понял, в чем именно заключается проблема. В том, что каталогов
> с инклюдами и библиотеками больше одного? Это не проблема.
Т.е. autobook Вы даже не читали?  Замечательно.  Покажите
пожалуйста, как "идеологически верно" собирать софт, написанный,
допустим, на C++ с использованием lex, yacc и pkg-config?

-- 
Regards,
Sir Raorn.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Aleksey Cheusov]

 >> Я пока не понял, в чем именно заключается проблема. В том, что каталогов
 >> с инклюдами и библиотеками больше одного? Это не проблема.
> Т.е. autobook Вы даже не читали?  Замечательно.
Каким образом это следует из того, что Денис Смирнов недостаточно ясно
описал, в чем именно заключается проблема, о которой он говорит???

Не надо валять дурака.

> Покажите пожалуйста, как "идеологически верно" собирать софт,
> написанный, допустим, на C++ с использованием lex, yacc и pkg-config?
your_favourite_make all

-- 
Best regards, Aleksey Cheusov.

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 775 bytes --]

On Sun, Jul 12, 2009 at 11:41:20PM +0300, Aleksey Cheusov wrote:
>  >> Я пока не понял, в чем именно заключается проблема. В том, что каталогов
>  >> с инклюдами и библиотеками больше одного? Это не проблема.
> > Т.е. autobook Вы даже не читали?  Замечательно.
> Каким образом это следует из того, что Денис Смирнов недостаточно ясно
> описал, в чем именно заключается проблема, о которой он говорит???
Читайте целиком.

> Не надо валять дурака.
Не надо хамить.

> > Покажите пожалуйста, как "идеологически верно" собирать софт,
> > написанный, допустим, на C++ с использованием lex, yacc и pkg-config?
> your_favourite_make all
Код для mk-confgure покажите пожалуйста.  Реализация компилятора
C++, lex и yacc заранее неизвестны.

-- 
Regards,
Sir Raorn.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Aleksey Cheusov]

 >>  >> Я пока не понял, в чем именно заключается проблема. В том, что каталогов
 >>  >> с инклюдами и библиотеками больше одного? Это не проблема.
 >> > Т.е. autobook Вы даже не читали?  Замечательно.
 >> Каким образом это следует из того, что Денис Смирнов недостаточно ясно
 >> описал, в чем именно заключается проблема, о которой он говорит???
> Читайте целиком.
Надо ясно выражать свои мысли.

 >> Не надо валять дурака.
> Не надо хамить.
Пс :-) Если мне непонятен ход мыслей собеседника я задаю вопросы.  И что
я слышу в ответ? Комментарии от третьего лица по поводу того, что я
читал и что нет. Детский сад.

 >> > Покажите пожалуйста, как "идеологически верно" собирать софт,
 >> > написанный, допустим, на C++ с использованием lex, yacc и pkg-config?
 >> your_favourite_make all
> Код для mk-confgure покажите пожалуйста.  Реализация компилятора
> C++, lex и yacc заранее неизвестны.

Модуль mkc.pkg-config.mk у меня в TODO, его я пока не продумал в
деталях.  Но идеологически верно по идеологии mk-configure это делается
примерно так.

    PROG=             app.cc

    PKG_CONFIG_DEPS=  glib

    .include "mkc.pkg-config.mk"
    .include "mkc.prog.mk"

-- 
Best regards, Aleksey Cheusov.

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Aleksey Cheusov]

>     PROG=             app.cc
>     PKG_CONFIG_DEPS=  glib
>     .include "mkc.pkg-config.mk"
>     .include "mkc.prog.mk"

Пардон. Апчипяталси.

     PROG=             app

     PKG_CONFIG_DEPS=  glib

     .include "mkc.pkg-config.mk"
     .include "mkc.prog.mk"

PROG пишется без .cc
Ну или, если исходников много, так.

     PROG=             app
     SRCS=             file1.cc file2.cc

     PKG_CONFIG_DEPS=  glib

     .include "mkc.pkg-config.mk"
     .include "mkc.prog.mk"

-- 
Best regards, Aleksey Cheusov.

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Alexey Rusakov]

[-- Attachment #1: Type: text/plain, Size: 3872 bytes --]

В Вск, 12/07/2009 в 23:02 +0300, Aleksey Cheusov пишет:
> AC>> Как раз наоборот.
>  AC>> bmake PREFIX=/usr/pkg MANDIR=/some/where/man
>  AC>> по сути своей ничем не отличется от
>  AC>> ./configure --prefix=/usr/pkg --mandir=/some/where/man
>  AC>> Не вижу необходимости плодить сущности без необходимости.
>  AC>> Опции не нужны. На самом деле хватает указания значений переменных
>  AC>> make-а.
>  AC>> Опции же типа ./configure --lalala-includedir=yyy --lalala-libdir=yyy
>  AC>> я считаю, эм... скажем так, весьма сомнительным дизайнерским решением.
> 
> > Простой пример -- libgsm у нас и в некоторых других дистрибутивах
> > находится в разных includedir. Вопрос -- как решается эта проблема?
> 
> Я пока не понял, в чем именно заключается проблема. В том, что каталогов
> с инклюдами и библиотеками больше одного? Это не проблема.
> 
>    LDFLAGS='-Ldir -Ldir2' CPPFLAGS='-Idir1 -Idir2' ./configure
>    make
> 
> Точно также, только короче на одну команду делается в mk-configure
> 
>    LDFLAGS='-Ldir -Ldir2' CPPFLAGS='-Idir1 -Idir2' bmake
> 
> Для этого не нужны опции --foo-includedir и --bar-includedir.
> Это просто лишний, ничего не добавляющий к функциональности, код (жир).
Да видите ли какое дело, если библиотека нормально собрана (и у нас, и в
другом дистрибутиве, то сборка с ней будет выглядеть вот так:
./configure
make

Безо всяких опций. configure найдёт в одном дистрибутиве хедеры в одном
месте, в другом дистрибутиве - в другом, и настроит сборку сообразно. И
всё, никаких опций не нужно вообще. Магию объяснять или сами
догадаетесь?

Ну и ваш заход на тему "любой дурак напишет большую программу" -
извините, это даже не снобизм. Это элементарная далёкость от
промышленного программирования. С такими подходами ваш проект далеко не
уйдёт. Причём вас-то спрашивали о программе с большим числом
подключаемых библиотек, а вы перепутали и ответили про большую
программу. Надеюсь, вы догадываетесь, что это не одно и то же?

Вот вам тест насчёт вашего фреймворка: попробуйте перенести на
mk-configure сборку простой такой библиотеки Gtk+, написанной, судя по
размеру, круглыми дураками. Не забудьте про сборку не только с иксами,
но и с DirectFB. Теоретически она переносима на Win32, но вы хотя бы
линух осильте. Если осилите - возвращайтесь с новой версией
mk-configure, возможно, тогда она уже чего-то будет стоить.

-- 
  Alexey "Ktirf" Rusakov
  GNOME Project
  ALT Linux Team

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 255 bytes --]

On Mon, Jul 13, 2009 at 01:27:03AM +0400, Alexey Rusakov wrote:
> Если осилите - возвращайтесь с новой версией mk-configure,
> возможно, тогда она уже чего-то будет стоить.
Хи-хи.  И будет сравнима по размеру с autotools.

-- 
Regards,
Sir Raorn.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Mikhail Yakshin]

Приветствую,

>> Если не секрет, в двух словах, чем эта альтернатива лучше scons, например?
>> Спасибо.
>
> Если в двух словах, то mk-configure - это логическое продолжение mk
> скриптов в BSD системах. Те, кто видел дерево исходников BSD систем
> (базовые системы, не порты) понимают, о чем я. mk-configure -- развитие
> тех же идей с добавлением ala autoconf функциональности и кое-чего
> другого типа замены @полей@ в .in файлах.
> Но основные идеи следующие:
> - декларативный способ написания Makefile-ов;
> - никакой годогенерации;
> - модули пишутся на bmake и внешних скриптах на POSIX shell + unix tools,
> естественно никто не запретит использовать другие средства.

Алексей, прошу не обижаться, но выскажу все-таки мнение (подозреваю,
далеко не единственное). Поставленные цели, идеи и выбранные подходы,
мягко говоря, странные для существующих реалий. Так уж получается, что
любая "система сборки" в первую очередь должна подстраиваться под то,
что есть и то, чем другие люди занимаются - она сама является
"связующим звеном" в треугольнике между разработчиком - компиляторами
- пользователями.

Perl/Python/Ruby с некоторой натяжкой есть на практических всех
современных Linux/BSD-системах. В принципе, можно считать, что и на
большинстве Windows-систем, где будет собираться свободное ПО, эти
языки тоже есть. Причем работают они одинаково by design на всех
платформах. Для того, чтобы написать на них что-то непортабельное -
надо постараться.

"POSIX shell" фактически нет нигде. С некоторой натяжкой можно
считать, что bash есть везде, но:

1. К POSIX shell он имеет довольно приблизительное отношение.
2. Его поведение сильно зависит от сборки в конкретном месте.
3. Авторы его регулярно ломают и это поведение меняют.

Есть dash, он он тоже ужасен и, к тому же, относительно редок (AFAIR,
до сих пор распространение он получил только в Debian - все остальные
ставят сейчас в /bin/sh все равно bash). Есть ash, но он не менее
ужасен и исчезающие редок.

Под красивым словосочетанием "POSIX shell" вы еще, насколько я вижу из
исходников, понимаете sed, awk, grep и еще кучу всяких утилит. Их
BSD-аналоги, скажем, тоже, как ни странно, плохо совместимы с
GNU-реализациями.

Любой, кто пишет на "POSIX shell" приобретает в удобстве и скорости
написания, но здорово теряет в первую очередь в портабельности. Потеря
портабельности для системы сборки - смерти подобна.

"NetBSD make", если понимать это буквально, еще более исчезающе редок.
С GNU make он пересекается плохо. Если будете пытаться генерировать
Makefiles так, чтобы "работало везде" - и на bmake, и на GNU make -
потеряете массу возможностей. Будете поддерживать только bmake -
сильно осложняете использование своего продукта для
Linux-пользователей. Сейчас по факту оно несовместимо не только с GNU
make, но еще и с FreeBSD/OpenBSD make. Одно это, в общем-то, хоронит
напрочь любую идею, сколько бы хорошей она ни была.

Критика любых make-подобных программ всё так же применима к нему
(полагаю, Вы с ней знакомы, но эту точку зрения не разделяете).

Я сейчас как раз нахожусь на перепутии проектировании некоей
достаточно сложной configure-подобной системы для своего проекта и
анализирую массу информации на эту тему, но к mk-configure, к
сожалению, пока я серьезно рассматривать не могу.

Даже если закрыть глаза на bmake, который предлагается заставлять
ставить всех пользователей, то фатальные, с моей точки зрения,
недостатки существующей системы такие:

* Подмена понятий при разделении хотя бы на 2 шага: интерактивный
(configure, пользователь долго взаимодействует с опциями и подбирает
нужную ему комбинацию) и неинтерактивный (make, пользователь пошел
пить кофе). То, что вы называете "configure" на практике просто
занимается проверками и кое-что строит на лету, а реальная
конфигурация на самом деле передается вместе с запуском bmake.

* Отсутствие возможности (насколько я могу судить - принципиальное)
даже в каком-то далеком будущем организовать пользователю красивый
TUI/GUI для сборки. В cmake и scons оно есть. В waf оно планируется в
виде внешнего конфигуратора.

* Достаточно медленная работа, отсутствие адекватного кэширования
результатов configure. В некотором смысле - это следствие используемых
инструментов - в том числе см. выше про критику всех make.

* Отсутствие хоть сколько-нибудь минимального набора модулей, умеющих
поддерживать распространенные языки, библиотеки и пакеты - насколько я
могу видеть, даже C/С++-программы сейчас собирать проблематично (ни
pkg-config, ни Qt/KDE, ни boost сходу не подключишь).

* Крайне плохо масштабируемая модель синтаксиса входных файлов. Нет и
я не очень представляю как в представленной парадигме реализовать
подпроекты, группы, иерархию опций, зависимости между ними и т.п.

* Отсутствие (насколько я вижу по Вашим ответам - принципиальное)
каких-то средств интеграции в deployment, continuous integration и
unit testing.

* Модель эмбеддинга системы сборки в продукт. Учитывая выбранные
средства программирования - в пределе это дает на порядок более
bloated, чем autotools решение. Извините, но оно уже сейчас занимает
35 килобайт - и при этом не умеет делать практически ничего. Для
сравнения - waf занимает 80 и умеет очень много всего.

-- 
WBR, Mikhail Yakshin

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 583 bytes --]

On Mon, Jul 13, 2009 at 12:00:12AM +0300, Aleksey Cheusov wrote:
> > Код для mk-confgure покажите пожалуйста.  Реализация компилятора
> > C++, lex и yacc заранее неизвестны.
> Модуль mkc.pkg-config.mk у меня в TODO, его я пока не продумал в
> деталях.  Но идеологически верно по идеологии mk-configure это делается
> примерно так.
Усложним задачу.  Три программы и библиотека.  Две программы
должны устанавливаться по $MAKE install, одна должна запускаться
по $MAKE test.  Всё это происходит в одном subdir'е.

Я таких проектов реально видел.

-- 
Regards,
Sir Raorn.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Aleksey Cheusov]

> Да видите ли какое дело, если библиотека нормально собрана (и у нас, и в
> другом дистрибутиве, то сборка с ней будет выглядеть вот так:
> ./configure
> make
Если все зависимые библиотеки лежат в системных каталогах и всякие
pkg-config и подобные находятся в путях, то для сборки с mc-configure
понадобится ровно в два раза меньше команд, тоже безо всяких опций.

   bmake

Не вижу никакой разницы.

> Ну и ваш заход на тему "любой дурак напишет большую программу" -
> извините, это даже не снобизм. Это элементарная далёкость от
> промышленного программирования.
Промышленным программированием с огромными объемами исходного кода я
занимаюсь на работе. ЗДЕСЬ мне ЭТО обсуждать не интересно. Как я уже
сказал, в open source (в свое личное время) я не делаю ОГРОМНЫХ
проектов. Принципиально. И не собираюсь этого делать в ближайшем
будущем. Проект же mk-configure маленький сейчас ( <1500 строк
mk-configure + ~2500 строк mk-files) и маленьким останется в обозримом
будущем. У меня в этом нет никаких сомнений. При этом уже сейчас он
реализует львиную долю функциональности automake и
autoconf. Нереализованные пока возможности займут еще несколько сотен
строк. Степень моей "далекости" мне тоже обсуждать не интересно.

> Вот вам тест насчёт вашего фреймворка: попробуйте перенести на
> mk-configure сборку простой такой библиотеки Gtk+
Началось забрасывание тухлыми яйцами. Ну и манеры вести разговор...
Портировать gtk+ на mk-configure я, естественно, не буду. Просто потому,
что мне это не надо. Это абсолютно бесполезная потеря времени.

Если Вам известны НЕПРЕОДОЛИМЫЕ или хотя весьма СЕРЬЁЗНЫЕ на Ваш взгляд
для сторонних framework-ов трудности в сборке gtk+, будьте так любезны,
огласите весь список. Буду весьма признателен. В этом случае разговор
получится весьма предметным и весьма полезным, а возможно и
поучительным.  Если такого списка нет, то подобные "тесты насчёт вашего
фреймворка" -- не более чем растопыривание пальцев веером. Если такой
список есть, но поделиться им жалко, значит я сюда зря пришел. Хотя нет,
уже не зря, кое на какие мысли меня здесь всеже натолкнули. В такой
"дружелюбной" атмосфере... счастлив, что жив остался. Но нормальной
критики, увы, так и не услышал.

Передергивания на счет "дураков" поскипал -- скучно.

-- 
Best regards, Aleksey Cheusov.

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 1151 bytes --]

On Mon, Jul 13, 2009 at 01:29:10AM +0300, Aleksey Cheusov wrote:
> > Вот вам тест насчёт вашего фреймворка: попробуйте перенести на
> > mk-configure сборку простой такой библиотеки Gtk+
> Началось забрасывание тухлыми яйцами. Ну и манеры вести разговор...
Вы пришли сюда, сказали что использование automake наносит
непоправимый вред окружающей среде и мозгу разработчика и сказали
что mk-configure идеологически верно решает все проблемы.

Когда же Вас спрашивают, в чём будет реальная польза от перевода
проекта Foo с autotools на mk-comfigure, Вы начинаете искать
скрытую угрозу.

> Портировать gtk+ на mk-configure я, естественно, не буду. Просто потому,
> что мне это не надо. Это абсолютно бесполезная потеря времени.
Нет, ну кто бы сомневался.  Тогда из Ваших слов получается, что
mk-configure это такой набор скриптиков для сборки маленьких
проектиков, где время работы autotools-based configure больше или
равно времени собственно сборки этого проектика.

И всё-таки, какая реальная польза от перехода с autotols и GNU
make на какой-то экзотический bmake с ещё более экзотическими
mk-scrips?

-- 
Regards,
Sir Raorn.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Alexey Rusakov]

[-- Attachment #1: Type: text/plain, Size: 6688 bytes --]

В Пнд, 13/07/2009 в 01:29 +0300, Aleksey Cheusov пишет:
> Промышленным программированием с огромными объемами исходного кода я
> занимаюсь на работе. ЗДЕСЬ мне ЭТО обсуждать не интересно.
Вы таки не поверите, но в области свободного ПО очень много
промышленного программирования с огромными объёмами исходного кода :) И
очень большая часть этих объёмов собирается autotools.

>  Как я уже
> сказал, в open source (в свое личное время) я не делаю ОГРОМНЫХ
> проектов. Принципиально. И не собираюсь этого делать в ближайшем
> будущем.
Короче говоря, mk-configure не применима и не планируется к применению в
больших проектах, и является альтернативой autotools только в "малой
форме"? Так бы сразу и сказали.

>  Проект же mk-configure маленький сейчас ( <1500 строк
> mk-configure + ~2500 строк mk-files) и маленьким останется в обозримом
> будущем. У меня в этом нет никаких сомнений. При этом уже сейчас он
> реализует львиную долю функциональности automake и
> autoconf. Нереализованные пока возможности займут еще несколько сотен
> строк.
Извините, но это шапкозакидательство. Уже хотя бы потому, что в отличие
от mk-configure, возможности autotools (при всей кривости этой сборочной
системы) позволяют сопровождать крупные проекты с большим числом
зависимостей, а ваша сборочная система нет.

> > Вот вам тест насчёт вашего фреймворка: попробуйте перенести на
> > mk-configure сборку простой такой библиотеки Gtk+
> Началось забрасывание тухлыми яйцами. Ну и манеры вести разговор...
> Портировать gtk+ на mk-configure я, естественно, не буду. Просто потому,
> что мне это не надо. Это абсолютно бесполезная потеря времени.
Вы неправы. Я же не предлагаю переносить Gtk+ и проталкивать это в
апстрим. Просто Gtk+ - это такой хороший проект, позволяющий оценить
возможности сборочной системы.

> Если Вам известны НЕПРЕОДОЛИМЫЕ или хотя весьма СЕРЬЁЗНЫЕ на Ваш взгляд
> для сторонних framework-ов трудности в сборке gtk+, будьте так любезны,
> огласите весь список. Буду весьма признателен. В этом случае разговор
> получится весьма предметным и весьма полезным, а возможно и
> поучительным.
Там этих трудностей - не для этого письма. Собственно, configure.ac и
Makefile.am от Gtk+ достаточно прозрачно рассказывает практически обо
всех. Не воспринимайте как восклицание "учи матчасть", пожалуйста. Я
серьёзно. Мне просто тоже не очень интересно комментировать содержимое
этих файлов, а для вас, раз уж вы занялись сборочной системой,
разобраться в них будет вот именно что полезно. Там есть целый ряд
интересных и сложных моментов.

Для начала просто попробуйте хорошо, кроссплатформенно, между
несколькими дистрибутивами Linux и BSD, собираться с иксовыми
библиотеками. Это не тривиальная задача, потому что библиотек много
разных, конфигурацию их нужно собирать тоже по-разному, а некоторые из
них ещё и использовать нужно по-разному в зависимости от режима сборки
самой Gtk+. Я понимаю, это не строго поставленная задача, зато она
гораздо ближе к реальному грязному миру. Затем добавьте туда же
возможность выбора бэкенда: X11/DirectFB/Quartz. И учтите между делом,
что API, предоставляемый этими бэкендами, отличается.

>   Если такого списка нет, то подобные "тесты насчёт вашего
> фреймворка" -- не более чем растопыривание пальцев веером. Если такой
> список есть, но поделиться им жалко, значит я сюда зря пришел. Хотя нет,
> уже не зря, кое на какие мысли меня здесь всеже натолкнули. В такой
> "дружелюбной" атмосфере... счастлив, что жив остался. Но нормальной
> критики, увы, так и не услышал.
Грамотного rationale для создания ещё одной сборочной среды от вас здесь
тоже не прозвучало. Только на уровне "мне не понравились autotools,
поэтому я сделал своё". Не обижайтесь, но с чем пришли, то вам тут и
раскритиковали. Вероятно, здесь уровень просто слегка, хм, не ваш :)

-- 
  Alexey "Ktirf" Rusakov
  GNOME Project
  ALT Linux Team

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 6069 bytes --]

On Sun, Jul 12, 2009 at 11:02:22PM +0300, Aleksey Cheusov wrote:

AC> Я пока не понял, в чем именно заключается проблема. В том, что каталогов
AC> с инклюдами и библиотеками больше одного? Это не проблема.
AC>    LDFLAGS='-Ldir -Ldir2' CPPFLAGS='-Idir1 -Idir2' ./configure
AC>    make

Правильно написаный configure на autotols сделает это за меня.

И я, кстати, почти никогда не переопределяю переменные окружения для
./configure.

AC> Для этого не нужны опции --foo-includedir и --bar-includedir.
AC> Это просто лишний, ничего не добавляющий к функциональности, код (жир).

Он _очевиден_. Глядя на эти опции autotools я понимаю что таким образом
добавлена эта библиотека.

Кстати рекомендую посмотреть на spec чего-нибудь вроде mplayer, где
используетяс много with/without. Или на тот же asterisk.

AC> Проблема в том, что autotool не должен ИСКАТЬ библиотеку с которой
AC> приложение может затребовать. autotools должен ОБНАРУЖИТЬ библиотеку там
AC> и только там, где указал тот, кто приложение собирает.  

В случае если собирает пользователь на произвольной системе, а не
мантейнер дистрибутива -- эти слова неправда. Фича autotools как раз в том
что пользователь не должен знать где у него библиотеки.

AC> Пример: есть одно старое древнее приложение xsokoban, которое я собирал
AC> для pkgsrc.
AC> http://www.cs.cornell.edu/andru/xsokoban.html
AC> Его чудовищный
AC> configure.ac может наблюдать каждый, скачав тарбол.  Здесь можно видеть,
AC> что мне пришлось с ним сделать (кастрировать, по-другому не назовешь),
AC> чтобы привести его в чувство.
AC> http://pkgsrc-wip.cvs.sourceforge.net/viewvc/pkgsrc-wip/wip/xsokoban/patches/patch-ab?hideattic=0&revision=1.1.1.1&view=markup
AC> Обратить внимание на удаленную секцию про поиски libXpm.

Да, я согласен, не многие умеют писать нормальые configure-скрипты.

AC> Скажем так. В настоящее время большинство программ поступают к конечному
AC> пользователю в виде уже готового пакета в его родной системе. И среди
AC> программистов и среди админов в последнее время распранен такой подход:
AC> "если программы нет в моей системе, значит это она мне не нужна".
AC> Это говорит о том, расстояние между автором и конечным пользвателем из
AC> года в год увеличивается. Лично я не вижу смысла заботиться о постоянно
AC> уменьшающейся доле пользователей, собирающих софт руками, оправдывая
AC> этой заботой нарушение правильного подхода к настройке и сборке софта,
AC> то есть нарушением нормального дизайна.

Эта самая уменьшающаяся доля пользователей -- является как раз
квалифицироваными пользователями, разработчиками, будущими мантейнерами.

То есть те о ком вы не собираетесь заботиться, для меня лично является
иденственной аудитории, которой я готов многим помочь не выставив
предварительно счет.

>> Вы пробовали написать приложение, которое бы:
>> а) пользовалось большим количеством сторонних библиотек;
AC> Нет. Любой дурак может написать большое приложение. Попробуй написать
AC> маленькое ;-) У меня довольно много проектов в open source, и все они
AC> невелики по объему исходного кода. Много сторонних библиотек я тоже не
AC> использую.

Таким образом, естественно, что вы не учли при разработке своего решения
интересов тем, кому приходится писать большие системы :)

>> б) использовало бы некоторые ОС-специфичные функции (к примеру системные
>> вызовы);
>> в) собиралось бы под хотя бы 2-3 разных ОС;
AC> Естественно. dictd, runawk, paexec...

Как выглядит сборка под разные ОС?
В случае autotools она выглядит так:
./configure
make
make install

AC> Само собой. Примеры те же. Почти все, что мной создано. Я тестирую свой
AC> софт на всех ОС и любом железе, которое мне доступно. В данный момент
AC> это NetBSD, Linux, FreeBSD, Solaris, Darwin.  По железу:
AC> alpha,x86,x86-64. Периодически "проскакивает" другое железо.
AC> Список проектов можно найти на {sourceforge,freshmeat}.net и в
AC> репозитории pkgsrc-wip (там pkgsrc специфичные проекты, например
AC> распределенная, устойчивая к сбоям система пакетной сборки (bulk
AC> builder) для пакетов pkgsrc, примерный аналог вашего hasher-а).
AC> Я был бы весьма признателен за список того, чего не хватает в
AC> mk-configure. На данный момент реализованы в полном объеме все
AC> возможности, необходимые в 95% случаев. Напомню, проекту 4 месаца. Менее
AC> критичные вещи я отложил "на потом". Одним словом проект развивается и
AC> не стоит на месте, например, только что сделал я поддержку custom тестов
AC> (a la AC_TRY_COMPILE).
AC> Но начинается любой проект с концепции...  Зачем я сюда и
AC> пришел. Выслушать "фи" насчет идеологии и, приняв к сведению, учесть при
AC> разработке.

Я как раз к концепции и придираюсь :) Честно скажу, несколько лет назад я
пользовался slackware и считал autotools жутким непонятным монстром
который мне мешал ковыряться в коде. И приложения где были простые
самодельные makefile мне нравились.

Сейчас, когда я много времени трачу на сборку, у меня к любой системе
сборки всегда один вопрос -- чем она _принципиально_ лучше autotools? Если
нет ни одной killer feature -- то ее использование кем-либо буду для себя
считать неудобным. Потому что мне как мантейнеру, пришлось с autotools
сколь-нибудь разобраться. Другая система -- требует отдельного вкуривание
в него, и не всегда понятно с какими перспективами.

Система созданная вами облегчает жизнь разработчику (ее применение требует
меньше эзотерических знаний чем autotools), однако слегка _осложняет_
жизнь мантейнеру (повторюсь - большинство пакетов собирается тремя
командами) и пользователю. А также не очень-то пригодна для больших
проектов.

Ради интереса -- ознкомьтесь с системой сборки в Asterisk, там
действительно все непросто, и даже над autotools еще написали отдеьлную
обвязку для управления зависимостями. Думаю это поставит перед вами ряд
вопросов которые вам будет интересно решить :)

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Afanasov Dmitry]

[-- Attachment #1: Type: text/plain, Size: 409 bytes --]

On Mon, Jul 13, 2009 at 10:05:15AM +0400, Денис Смирнов wrote:
> On Sun, Jul 12, 2009 at 11:02:22PM +0300, Aleksey Cheusov wrote:
> Кстати рекомендую посмотреть на spec чего-нибудь вроде mplayer, где
> используетяс много with/without. Или на тот же asterisk.
небольшое замечание: mplayer не использует ни autotools ни libtool.
configure там - самостоятельный скрипт.
-- 
С уважением
Афанасов Дмитрий

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 437 bytes --]

On Mon, Jul 13, 2009 at 12:26:54PM +0400, Afanasov Dmitry wrote:

AD> небольшое замечание: mplayer не использует ни autotools ни libtool.
AD> configure там - самостоятельный скрипт.

Там хороший пример для чего нужно управление сборкой различными опциями,
при сборке со множеством разных библиотек.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] mk-configure: args vs options

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 924 bytes --]

On Sun, Jul 12, 2009 at 06:15:15PM +0300, Aleksey Cheusov wrote:
[...]
> > Переменные окружения это конечно хорошо, но считать это альтернативой
> > механизму указания опций сборки, мне кажется, нельзя.
> Как раз наоборот.
> 
> bmake PREFIX=/usr/pkg MANDIR=/some/where/man
> 
> по сути своей ничем не отличется от
> 
> ./configure --prefix=/usr/pkg --mandir=/some/where/man
> 
> Не вижу необходимости плодить сущности без необходимости.
> Опции не нужны. На самом деле хватает указания значений переменных
> make-а.

Есть принципиальное отличие: ./configure, сделанный autoconf'ом, отличает
поддерживаемые им параметры ото всех остальных, и диагностирует все
переданные ему неподдерживаемые.  Это позволяет сэкономить кучу времени,
которое в самый неподходящий момент уходит на поиск опечатки.

Система должна помогать разработчику не делать ошибки, которые можно легко
диагностировать.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Aleksey Cheusov]

Ух ты! А я, признаться, уже и не ожидал увидеть здесь хоть какой-то
конструктив...

> 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.

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Aleksey Cheusov]

 >> > Код для mk-confgure покажите пожалуйста.  Реализация компилятора
 >> > C++, lex и yacc заранее неизвестны.
 >> Модуль mkc.pkg-config.mk у меня в TODO, его я пока не продумал в
 >> деталях.  Но идеологически верно по идеологии mk-configure это делается
 >> примерно так.
> Усложним задачу.  Три программы и библиотека.  Две программы
> должны устанавливаться по $MAKE install, одна должна запускаться
> по $MAKE test.  Всё это происходит в одном subdir'е.
Не надо в одном сабдире. В идеологии mk-configure (mk-files на самом
деле) заложено следующее: один каталог -- максимум одна программа или
одна библиотека плюс неограниченное количество всяких скриптов или
просто файлов. После чего все решается очень просто и красиво.  В общем,
я с этой идеологией совершенно согласен. Прежде чем громко возражать,
предлагаю спокойно подумать.  См. проект lmdbg -- реальный проект на
mk-configure.  Мой. Proof of concept. Есть пример попроще в тарболе.

Надо бы это добавить в документацию. Тоже FAQ. Thx!

-- 
Best regards, Aleksey Cheusov.

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Aleksey Cheusov]

 AC>> Я пока не понял, в чем именно заключается проблема. В том, что каталогов
 AC>> с инклюдами и библиотеками больше одного? Это не проблема.
 AC>>    LDFLAGS='-Ldir -Ldir2' CPPFLAGS='-Idir1 -Idir2' ./configure
 AC>>    make

> Правильно написаный configure на autotols сделает это за меня.

> И я, кстати, почти никогда не переопределяю переменные окружения для
> ./configure.

И я не определяю опции при сборки mk-files, если библиотеки и заголовки
разложены в стандартных местах.

 AC>> Для этого не нужны опции --foo-includedir и --bar-includedir.
 AC>> Это просто лишний, ничего не добавляющий к функциональности, код (жир).

> Он _очевиден_. Глядя на эти опции autotools я понимаю что таким образом
> добавлена эта библиотека.
Ага. Создается иллюзия, что --foo-includedir - это только для FOO,
а --bar-includedir - это только для BAR, хотя на самом деле все совсем
не так. Не уж, в сад.

> Кстати рекомендую посмотреть на spec чего-нибудь вроде mplayer, где
> используетяс много with/without. Или на тот же asterisk.
Музхи отдельно, котлеты отдельно. --with/without не имеет никакого
отношения к --foo-{lib,include}dir.

> То есть те о ком вы не собираетесь заботиться, для меня лично является
> иденственной аудитории, которой я готов многим помочь не выставив
> предварительно счет.
Мне не интересны "профессионалы", которым нравится откровенно
кривой дизайн.

 >>> Вы пробовали написать приложение, которое бы:
 >>> а) пользовалось большим количеством сторонних библиотек;
 AC>> Нет. Любой дурак может написать большое приложение. Попробуй написать
 AC>> маленькое ;-) У меня довольно много проектов в open source, и все они
 AC>> невелики по объему исходного кода. Много сторонних библиотек я тоже не
 AC>> использую.

> Таким образом, естественно, что вы не учли при разработке своего решения
> интересов тем, кому приходится писать большие системы :)
Нет. Просто в первую очередл реализовано то, что необходимо было
мнепрямо вот сейчас. Поддержка sml-я мне, например, прямо сейчас не
нужна.

 >>> б) использовало бы некоторые ОС-специфичные функции (к примеру системные
 >>> вызовы);
 >>> в) собиралось бы под хотя бы 2-3 разных ОС;
 AC>> Естественно. dictd, runawk, paexec...

> Как выглядит сборка под разные ОС?
> В случае autotools она выглядит так:
> ./configure
> make
> make install

Точно также.

   bmake
   bmake install-dirs
   bmake install

install-dirs - это побочный эффект немного кривых в этом месте
mk-files. Мне это не очень нравится. Но лучшего решения я не нашел.

> Сейчас, когда я много времени трачу на сборку, у меня к любой системе
> сборки всегда один вопрос -- чем она _принципиально_ лучше autotools?
Я уже много раз отвечал:
- более правильным дизайном
- простотой в изучении и использвании

И я никогда не говорил, что в нем реализовано все на свете.

> Другая система -- требует отдельного вкуривание в него, и не всегда
> понятно с какими перспективами.
Немного времени требуется. В случае с pkgsrc, например, в одном случае
нужно написать в Makefile-е пакета

  GNU_CONFIGURE=yes

а для mk-files (и mk-configure)

  USE_BSD_MAKEFILE=yes

Все остальное сделается и передастся куда следует автоматом.
Если в Алте не так, значит вам есть над чем поработать ;-)

> Ради интереса -- ознкомьтесь с системой сборки в Asterisk,
Угу.

> Думаю это поставит перед вами ряд
> вопросов которые вам будет интересно решить :)
Посмотрим. Записал.

-- 
Best regards, Aleksey Cheusov.

Re: [sisyphus] mk-configure: args vs options

[Aleksey Cheusov]

 >> > Переменные окружения это конечно хорошо, но считать это альтернативой
 >> > механизму указания опций сборки, мне кажется, нельзя.
 >> Как раз наоборот.
 >> 
 >> bmake PREFIX=/usr/pkg MANDIR=/some/where/man
 >> 
 >> по сути своей ничем не отличется от
 >> 
 >> ./configure --prefix=/usr/pkg --mandir=/some/where/man
 >> 
 >> Не вижу необходимости плодить сущности без необходимости.
 >> Опции не нужны. На самом деле хватает указания значений переменных
 >> make-а.

> Есть принципиальное отличие: ./configure, сделанный autoconf'ом, отличает
> поддерживаемые им параметры ото всех остальных, и диагностирует все
> переданные ему неподдерживаемые.

Согласен, минимальное преимущество у опций есть.

-- 
Best regards, Aleksey Cheusov.

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1640 bytes --]

On Sun, Jul 12, 2009 at 08:53:15AM +0300, Aleksey Cheusov wrote:
[...]
> Речь идет об одной из моих последних open source разработок,
> mk-configure, легковесной простой использовании (да, я знаю, звучит как
> маркетоидное заклинание :-) , уж простите ) альтернативе GNU
> autotools. Ни много, ни мало...

Есть ещё одно соображение, не прозвучавшее за прошедшие 2 дня обсуждения.

Не секрет, что многие мантейнеры пакетов нередко используют заклинание
"autoreconf -fisv" для того, чтобы заменить поставляемые в исходниках
сгенерированные файлы на более адекватные.

Основная идея проекта, отличающая его от GNU autotools -- в замене
сгенерированных (предвычисленных "на все случаи жизни") configure+Makefile.in
на декларативные правила, которые будет вычислять каждый пользователь во
время сборки -- в первую очередь должна понравиться разработчикам
операционной системы.

В то же время есть две гораздо более многочисленные группы пользователей,
которым подход mk-configure менее предпочтителен:
- Обычные пользователи, собирающие софт из исходников без изменений.  Как
  уже было сказано, необходимые для сборки проектов, использующих
  mk-configure, новые инструментальные средства _нужных_версий_ -- это
  сейчас проблема.
- Разработчики софта, рассчитывающие, что их проект будет работать на
  любой платформе, которую может поддерживать autotools.  Очевидно, что
  mk-configure как минимум на первых порах сможет поддерживать только
  самые "живые" платформы.

Весьма вероятно, что инертность этих двух групп потушит любое начинание
в этой области, вне зависимости от деталей реализации.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] mk-configure: args vs options

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1065 bytes --]

On Mon, Jul 13, 2009 at 11:28:13PM +0300, Aleksey Cheusov wrote:
> 
>  >> > Переменные окружения это конечно хорошо, но считать это альтернативой
>  >> > механизму указания опций сборки, мне кажется, нельзя.
>  >> Как раз наоборот.
>  >> 
>  >> bmake PREFIX=/usr/pkg MANDIR=/some/where/man
>  >> 
>  >> по сути своей ничем не отличется от
>  >> 
>  >> ./configure --prefix=/usr/pkg --mandir=/some/where/man
>  >> 
>  >> Не вижу необходимости плодить сущности без необходимости.
>  >> Опции не нужны. На самом деле хватает указания значений переменных
>  >> make-а.
> 
> > Есть принципиальное отличие: ./configure, сделанный autoconf'ом, отличает
> > поддерживаемые им параметры ото всех остальных, и диагностирует все
> > переданные ему неподдерживаемые.
> 
> Согласен, минимальное преимущество у опций есть.

Просто опции configure -- это более структурированная сущность, чем
произвольные параметры, которые можно передать make'у.  Возможно, вам стоит
попробовать формализовать тот интерфейс управления, который вы выбрали.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 1155 bytes --]

On Mon, Jul 13, 2009 at 11:20:16PM +0300, Aleksey Cheusov wrote:
> Ага. Создается иллюзия, что --foo-includedir - это только для FOO,
> а --bar-includedir - это только для BAR, хотя на самом деле все совсем
> не так. Не уж, в сад.
Это не иллюзия.  Уж поверьте.

> > То есть те о ком вы не собираетесь заботиться, для меня лично является
> > иденственной аудитории, которой я готов многим помочь не выставив
> > предварительно счет.
> Мне не интересны "профессионалы", которым нравится откровенно
> кривой дизайн.
Мне кажется, или у Вас синдром NIH в тяжёлой форме?

> > Как выглядит сборка под разные ОС?
> > В случае autotools она выглядит так:
> > ./configure
> > make
> > make install
> Точно также.
>    bmake
>    bmake install-dirs
>    bmake install
А тогда как выглядит кросскомпиляция?

> > Сейчас, когда я много времени трачу на сборку, у меня к любой системе
> > сборки всегда один вопрос -- чем она _принципиально_ лучше autotools?
> Я уже много раз отвечал:
> - более правильным дизайном
> - простотой в изучении и использвании
Это Ваше суб'ективное, ничем не подтверджённое мнение.

-- 
Regards,
Sir Raorn.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 329 bytes --]

On Mon, Jul 13, 2009 at 11:03:27PM +0300, Aleksey Cheusov wrote:
> > Усложним задачу.  Три программы и библиотека.  Две программы
> > должны устанавливаться по $MAKE install, одна должна запускаться
> > по $MAKE test.  Всё это происходит в одном subdir'е.
> Не надо в одном сабдире.
Обоснуйте.

-- 
Regards,
Sir Raorn.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Aleksey Cheusov]

 >> Речь идет об одной из моих последних open source разработок,
 >> mk-configure, легковесной простой использовании (да, я знаю, звучит как
 >> маркетоидное заклинание :-) , уж простите ) альтернативе GNU
 >> autotools. Ни много, ни мало...

> Есть ещё одно соображение, не прозвучавшее за прошедшие 2 дня обсуждения.

> Не секрет, что многие мантейнеры пакетов нередко используют заклинание
> "autoreconf -fisv" для того, чтобы заменить поставляемые в исходниках
> сгенерированные файлы на более адекватные.
Да, что, кстати, ломает изначальную идеологию autotools -- предоставить
тарбол, достаточный для сборки абсолютно везде.  Оказывается,
недостаточный, необходимо, оказывается, еще и autotools ставить. Новое
поколение разработчиков считает даже, что за предоставленный в тарболе
готовый configure нужно бить по рукам. Когда я об этом услышал, я был
просто в шоке :-)

Во-первых, это делает подход с кодогенерацией абсолютно неуместным.
Преврати autotools в библиотеку на шеле и пиши декларативно на шеле,
безо всяких m4 и кодогенерации.

Во-вторых, получается такая же ситуация, как и с mk-configure.  Для
mk-configure-based проектов нужно поставить кучу всего, и для
autotools-based -- тоже.

> Основная идея проекта, отличающая его от GNU autotools -- в замене
> сгенерированных (предвычисленных "на все случаи жизни")
> configure+Makefile.in на декларативные правила, которые будет
> вычислять каждый пользователь во время сборки
Угу.

> -- в первую очередь должна понравиться разработчикам операционной
> системы.
Вот, кстати пример. Что делают разработчики BSD систем, когда помещают
сторонний софт, собранный явно не средствами соответствующих bsdmake-ов,
в свои деревья? Правильно. Выбрасывают родные системы сборки к черту и
пишут свои, коротенькие маленькие на родном bsdmake-е. Тот же подход
может быть успешно применим и при разработке больших и долгоиграющих
узкоспециализированных программных комплексов. Заодно решается проблема
кросс-сборки, актуальная для эмбеда.

Вот пример, как GNU grep встроен в NetBSD
http://cvsweb.netbsd.org/bsdweb.cgi/src/gnu/usr.bin/grep/Makefile?only_with_tag=MAIN

> В то же время есть две гораздо более многочисленные группы пользователей,
> которым подход mk-configure менее предпочтителен:
> - Обычные пользователи, собирающие софт из исходников без изменений.  Как
>   уже было сказано, необходимые для сборки проектов, использующих
>   mk-configure, новые инструментальные средства _нужных_версий_ -- это
>   сейчас проблема.
На мне лежит забота об обратной совместимости.  Так что "нужных версий"
можно опустить.  Я бы поставил ударение на "новые инструментальные
средства" и "малораспространенные". Принимаю помощь в пакетировании для
Debian, FreeBSD, Fedora, OpenSuse, Gentoo, Slackware и проч. :-)

> - Разработчики софта, рассчитывающие, что их проект будет работать на
>   любой платформе, которую может поддерживать autotools.  Очевидно, что
>   mk-configure как минимум на первых порах сможет поддерживать только
>   самые "живые" платформы.
Да.

> Весьма вероятно, что инертность этих двух групп потушит любое начинание
> в этой области, вне зависимости от деталей реализации.
Без активной помощи со стороны -- да.

-- 
Best regards, Aleksey Cheusov.

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Led]

On Monday, 13 July 2009 22:56:35 Aleksey Cheusov wrote:
> Ух ты! А я, признаться, уже и не ожидал увидеть здесь хоть какой-то
> конструктив...
>
> > Perl/Python/Ruby с некоторой натяжкой есть на практических всех
> > современных Linux/BSD-системах.
>
> Мысль понял. Почему я не использую ЯП, вместо комбинации POSIX shell +
> unix tools? Ответ простой. Потому что средство подбирается не по
> принципу "крутости", современности или распространенности, а исходя из
> задачи.  Система сборки -- задача простая, и для ее реализации я выбрал
> подходящие на мой взгляд и простые средства.  Ни питон, ни руби, ни перл
> там не нужны. Тем более, что все они довольно громоздкие.

lua? Хотя (как и perl, ruby, не говоря уже о пресмыкающемся уродце) он не 
функциональный (в отличие от make) :(

> С какой стати все должны быть совместимы с каким-то там GNU make? ;-)

Наверное, потому что вы пишете в рассылку, которая "имеет какое-то отношение" 
к GNU/Linux? Вы же (надеюсь) не просто BSD-проповедник/евангелист.фанатик?

>
> Все, что выше я принимаю. Да, с точки зрения маркетинга выбор не очень
> удачный. Инструменты малоузнаваемы. Некоторые особо молодые воспринимают
> в штыки любое незнакомое слово. А если в нем есть BSD, тогда вообще...

Наверное, для этого есть причины? Как думаете? Я не "особо молодой" и ничего 
против конкретно *BSD (как продуктов/ОСей/ядер) не имею, но за десят лет 
выработалась защитная реакция - всё от *BSD воспринимается, в первую очередь, 
настороженно :(

>
> > * Отсутствие возможности (насколько я могу судить - принципиальное)
> > даже в каком-то далеком будущем организовать пользователю красивый
> > TUI/GUI для сборки. В cmake и scons оно есть. В waf оно планируется в
> > виде внешнего конфигуратора.
>
> А зачем ГУИ для сборки??? Мы же в юниксе. Может его еще и во все цвета
> радуги раскрасить? :-)

Ну, cmake размалевали. И молятся это очередное уродство (даже по сравнению с 
autotools) :(

-- 
Led

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Aleksey Cheusov]

 >> > То есть те о ком вы не собираетесь заботиться, для меня лично является
 >> > иденственной аудитории, которой я готов многим помочь не выставив
 >> > предварительно счет.
 >> Мне не интересны "профессионалы", которым нравится откровенно
 >> кривой дизайн.
> Мне кажется, или у Вас синдром NIH в тяжёлой форме?
Нет. Я вполне уважительно отношусь к чужим разработкам, при условии,
естественно, что они мне действительно нравятся. Вне зависимости от
того, откуда они пришли (Linux, BSD, GNU - все равно).

 >> > Как выглядит сборка под разные ОС?
 >> > В случае autotools она выглядит так:
 >> > ./configure
 >> > make
 >> > make install
 >> Точно также.
 >>    bmake
 >>    bmake install-dirs
 >>    bmake install
> А тогда как выглядит кросскомпиляция?
На данный момент так:

  env <other settings> bmake CC=/com/piler LD=/lin/ker <other settings>

или так

  bmake -f settings.mk -f Makefile <other settings>

В общем, есть варианты.

Над улучшением я думаю. Есть предложения?

 >> > Сейчас, когда я много времени трачу на сборку, у меня к любой системе
 >> > сборки всегда один вопрос -- чем она _принципиально_ лучше autotools?
 >> Я уже много раз отвечал:
 >> - более правильным дизайном
 >> - простотой в изучении и использвании
> Это Ваше суб'ективное, ничем не подтверджённое мнение.
Мнение субъективно по определению.  Оно потому и "мнение".

-- 
Best regards, Aleksey Cheusov.

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Aleksey Cheusov]

> On Mon, Jul 13, 2009 at 11:03:27PM +0300, Aleksey Cheusov wrote:
 >> > Усложним задачу.  Три программы и библиотека.  Две программы
 >> > должны устанавливаться по $MAKE install, одна должна запускаться
 >> > по $MAKE test.  Всё это происходит в одном subdir'е.
 >> Не надо в одном сабдире.
> Обоснуйте.
Очень удобно :-D

-- 
Best regards, Aleksey Cheusov.

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 459 bytes --]

On Tue, Jul 14, 2009 at 12:06:54AM +0300, Aleksey Cheusov wrote:
> > On Mon, Jul 13, 2009 at 11:03:27PM +0300, Aleksey Cheusov wrote:
>  >> > Усложним задачу.  Три программы и библиотека.  Две программы
>  >> > должны устанавливаться по $MAKE install, одна должна запускаться
>  >> > по $MAKE test.  Всё это происходит в одном subdir'е.
>  >> Не надо в одном сабдире.
> > Обоснуйте.
> Очень удобно :-D
Очень суб'ективно.

-- 
Regards,
Sir Raorn.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Aleksey Cheusov]

 >> подходящие на мой взгляд и простые средства.  Ни питон, ни руби, ни перл
 >> там не нужны. Тем более, что все они довольно громоздкие.

> lua? Хотя (как и perl, ruby, не говоря уже о пресмыкающемся уродце) он не 
> функциональный (в отличие от make) :(

Да. Лично мне очень нравится Lua. Гораздо приятнее RuPyPe, хотя
практического опыта очень мало.

 >> С какой стати все должны быть совместимы с каким-то там GNU make? ;-)

> Наверное, потому что вы пишете в рассылку, которая "имеет какое-то отношение" 
> к GNU/Linux? Вы же (надеюсь) не просто BSD-проповедник/евангелист.фанатик?

Я атеист. Мне нравятся многие вещи и в NetBSD и в Linux. Вполне успешно
использую обе системы (соответственно дома и на работе).
Есть красиво, мне все равно откуда они пришли.

 >> Все, что выше я принимаю. Да, с точки зрения маркетинга выбор не очень
 >> удачный. Инструменты малоузнаваемы. Некоторые особо молодые воспринимают
 >> в штыки любое незнакомое слово. А если в нем есть BSD, тогда вообще...

> Наверное, для этого есть причины? Как думаете?
Думаю, нет.

> Я не "особо молодой" и ничего 
> против конкретно *BSD (как продуктов/ОСей/ядер) не имею, но за десят лет 
> выработалась защитная реакция - всё от *BSD воспринимается, в первую очередь, 
> настороженно :(
У меня нет таких предрассудков ;-)

 >>
 >> > * Отсутствие возможности (насколько я могу судить - принципиальное)
 >> > даже в каком-то далеком будущем организовать пользователю красивый
 >> > TUI/GUI для сборки. В cmake и scons оно есть. В waf оно планируется в
 >> > виде внешнего конфигуратора.
 >>
 >> А зачем ГУИ для сборки??? Мы же в юниксе. Может его еще и во все цвета
 >> радуги раскрасить? :-)

> Ну, cmake размалевали.
Так я о чем и говорю :-) Хотя с точки зрения маркетинга -- возможно,
очень верный ход.

-- 
Best regards, Aleksey Cheusov.

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Aleksey Cheusov]

 >>  >> > Усложним задачу.  Три программы и библиотека.  Две программы
 >>  >> > должны устанавливаться по $MAKE install, одна должна запускаться
 >>  >> > по $MAKE test.  Всё это происходит в одном subdir'е.
 >>  >> Не надо в одном сабдире.
 >> > Обоснуйте.
 >> Очень удобно :-D
> Очень суб'ективно.

Идеология "один [под]проект -- один [под]каталог" очень сильно упрощает
разработку софта, убирает всевозможные костыли при сборке и упрощает
разработку mk-files для поддержки инфраструктуры.

Вы же любите мелкое дробление программных пакетов. Так здесь практически
то же самое. Принцип "разделяй и властвуй" работает почти везде.

-- 
Best regards, Aleksey Cheusov.

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 2427 bytes --]

On Mon, Jul 13, 2009 at 11:56:45PM +0300, Aleksey Cheusov wrote:
>  >> Речь идет об одной из моих последних open source разработок,
>  >> mk-configure, легковесной простой использовании (да, я знаю, звучит как
>  >> маркетоидное заклинание :-) , уж простите ) альтернативе GNU
>  >> autotools. Ни много, ни мало...
> 
> > Есть ещё одно соображение, не прозвучавшее за прошедшие 2 дня обсуждения.
> 
> > Не секрет, что многие мантейнеры пакетов нередко используют заклинание
> > "autoreconf -fisv" для того, чтобы заменить поставляемые в исходниках
> > сгенерированные файлы на более адекватные.
> Да, что, кстати, ломает изначальную идеологию autotools -- предоставить
> тарбол, достаточный для сборки абсолютно везде.  Оказывается,
> недостаточный, необходимо, оказывается, еще и autotools ставить.

Не совсем так.  С одной стороны, на выходе autotools получается генерат,
достаточный для сборки "абсолютно везде".  С другой стороны, мантейнер 
пакета по разным причинам патчит исходник, он вообще предпочитает собирать
всё из исходников, и тарболлу предпочитает репозиторий исходного кода, в 
котором (по определению) нет файлов, полученных на выходе autotools.
Просто это две разные целевые аудитории.

> Новое
> поколение разработчиков считает даже, что за предоставленный в тарболе
> готовый configure нужно бить по рукам. Когда я об этом услышал, я был
> просто в шоке :-)

Это разные целевые аудитории.  Разработчик проекта старается вместить в
тарболл всё по максимуму, а мейнтейнер пакета старается выкинуть всё то,
что дублирует компоненты его ОС, которая, по его мнению, свежее, лучше, и
т.п.  Есть форма, которая обычно подходит этим двум группам разработчиков --
это репозиторий исходного кода, в котором нет ничего лишнего.

> Во-первых, это делает подход с кодогенерацией абсолютно неуместным.
> Преврати autotools в библиотеку на шеле и пиши декларативно на шеле,
> безо всяких m4 и кодогенерации.

Это сложно вот в каком аспекте: разработчик, запускающий инструменты
autotools и формирующий тарболл, тестирует исходные файлы для некоторых
фиксированных версий autotools.  Обеспечить совместимость с произвольными
версиями autotools _у_пользователя_ задача не стоит в принципе.

Если бы autotools и куча m4-макросов (проекта gnulib и некоторых других)
была одной большой библиотекой, это получился бы совсем другой проект,
с другими целями и задачами.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 237 bytes --]

On Tue, Jul 14, 2009 at 12:06:17AM +0300, Aleksey Cheusov wrote:
> > А тогда как выглядит кросскомпиляция?
>   env <other settings> bmake CC=/com/piler LD=/lin/ker <other settings>
Мне всё ясно, спасибо.

-- 
Regards,
Sir Raorn.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 265 bytes --]

On Tue, Jul 14, 2009 at 12:23:24AM +0300, Aleksey Cheusov wrote:
> Идеология "один [под]проект -- один [под]каталог"
"One egg - one basket".  Вот только зачем навешивать "идеологию"
на искусственное ограничение библиотеки mk-files?

-- 
Regards,
Sir Raorn.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] [JT] Re: mk-configure -- lightweight replacement for GNU autotools

[Pavel N. Solovyov]

On Mon, 13 Jul 2009 22:56:35 +0300
Aleksey Cheusov wrote:

> Ух ты! А я, признаться, уже и не ожидал увидеть здесь хоть какой-то
> конструктив...

	А я (хотя и не всё понял)  с таким удовольствием почитал Вашу с
Михаилом дискуссию. Молодцы!

-- 
	Успехов. Павел.

Re: [sisyphus] [JT] Re: mk-configure -- lightweight replacement for GNU autotools

[Afanasov Dmitry]

[-- Attachment #1: Type: text/plain, Size: 645 bytes --]

On Tue, Jul 14, 2009 at 07:49:43AM +0600, Pavel N. Solovyov wrote:
> On Mon, 13 Jul 2009 22:56:35 +0300
> Aleksey Cheusov wrote:
> 
> > Ух ты! А я, признаться, уже и не ожидал увидеть здесь хоть какой-то
> > конструктив...
> 
> 	А я (хотя и не всё понял)  с таким удовольствием почитал Вашу с
> Михаилом дискуссию. Молодцы!
согласен, мне тоже интересно.

хотя предлагаемое до жути напоминает недавний build system, с которым я
сталкивался.

автор - некий шиллинг, программа cdrecrod, пример: 
http://git.altlinux.org/people/ender/packages/?p=cdrtools.git;a=blob;f=cdrtools/cdda2wav/Makefile

-- 
С уважением
Афанасов Дмитрий

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [sisyphus] [JT] Re: mk-configure -- lightweight replacement for GNU autotools

[Aleksey Cheusov]

 >> > Ух ты! А я, признаться, уже и не ожидал увидеть здесь хоть какой-то
 >> > конструктив...
 >> 
 >> 	А я (хотя и не всё понял)  с таким удовольствием почитал Вашу с
 >> Михаилом дискуссию. Молодцы!
> согласен, мне тоже интересно.
Ну, значит не еще все потеряно.

Приблизительная цитата (по памяти)
"Мы, режиссеры, должны сказать Квентину Тарантоно огромное спасибо.
Он показал нам всем,
что фильмы можно снимать и так тоже"(С)Иван Дыховичный

> хотя предлагаемое до жути напоминает недавний build system, с которым я
> сталкивался.
Да, действительно. Внешне очень похоже.
Надо внимательнее посмотреть. Thnx!

> автор - некий шиллинг, программа cdrecrod, пример: 
> http://git.altlinux.org/people/ender/packages/?p=cdrtools.git;a=blob;f=cdrtools/cdda2wav/Makefile

-- 
Best regards, Aleksey Cheusov.

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Aleksey Cheusov]

 >> Да, что, кстати, ломает изначальную идеологию autotools -- предоставить
 >> тарбол, достаточный для сборки абсолютно везде.  Оказывается,
 >> недостаточный, необходимо, оказывается, еще и autotools ставить.

> Не совсем так.  С одной стороны, на выходе autotools получается генерат,
> достаточный для сборки "абсолютно везде".  С другой стороны, мантейнер 
> пакета по разным причинам патчит исходник,
Внимание вопрос, с какой целью он patch-ит configure.ac?
Правильность определения особенностей системы -- это не вещественная
величина, она логическая. Либо особенности определены правильно либо
неправильно. "А если нет разницы, зачем платить больше?"(С)

> Если бы autotools и куча m4-макросов (проекта gnulib и некоторых других)
> была одной большой библиотекой, это получился бы совсем другой проект,
> с другими целями и задачами.
Цели и задачи как раз абсолютно те же. И реализация получилась бы на
порядок и проще красивее. И точно не было бы такого количества
недовольных "стандартом де факто". И у всех разработчиков была бы
установлена autotools, как сейчас установлены кодогенераторы autotools.

-- 
Best regards, Aleksey Cheusov.

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Afanasov Dmitry]

[-- Attachment #1: Type: text/plain, Size: 629 bytes --]

On Tue, Jul 14, 2009 at 09:37:57AM +0300, Aleksey Cheusov wrote:
> > Не совсем так.  С одной стороны, на выходе autotools получается генерат,
> > достаточный для сборки "абсолютно везде".  С другой стороны, мантейнер 
> > пакета по разным причинам патчит исходник,
> Внимание вопрос, с какой целью он patch-ит configure.ac?
1й случай: выключить вызов autopoint, зазря дергающий cvs. порождается
конструкцией AM_GNU_GETTEXT_VERSION()

2й случай: передача своих параметров при сборке. потребовалось при
отпиливании apr libtool'а от subversin.

3й случай: сборка с системным libltdl.
-- 
С уважением
Афанасов Дмитрий

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Aleksey Cheusov]

> On Tue, Jul 14, 2009 at 09:37:57AM +0300, Aleksey Cheusov wrote:
 >> > Не совсем так.  С одной стороны, на выходе autotools получается генерат,
 >> > достаточный для сборки "абсолютно везде".  С другой стороны, мантейнер 
 >> > пакета по разным причинам патчит исходник,
 >> Внимание вопрос, с какой целью он patch-ит configure.ac?
Вопрос бы риторический, ну да ладно :-)

> 1й случай: выключить вызов autopoint, зазря дергающий cvs. порождается
> конструкцией AM_GNU_GETTEXT_VERSION()
Бага autotools.

> 2й случай: передача своих параметров при сборке. потребовалось при
> отпиливании apr libtool'а от subversin.
Недоделка автора, если иэнтейнер пакета ему помогает, почему нет.

> 3й случай: сборка с системным libltdl.

4й случай: башизмы, который выползают из всех щелей.
Вот, сегодняшний, наисвещайший: 
http://code.google.com/p/google-perftools/issues/detail?id=155

5й случай. Уже описанный мной недавно сверхестественный интеллект.

Вот такие вот слагаемые в частности и объясняют недовольство autotools.
И не только мое.

-- 
Best regards, Aleksey Cheusov.

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Led]

On Tuesday 14 July 2009 21:25:25 Aleksey Cheusov wrote:
> 4й случай: башизмы, который выползают из всех щелей.
> Вот, сегодняшний, наисвещайший:
> http://code.google.com/p/google-perftools/issues/detail?id=155

Это не "башизм", а "сионизм" и/или криворукость или опечатка.

-- 
Led

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Mikhail Yakshin]

Приветствую,

>> 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

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Aleksey Cheusov]

 >>> "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.

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Vitaly Kuznetsov]

Aleksey Cheusov <vle@gmx.net> writes:

>
>> Процесс "configure" вполне может быть итеративный или иметь более, чем
>> одну стадию.
> Моя религия: командный интефейс отдельно, диалоги с пользовалетем --
> отдельно, уровнем выше. Спрашивать "А вы уверены? Точно?" это не
> задача системы сборки.
>

итеративный != интерактивный

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Aleksey Cheusov]

 >>> Процесс "configure" вполне может быть итеративный или иметь более, чем
 >>> одну стадию.
 >> Моя религия: командный интефейс отдельно, диалоги с пользовалетем --
 >> отдельно, уровнем выше. Спрашивать "А вы уверены? Точно?" это не
 >> задача системы сборки.
 >>

> итеративный != интерактивный

А, да. Пардон. Невнимательно прочитал. Но я уже приводил пример, как
итеративность достигается в pkgsrc - набором таргетов, которые
"строятся" строго последовательно: fetch checksum extract patch и т.д.
Кто мешает изобрести таргет check_me_please?

Сбой на любой из стадий фатален и дальше построение пакета не идет.

-- 
Best regards, Aleksey Cheusov.

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Gleb Kulikov]

В сообщении от [Понедельник 13 июля 2009 Aleksey Cheusov] написал:

>  >> Но основные идеи следующие:
>  >> - декларативный способ написания Makefile-ов;
>  >> - никакой годогенерации;
>  >> - модули пишутся на bmake и внешних скриптах на POSIX shell + unix
>  >> tools,
> >
> > Понятно, спасибо.
> >
> > На мой взгляд --- архаичный, тупиковый путь. Без обид, просто "машина
> > должна работать, а человек думать" (c).
>
> А конкретнее? Здоровый консерватизм и разумная критика - это нормально.

1. зачем вообще писать мэйкфайлы? с этим прекрасно справляется сама 
билдсистема

2. при словах "модули (читай: большой и сложной программы) пишутся на позикс 
шелл", меня пробирает неприятный холодок: искать ошибку или поддерживать 
такое, удовольствие ниже среднего. 

> Я другого и не ожидал.  Но высказывания типа "машина должна работать, а
> человек думать" - это очень некрасивый в приличных местах демагогический
> прием, не более.

Я так не думаю. Мощность цифродробилок стандартных машинок вполне достаточна, 
чтобы автоматизировать как можно больше рутинных операций.
Кстати, высказывание принадлежит IBM, и у них вполне получается :)


-- 
      Салют, /GLeb

UIN: 15341920
jabber://gleb@asd.iao.ru
sip://2387245@sipnet.ru			(telephony)
skype://gleb_kulikov.tomsk		(telephony)
sip://20000204@sip.pctel.ru		(telephony)
netmail: 2:5005/78

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Aleksey Cheusov]

С момента предыдущего моего письма на эту тему прошел почти год.
Были люди, для которых предыдущее обсуждение оказалось полезным.
Так что я осмелюсь поднять вопрос еще раз.

Проект активно развивается. За прошедший год сделано очень многое:
обеспечена поддержка многих не mainstream-ных операционных систем
и компиляторов, созданы новые модули, например, для поддержки языка
программирования Lua и pkg-config, переработаны и значительно улучшены
существующие модули и многое-многое другое. Думаю, нет смысла
перечислять все изменения, сделанные за год.
Они подробно описаны в NEWS.txt.

Ограничусь несколькими ссылками.

   Простая презентация, демонстрирующая основные идеи с примерами.
   Представленные примеры - не туториал, это демонстрация лишь
   незначительной части функционала.
   http://mova.org/~cheusov/pub/mk-configure/mkc-presentation.pdf

   Сайт проекта.
   http://sf.net/projects/mk-configure/

   Зеркало. Там есть NEWS.txt.
   http://mova.org/~cheusov/pub/mk-configure/

В AltLinux есть пакет bmake. Он старый, но его должно быть достаточно
для тех, кто хочет покрутить mk-configure в руках. На данный момент это
единственная зависимость mk-c. Пакет mk-configure тоже есть, но он
очень тухлый, у меня не получается достучаться до ментейнера :-(
Его брать не стоит.

-- 
Best regards, Aleksey Cheusov.

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[REAL]

Aleksey Cheusov пишет:
> В AltLinux есть пакет bmake. Он старый, но его должно быть достаточно

Только у меня его так и не удалось завести. В hsh-shell работает 
нормально, но при попытке сборки из gear жёстко тупит.

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[REAL]

Aleksey Cheusov пишет:
> Я не специалист в хешере, но по логам сборки bmake-а что-нибудь сказал
> бы. "Жестко тупит" мне ни о чем не говорит.

Кусок лога:

+ bmake all 

getopt(BD:I:J:NST:V:WXd:ef:ij:km:nqrst) -> 119 (w) 

usage: bmake [-BeikNnqrstWX] [-D variable] [-d flags] [-f makefile] 

             [-I directory] [-J private] [-j max_jobs] [-m directory] 
[-T file]
             [-V variable] [variable=value] [target ...] 

error: Bad exit status from /usr/src/tmp/rpm-tmp.73981 (%build)

Хотите поупражняться? Пожалуйте:

http://git.altlinux.org/people/real/packages/paexec.git

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Aleksey Cheusov]

> Aleksey Cheusov пишет:
 >> В AltLinux есть пакет bmake. Он старый, но его должно быть достаточно

> Только у меня его так и не удалось завести. В hsh-shell работает
> нормально, но при попытке сборки из gear жёстко тупит.

Я не специалист в хешере, но по логам сборки bmake-а что-нибудь сказал
бы. "Жестко тупит" мне ни о чем не говорит.

-- 
Best regards, Aleksey Cheusov.

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[REAL]

Aleksey Cheusov пишет:
> - paexec - это хорошая погремушка, но она не mk-configure :-)

Сейчас речь про bmake.

> - paexec требует для сборки pkgsrc-mk-files, я этого пакета в спеках не
>   обнаружил. В AltLinux он есть.

Попробуем, посмотрим...

> - paexec требует для сборки библиотеку libmaa, которой нет в AltLinux-е.

Она есть в Сизифе.

> - Ошибка, которая выше, у меня не воспризвонится. bmake и pkgsrc-mk-files
>   собраны из пакетов AltLinux-а.

Значит, Вы собирали не из gear, поэтому и не воспроизводится.

> - А! Кажется я догадался! У вас при сборке, видимо, устанавливается
>   переменная MAKEFLAGS. И в ней прописан непонятный bmake-у флаг -w.
>   Сделайте ей unset.

Да, тут рядом письмо как раз об этом.

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Slava Semushin]

15 июня 2010 г. 12:29 пользователь REAL <root@mmedia2.kemsu.ru> написал:
> + bmake all
> getopt(BD:I:J:NST:V:WXd:ef:ij:km:nqrst) -> 119 (w)
> usage: bmake [-BeikNnqrstWX] [-D variable] [-d flags] [-f makefile]
>            [-I directory] [-J private] [-j max_jobs] [-m directory] [-T
> file]
>            [-V variable] [variable=value] [target ...]
> error: Bad exit status from /usr/src/tmp/rpm-tmp.73981 (%build)

http://lists.altlinux.org/pipermail/devel/2007-March/136374.html


-- 
Slava Semushin

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Aleksey Cheusov]

> Aleksey Cheusov пишет:
 >> Я не специалист в хешере, но по логам сборки bmake-а что-нибудь сказал
 >> бы. "Жестко тупит" мне ни о чем не говорит.

> Кусок лога:

> + bmake all 

> getopt(BD:I:J:NST:V:WXd:ef:ij:km:nqrst) -> 119 (w) 

> usage: bmake [-BeikNnqrstWX] [-D variable] [-d flags] [-f makefile] 

>             [-I directory] [-J private] [-j max_jobs] [-m directory]
> [-T file]
>             [-V variable] [variable=value] [target ...] 

> error: Bad exit status from /usr/src/tmp/rpm-tmp.73981 (%build)

> Хотите поупражняться? Пожалуйте:

Да не то, чтобы очень, у меня хватает мест, где можно поупражняться. Но
замечаниями могу поделиться.
- paexec - это хорошая погремушка, но она не mk-configure :-)
- paexec требует для сборки pkgsrc-mk-files, я этого пакета в спеках не
  обнаружил. В AltLinux он есть.
- paexec требует для сборки библиотеку libmaa, которой нет в AltLinux-е.
  Нужно пакетировать. Она часть dictd. То, что нужно для сборки paexec,
  документировано.
- Ошибка, которая выше, у меня не воспризвонится. bmake и pkgsrc-mk-files
  собраны из пакетов AltLinux-а.
  ALT Linux Office Server (20080609)
- А! Кажется я догадался! У вас при сборке, видимо, устанавливается
  переменная MAKEFLAGS. И в ней прописан непонятный bmake-у флаг -w.
  Сделайте ей unset.

-- 
Best regards, Aleksey Cheusov.

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[REAL]

Aleksey Cheusov пишет:
> - А! Кажется я догадался! У вас при сборке, видимо, устанавливается
>   переменная MAKEFLAGS. И в ней прописан непонятный bmake-у флаг -w.
>   Сделайте ей unset.

А ещё надо устанавливать BINOWN, BINGRP, MANOWN, MANGRP. В общем, не в 
восторге я от таких инстрУментов.

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [sisyphus] mk-configure -- lightweight replacement for GNU autotools

[Aleksey Cheusov]

> Aleksey Cheusov пишет:
 >> - А! Кажется я догадался! У вас при сборке, видимо, устанавливается
 >>   переменная MAKEFLAGS. И в ней прописан непонятный bmake-у флаг -w.
 >>   Сделайте ей unset.

> А ещё надо устанавливать BINOWN, BINGRP, MANOWN, MANGRP. В общем, не в
> восторге я от таких инстрУментов.

Эта критика не в мой адрес. Это проблемы mk-files, успешно исправленные
в mk-configure. Да и выставить 4 переменные - не такой тяжкий труд
по сравнению с закатом солнца вручную.
А у mk-files недостатков много, я знаю ;-)

Что касается инстрУментов: bmake, pkgsrc-mk-files и mk-configure -- это
три разных инструмента.

-- 
Best regards, Aleksey Cheusov.