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> [EMAIL PROTECTED] 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: [EMAIL PROTECTED] Intel - тоже Сильмарилл. Только сделанный не так... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]