>> Я думаю, вы выдаете желаемое за действительное. Я лично считаю вызов >> внешнего шела гораздо более правильной практикой по сравнению с >> изобретением собственных недоязыков программирования. >> >> А вызвать внешний shell ничем не хуже, чем дернуть встроенный >> интерпретатор java script, lua, scheme, lisp etc. >> Но и то и другое лучше изобретения велосипедов.
> В чем смысл изучения синтаксиса кучи специфичных языков make, bash, sed, awk, > grep, etc., Э-э-э-э... Ну-у-у-у-у. Даже не знаю, что и сказать. Каждое средство хорошо на своем месте. > если то же самое можно делать на хорошо известном и используемом > ежедневно языке программирования общего назначения Вот именно, что нельзя. > (и не таскать кучу зависимостей при этом)? Нежелательные зависимости - это как раз таки многотонные интерпретаторы perl/python/tcl/ruby с многотонными же библиотеками. BSD make/GNU make зависимостями не считаются :) > Под линуксом один make, под бсд-клонами, как выясняется, другой, Вообще-то, это общеизвестно. Ну, по крайне мере за пределами Линукса все знают о разнообразии make-ов ;) > в винде nmake offtopic >, да еще синтаксис внешних утилит разный - получается, что задача >написать переносимый мэйкфайл требует огромных трудозатрат. При всем моем уважении к стандартам, не советую ставить задачу написания портабельных Makefile-в. Ни к чему хорошему для вашего продукта это не принесет, и никому это не нужно. Уж слишком убог "стандартный" make. В настоящее время стандартами де факто являются GNU make и BSD make. Мне гораздо больше нравится BSD make и особенно его MK скрипты. С ужасом вспоминаю GNU-make-овский eval/call и прочие его "прелести". Сейчас в моду входит cmake и прочее. Переходить ли на них - может быть, но очень осторожно, взвесив, чего же именно хочется от make-а. И уж точно не стоит бросаться в крайности, не разобравшись. -- Best regards, Aleksey Cheusov. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
