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

Aleksey Cheusov vle на gmx.net
Вс Июл 12 19:15:15 MSD 2009


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

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

Все на свете субъективно. Критика 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.


Подробная информация о списке рассылки Sisyphus