Re: make contest
Aleksey Cheusov -> debian-russian@lists.debian.org @ Fri, 03 Oct 2008 16:01:20 +0300:
DEO>>> и проблема автогена депендсов везде решена?
>> Это наиболее тяжкая часть, но по сравнению с make оно гораздо лучше во
>> всех. Подробности я не смотрел, и подозреваю, что полностью корректного
>> решения нет ни в одном. Но во всяком случае грабли, по которым ходит
>> make, там убраны.
AC> Не из упрямства, а справедливости ради, не ГРАБЛИ, а маленькие грабельки ;-)
AC> Эти грабельки совсем не мешают жить, нужно всего лишь уметь готовить make ;-)
AC> Позволю себе представить собственно "классический" вариант решения
AC> проблемы, в очередной раз становясь на защиту классического make-а
AC> и, в особенности, одной его реализации ;-)
AC> Для удобства чтения разделил секции строкой =========================.
AC> ===========================================================================
AC> 0 dictd_bsd_make>bmake dict
AC> ... <построили в общем>
AC> ===========================================================================
AC> 0 dictd_bsd_make>touch dict/dict.h
AC> ===========================================================================
AC> 0 dictd_bsd_make>bmake dict TRG='depend all'
AC> SUBDIR="libmaa dict_common dict" /usr/pkg/bin/bmake depend all
AC> depend ===> libmaa
AC> depend ===> dict_common
AC> depend ===> dict
AC> all ===> libmaa
AC> all ===> dict_common
AC> all ===> dict
AC> gcc -O2 -Werror -c dict.c
AC> gcc -L../dict_common -L../libmaa -o dict dict.o -ldict_common -lmaa
Ну, начнем с того, что это уже ошибка. Потому что файл dict/dict.h не
менялся. Нет, я в курсе, что гнутый мейк в этом месте ничем не
лучше. А вот makepp - лучше.
AC> ===========================================================================
AC> 0 dictd_bsd_make>bmake dict TRG='depend all'
AC> SUBDIR="libmaa dict_common dict" /usr/pkg/bin/bmake depend all
AC> depend ===> libmaa
AC> depend ===> dict_common
AC> depend ===> dict
AC> all ===> libmaa
AC> all ===> dict_common
AC> all ===> dict
AC> ===========================================================================
AC> 0 dictd_bsd_make>cat Makefile
AC> .if !defined(SUBDIR)
AC> SUBDIR+= libmaa
AC> SUBDIR+= dict_common
AC> SUBDIR+= .WAIT
AC> SUBDIR+= dict
AC> SUBDIR+= dictd
AC> SUBDIR+= dictfmt
AC> SUBDIR+= dictzip
AC> .endif
AC> TRG?= all
AC> .PHONY: dict dictd dictfmt dictzip
AC> dict dictd dictfmt dictzip:
AC> SUBDIR="libmaa dict_common $@" $(MAKE) $(TRG)
AC> .include <bsd.subdir.mk>
AC> ===========================================================================
AC> 0 dictd_bsd_make>cat dict/dict.c
AC> #include "dict.h"
AC> int main ()
AC> {
AC> return 0;
AC> }
AC> ===========================================================================
AC> 0 dictd_bsd_make>cat dict/Makefile
AC> PROG= dict
AC> .include "../dict_common/Makefile.inc"
AC> .include "../libmaa/Makefile.inc"
AC> .include <bsd.prog.mk>
AC> ===========================================================================
AC> ОРстальные файлы каркасного проекта я уже показывал рядом.
AC> Для тех, кто дочитал до этого места. Дальше думаю понятно, что
AC> делать. Пилите ваше IDE, то есть ваш Linux/UNIX до состояния, в
AC> котором она IDE пригодна к использованию. Например man
AC> bash/zsh/ksh/tcsh/mksh на предмет алиасов, функций и программируемых
AC> автодополнений.
Это несложно. Но непонятно, почему аккуратное построение зависимостей,
без которого корректная сборка невозможна, не делается _инструментом для
корректной сборки_ по умолчанию, а делается только за отдельную
просьбу. И надо специально настраивать среду, чтобы добиться от него
той работы, для которой он, собственно, предназначен.
Сильно, кстати, подозреваю, что кросс-зависимость между проектами твоя
конструкция отработает некорректно. Нет, я понимаю, что с твоей точки
зрения кросс-зависимость надо лечить гильотиной. В 90% случаев ты даже
будешь прав. Но не более...
AC> Ктоме того, в BSD make по умолчанию до основного make-а всегда
AC> включается (include-ится) mk.conf. В нем можно писать всяческие
AC> приватные goodies, с помощью которых жизнь станет намного легче. У
AC> меня там, к примеру, прописан такой таргет.
AC> .PHONY : list-vars
AC> list-vars :
AC> .for v in ${VARS}
AC> @printf "%s=%s\n" "${v}" "${${v}}"
AC> .endfor
AC> Работает так
AC> 0 pdnsd>bmake list-vars VARS='PKGNAME MAINTAINER'
AC> PKGNAME=pdnsd-1.2.7
AC> MAINTAINER=schwarz@NetBSD.org
AC> 0 pdnsd>
AC> mk.conf - это собственно продолжение идеи о том, что ОС UNIX - это и
AC> есть ваша IDE. BSD make эту идею продолжает и развивает.
AC> mk.conf - ваши "умолчания" и спец функции по аналогии с .myshrc.
AC> _Сильно_ облегчает жизнь именно на этапе разработки.
AC> Туда можно прописать очень сложные вещи, в том числе настройки для
AC> различных проектов.
Ага, а потом у другого разработчика проект не собирается... Потому что
у него эти сложные вещи написаны по-другому, а называются, так случайно
получилось, точно так же :-) И, натурально, используются в других
проектах, поэтому идея заменить их на твои даже не рассматривается. В
лучшем случае - они у него вообще не написаны, а ты в отпуске, и на
письма не отвечаешь. Или отвечаешь, как сейчас в рассылку - общими
идеологическими рассуждениями, причем с развесистыми примерами, лишь бы
не на заданный вопрос.
AC> Собственно того же самого можно добиться и с GNU make, прописывая _явно_
AC> в каждый Makefile проекта что-нибудь вроде
AC> sinclude /etc/gnu_mk.conf
Можно. Но мне обычно надо инклудить конфиг не из /etc... Мне
требуется, как водится, даже не промежуточный, а боковой результат - и
не из текущей директории, и не общесистемный, а общепроектный.
Насколько я понимаю, это делается абсолютно одинаковыми усилиями в обоих
мейках.
--
Artem Chuprina
RFC2822: <ran{}ran.pp.ru> Jabber: ran@jabber.ran.pp.ru
Intel - тоже Сильмарилл. Только сделанный не так...
Reply to: