Не обязательно программ и не обязательно в бинарники :-/

Тем не менее, это его основное назначение ;-)

Задняя совместимость.

Расскажите лучше об изменениях и обратной совместимости. Где могут возникнуть проблемы с новым make?

Пора убить это поделие... scons форева!!!

M$ Visual C++ forever!

>M$ Visual C++ forever!

а он тоже make использует, не GNU конечно, но тем не менее

> M$ Visual C++ forever!

Оно же под венду. А вендой пользуются только конченные лузеры!

> Тем не менее, это его основное назначение ;-)

Помню, я им свой латеховые курсаки/лабы/... собирал :-)

Четыре года ничего не менять в make - это сильно :)

>Четыре года ничего не менять в make - это сильно :)

а по моему это показатель стабильности

> Пора убить это поделие... scons форева!!!

Насколько я разобрался с scons (а я питон неплохо понимаю) - он заточен именно под сборку C/C++ програм. Make же можно много для чего приспособить довольно просто. Это как сравнивать cpp и m4 :-)

>Насколько я разобрался с scons (а я питон неплохо понимаю) - он заточен именно под сборку C/C++ програм. Make же можно много для чего приспособить довольно просто. Это как сравнивать cpp и m4 :-)

Нет (C) :) Сконс прекрасно собирает c/c++/фортран/паскаль/тех-латех и вообще всё, для чего определён соотв. билдер. А билдеров таких -- море, пожалуй, "знающих" особенности всех мыслемых на сегодня компиляторов. И прекрасно "затачивается" под сборку, чего душе угодно -- только (если делать по-джентельменски, разумеется), то не в стиле мэйка, с написанием простыни правил в makefile'е, а написанием специализированного билдера. Но есои сильно хочется -- ради бога, можно сделать это и в стиле мэйка.

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

Почему в новости не сказано, что обновился GNU make? make'ов всяких много.

Там ссылка в "подробностях" куда-то в недра гну.орг ведет

Уважаемый ананимус! Можно с вами более подробно поговорить про scons? Дайте, пожалуйста, свои координаты на igorg [хетвероногий друг] convergin.com

> короче, на *сегодня* -- scons действительно, самый мощный и легкий в использовании инструмент.

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

Уважаемый ананимус вдохновляет меня опять пристально посмотреть на scons. Другое дело, что мне сейчас собирать почти нечего. Если только наборы конфигов иногда. Но с этим и make отлично справляется.

>Не обязательно программ и не обязательно в бинарники :-/

ага, например dvd -> xvid (ripmake -> Makefile -> make) :)

> включаются ли в scons сторонние билдеры (как модули или ещё как)

Естественно. =)

> и насколько просто/удобно их писать

Если есть опыт общения с Питоном, то очень просто/удобно.

Ещё scons умеет:

- автоматически определять зависимости

- строить глобальное дерево зависимостей (кто пользовался autotools'ами, тот знает :P)

- кэшировать (чтоб лишний раз не пересобирать одно и то же)

- определять, изменился ли файл по его контрольной сумме (md5), а не по дате, как make

- автоматически добывать исходники из CVS, SVN и др. репозиториев

>> включаются ли в scons сторонние билдеры (как модули или ещё как) > Естественно. =)

Пойду на офсайт, гляну - может пригодится.

>> и насколько просто/удобно их писать > Если есть опыт общения с Питоном, то очень просто/удобно.

А вот желательно знать насколько это просто для не знакомых с Питоном. Это всё-таки ЯВУ. А у make - просто синтакси, дотошно описанный в документаций.

> Ещё scons умеет: - автоматически определять зависимости - строить глобальное дерево зависимостей (кто пользовался autotools'ами, тот знает :P) - кэшировать (чтоб лишний раз не пересобирать одно и то же) - определять, изменился ли файл по его контрольной сумме (md5), а не по дате, как make - автоматически добывать исходники из CVS, SVN и др. репозиториев

Вот от чтения исходников всех этих фич и возникло ощущение, что заточка под Цэ. И что подпиливать под тот-же тех (даже с учетом наследования) может быть геморно. В защиту scons стойт сказать, что он работает :-). Был в небольшом шоке, когда в тарболе одной программы вместо auto обвязки или Makefile-в обнаружил копию scons. Но ничего так - собралось даже в rpm без проблем.

> Пора убить это поделие... scons форева!!!

Убить пора схему autoconf+automake.

Есть ситуации, когда make позволяет очень коротко и ясно описать путь решения задачи.

SCons же действительно выглядит довольно привлекательно для сборки программных пакетов.

30 лет писали и до сих пор ошибки исправляют. такая тулза пишется за 2 дня в первом приближении.

Write it. Good luck :)

> Вот от чтения исходников всех этих фич и возникло ощущение, что заточка под Цэ.

Отнюдь не так, уважаемый. Ж) Scons - весьма универсальная тулза.
Прямо из коробки он умеет:
386asm
aixc++
aixcc
aixf77
aixlink
ar
as
bcc32
c++
cc
cvf
dmd
dvipdf
dvips
f77
f90
f95
fortran
g++
g77
gas
gcc
gnulink
gs
hpc++
hpcc
hplink
icc
icl
ifl
ifort
ilink
ilink32
jar
javac
javah
latex
lex
link
linkloc
m4
masm
midl
mingw
mslib
mslink
msvc
msvs
nasm
pdflatex
pdftex
qt
rmic
sgiar
sgic++
sgicc
sgilink
sunar
sunc++
suncc
sunlink
swig
tar
tex
tlib
yacc
zip.

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

> Отнюдь не так, уважаемый. Ж) Scons - весьма универсальная тулза. Прямо из коробки он умеет: ...

Я знаю. Именно это и имел ввиду под кривой фразой "заточка под Цэ". Из общей картины выделяются лишь (pdf)(la)TeX, tar и zip. Я этот список смотрел, но в то время мне это не надо было (я вообще-то софт не пишу). Мне надо было именно любые программы (в т.ч. числе гуйные, но никак не языки) интегрировать. И они частенько менялись. И времени полностью понять scons не было. А сейчас и не нужно. Остались лишь простые случай, где make справляется на раз два три.

> Write it. Good luck :)

Ну все горазды сказать "write it". Хотя, с другой стороны все горазды сказать то, что я сказал :)

Чего там принципиально сложного? Распарсить дерево зависимостей? Синтаксис тривиален. -j N? Тут тоже все просто, когда есть дерево. Всякие переменные - вообще молчу. А на всякие static rules'ы, VPATH'ы (которые везде по-разному работает до сих пор) 30 лет (или сколько там?) должно было хватить даже кенгуру.

И вообще. Сила make в том, что он прост и везде работает. А то, что туда воротят всякие фичи, которые потом десятилетиями фиксятся, которые потом везде по-разному работают - дискредетируют make. Это одна из причин, почему все переходят на SCons и т.д.

> И вообще. Сила make в том, что он прост и везде работает.

Не так уж прост на самом деле. Поверьте.

> А то, что туда воротят всякие фичи, которые потом десятилетиями фиксятся, которые потом везде по-разному работают - дискредетируют make.

Посмотрите список недавних фич. Или хотя бы Changelog нового релиза. Они за фичами не гонятся, и это правильно. Что, по вашему лучше ещё лет десять фиксить баги в scons (А там их наверняка есть)?

> Это одна из причин, почему все переходят на SCons и т.д.

Неужели? Что-то не замечал. Лет за шесть встретил только одну программу, собирающуюся scons (обираю пакеты регулярно). Собиралась она без проблем, но и программы с нормальной auto-обвязкой тоже собираются без проблем.

Make - это хорошо, а еще есть Ant (http://ant.apache.org) и Maven (http://maven.apache.org) - рекомендую хотя бы попробовать, чтобы было из чего выбирать :)

And и Maven - это, блин, для особых фанатов и трудоголиков. =) Ибо писать развесистый XML руками - то ещё занятьице. %^/

s/And/Ant/ ^)

> Ant и Maven - это, блин, для особых фанатов и трудоголиков. =) Ибо писать развесистый XML руками - то ещё занятьице. %^/

Согласен, но современные IDE пишут такой XML сами, руками можно только чуть-чуть под себя затачивать. В крайнем случае спасает банальный копи-пэйст :) Ant удобен почти всегда, преимущества Maven начинаются сказываться в больших проектах.

> современные IDE пишут такой XML сами

Тот же маразм, что и autoconf+automake. Они бы лучше сами собирали пакет. А то вон пока autoconf сочинит configure да пока configure сообразит Makefile, тот же scons уже всё соберёт.

народ, дискуссия пошла по второму кругу, смотрите летнюю перепалку под тем же топиком. а что до ant & etc., так никто и не пытается преуменьшить их полезность, вот только реальная проверка для проектов средней и большой размерности, показывает преимущество сконс (о майк'е -- просто помолчим, любимая фишка мэйка -- ошибочное решение о пересборке/непересборке модуля, для больших проектов -- вообще не смешно).

PS: сборочный скрипт в xml -- это или с очень забористой травы, или ориентация на (почти) исключительно автогенерацию, со всеми вытекающими из слова *авто* обстоятельствами и (возможными) ограничениями.

PPS: сборочный скрипт сконса -- только с одной стороны есть "инструкция по сборке", с другой -- это практически неограниченная по возможностям, полноценная, программа. При желании, естественно. С вытекающими возможностями творить... что угодно. При желании :)

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

PPPS: bksys.

>любимая фишка мэйка -- ошибочное решение о пересборке/непересборке
>модуля, для больших проектов -- вообще не смешно

За десять лет пользования GNU make ни разу подобного не было. Каждый раз достаточно было разобраться, и обнаруживалась ошибка в правилах.

А вообще то угробище, которое генерирует autoconf не является нормальным мейкфайлом. Если толково пользоваться возможностями GNU Make, то размер файлов сильно уменьшается, а понятность существенно повышается. Чтобы не быть голословным, один мой проект (167 тысяч строк, состоит из 9 библиотек, 3 приложений, 8 утилит из которых 3 собираются и используются прямо во время сборки, 9 тестовых простеньких приложений) собирается из мейк файлов общим обьемом 590 строк (20к) при этом ядро системы сборки занимает всего 10к, остальное - файлики вида (один из самых сложных файлов):

LIBS += syck
DIR.INCLUDE.CXX += ;include/syck
DESCRIPTION.syck = Scripters' YAML Cobble-Yourself-a-Parser Kit
TARGETS.syck = syck$L
SRC.syck$L = $(wildcard libs/syck/*.c)
CFLAGS.syck = -w

> LIBS += syck

А откуда и зачем в Вашем проекте Syck? 8)

SCons реально крут.

Отлично работает на Win32/Linux. А мегапереносимость autotolls это вообще шутка юмора, под самой распространённой платформой (Win32) работает через пень-колоду.

Из своего опыта использования SCons-a (~1.5 года) могу сказать следующее:

1. Питон таки знать надо. Хотя бы на уровне туториала, для того чтобы дебажить скрипты сборки.

2. Свой билдер написать более чем реально. Для этого конечно придётся читать доку, но если писать что-либо нетривиальное на make или autotools то доки придётся читать в несколько раз больше.

3. Встроенный сканер зависимостей рулит. Я написал билдер для Pyrex-а, со сканером зависимостей и теперь пользуюсь им вместо distutils, т.к. distutils зависимости несканирует.

4. Определение изменения файлов по md5 рулит. Если ты поменял комментарий или название переменной в файле, то он только перекомпилируется, сконс посмотрит что объектник не изменился у перелинковывать не будет.

5. Намного лучше осуществляет распаралеливание (scons -j), т.к. сразу, ещё до начала компиляции у него уже есть план чего, как и в каком порядке он будет собирать.

6. Разобраться с ним достаточно просто. Был такой эпизод: собирал я расширение к питону на boost::python, а у них рекомендованая система сборки это bjam и после того как я час парился пытаясь подключить либу, я за пол часа переписал сборку на SCons-е, причём SCons я тогда ещё не знал, только слышал что это круто.

Есть конечно и негативные моменты:

1. Сборка становится очень скучной. Всё всегда собирается правильно, всё работает, никакой романтики.

2. Скрипт сборки это банальная императивщина, а не база правил для искуственного интелекта make...бэээ...скукотища...

>Пора убить это поделие... scons форева!!!

Бля заманал со своим скунсом...

gcc -o bla main.c -lblabla

форева

> 1. Питон таки знать надо. Хотя бы на уровне туториала, для того > чтобы дебажить скрипты сборки. ^^^^^^^^^^^^^^^^^^^^^^^ Этапять! Дебажить ключи компилятора ещё не пробовали?

> 2. Свой билдер написать более чем реально. Для этого конечно придётся читать доку, но если писать что-либо нетривиальное на make или autotools то доки придётся читать в несколько раз больше.

Зачем писать программу для сборки своей программы? Какая-то странная рекурсия получается. Я так понимаю, что билдер тоже надо scons-ом собирать :)

> 3. Встроенный сканер зависимостей рулит. Я написал билдер для Pyrex-а, со сканером зависимостей и теперь пользуюсь им вместо distutils, т.к. distutils зависимости несканирует.

Что есть pyrex? Что есть distutils? Какое отношение они имеют к топику? Я слыхал, что solitaire вообще софт собирать не умеет...

> 4. Определение изменения файлов по md5 рулит. Если ты поменял ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Единственная достойная фича. В make это давно пора включить.

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

А как это будет работать? Или вы говорите о проектах, состоящих из одного объектоного файла?

> 5. Намного лучше осуществляет распаралеливание (scons -j), т.к. сразу, ещё до начала компиляции у него уже есть план чего, как и в каком порядке он будет собирать.

Магия? Время сборки нетривиального проекта с помощью make и scons на мультипроцессоре в студию! Можно заодно упомянуть время затраченное на написание волшебной программы, которая объяснит scons-у как собирать (я правильно понял его смысл?)

> 6. Разобраться с ним достаточно просто. Был такой эпизод: собирал я расширение к питону на boost::python, а у них рекомендованая система сборки это bjam и > после того как я час парился пытаясь подключить либу, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

python не знаю, так что категорично утверждать не буду. Но здесь дело явно либо в руках либо в языке. Если второе, то фтопку этот python.

> я за пол часа переписал сборку на SCons-е, причём SCons я тогда ещё не знал, только слышал что это круто.

С формой отправки надо что-тио делать...

Всё тот же анонимус: anonymous (*) (02.04.2006 22:47:25)

> для того чтобы дебажить скрипты сборки.

> 2. Скрипт сборки это банальная императивщина, а не база правил для искуственного интелекта make...бэээ...скукотища...

Поделитесь дебагером императивного языка... Или травой...

> Этапять! Дебажить ключи компилятора ещё не пробовали? Конечно, конечно. А у тебя make всегда всё правильно собирает, с первого раза и в отладке не нуждается :-)

> Зачем писать программу для сборки своей программы? Какая-то странная рекурсия получается. Я так понимаю, что билдер тоже надо scons-ом собирать :)

А Makefile по твоему не программа?

Билдер сконсом собирать не надо. Билдер на питоне. В сборке не нуждается.

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

>А как это будет работать? Или вы говорите о проектах, состоящих из одного объектоного файла?

Ну смотри: у тебя есть проект из 100 .c файлов. Ты каждый из них компилируешь в объектник, а затем все объектники линкуешь.

Теперь ты в одном из файлов меняешь название переменной и пишешь: make.

Make смотрит файл обновился, перекомпилирует, смотрит объектник обновился и запускает перелинковку.

Если ты используешь сконс, то он сперва посмотрит что содержимое исходника обновилось и перекомпилирует, а содержимое объектника не изменится, md5 не изменится он и не будет заново линковать.

Кстати, он помнит не только md5 сумму исходного файла но и комманду, при помощи которой собирается цель, и если комманда меняется, пересобирает цель, т.е. необходимости делать make clean; make all со scons-ом не возникает практически никогда.

>> 6. Разобраться с ним достаточно просто. Был такой эпизод: собирал я расширение к питону на boost::python, а у них рекомендованая система сборки это bjam и > после того как я час парился пытаясь подключить либу, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

>python не знаю, так что категорично утверждать не буду. Но здесь дело явно либо в руках либо в языке. Если второе, то фтопку этот python.

Дело здесь в языке. Язык отстой. Только не питон, а bjam. Проблема была в том, как в скрипте сборки на bjam-е сказать что надо линковаться с определённой либой. На питоне как раз проблем то и не было.

> Поделитесь дебагером императивного языка... Или травой... gdb сойдёт?

Вкратце (это цитата, так что по поводу *все современные* это не ко мне): Императивные языки — это языки, оперирующие командами, изменяющими значение элементов данных, располагают операциями присваивания и циклами. К ним относятся все современные языки программирования.

За травой в гугл: http://www.google.com/search?hs=64R&hl=en&lr=&client=opera&rl...

> Этапять! Дебажить ключи компилятора ещё не пробовали? Конечно, конечно. А у тебя make всегда всё правильно собирает, с первого раза и в отладке не нуждается :-)

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

> Зачем писать программу для сборки своей программы? Какая-то странная рекурсия получается. Я так понимаю, что билдер тоже надо scons-ом собирать :)

> А Makefile по твоему не программа?

Нет. Это *императивный* набор правил.

> Билдер сконсом собирать не надо. Билдер на питоне. В сборке не нуждается.

Слава богу, что билдер нуждается только в отладке. Спасибо, обойдёмся.

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

>А как это будет работать? Или вы говорите о проектах, состоящих из одного объектоного файла?

> Ну смотри: у тебя есть проект из 100 .c файлов. Ты каждый из них компилируешь в объектник, а затем все объектники линкуешь.

> Теперь ты в одном из файлов меняешь название переменной и пишешь: make.

Я не пишу make, а вешаю биндинг на M-x compile.

> Make смотрит файл обновился, перекомпилирует, смотрит объектник обновился и запускает перелинковку.

Изменение имени переменной в общем случае влияет на объектный файл как минимум в С. В питоне это наверное не так, поскольку там нет объектных файлов.

> Если ты используешь сконс, то он сперва посмотрит что содержимое исходника обновилось и перекомпилирует, а содержимое объектника не изменится, md5 не изменится он и не будет заново линковать.

> Кстати, он помнит не только md5 сумму исходного файла но и комманду, при помощи которой собирается цель, и если комманда меняется, пересобирает цель, т.е. необходимости делать make clean; make all со scons-ом не возникает практически никогда.

Это тоже потенциально полезная возможность. Но в make её не будет никогда из-за принципа KISS.

>> 6. Разобраться с ним достаточно просто. Был такой эпизод: собирал я расширение к питону на boost::python, а у них рекомендованая система сборки это bjam и > после того как я час парился пытаясь подключить либу, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

>python не знаю, так что категорично утверждать не буду. Но здесь дело явно либо в руках либо в языке. Если второе, то фтопку этот python.

> Дело здесь в языке. Язык отстой. Только не питон, а bjam. Проблема была в том, как в скрипте сборки на bjam-е сказать что надо линковаться с определённой либой. На питоне как раз проблем то и не было.

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

Для scons простейшая инструкция по сборке будет такой:

program('hello','hello.c')

Посложнее:

program('hello2',['hello.c','myunit.c'])

Еще сложнее:

sourceslist = Split(""" hello.c myunit1.c myunit2.c myunit3.c myunit4.c myunit5.c myunit6.c myunit7.c myunit8.c myunit9.c myunit10.c """)

program('hello3',sourceslist)

Еще сложнее с подключением посторонних либ:

sourceslist = Split(""" hello.c myunit1.c myunit2.c myunit3.c myunit4.c myunit5.c myunit6.c myunit7.c myunit8.c myunit9.c myunit10.c """)

env = Environment(CPPPATG=['/usr/include/lib1','/usr/include/lib2'], LIBPATH=['/usr/lib/lib1','/usr/lib/lib2']), LIBS=['llib1','llib2'])

env.Program('hello4',sourceslist)

=== При всем при этом автоматически отслеживаются зависимости, и экономится время разработчика... make + autotools тут явные аутсайдеры.

Только отдна дебильность с TAB символоми в makefile показывает, что эту систему пора на свалку истории, а этих дебильностей в make и компании еще дофига.

> make + autotools тут явные аутсайдеры

Наоборот. Всё предельно ясно и намного более функционально.

Повтори-ка на scons такой тривиальный (для autotools) мини-проект.

Файл #1: Makefile.am

  SUBDIRS = mylib hello world
  EXTRA_DIST = INSTALL-QUICK.txt

Файл #2: mylib/Makefile.am

  noinst_LIBRARIES = libstar.a
  libstar_a_SOURCES = star.h star.c
  INCLUDES = -I$(top_srcdir)/headers $(X_CFLAGS) $(png_CFLAGS)

Файл #3: hello/Makefile.am

  bin_PROGRAMS = hello
  man_MANS = hello.1
  hello_SOURCES = hello.h hello.c hi.c
  hello_DEPENDENCIES = $(top_builddir)/mylib/libstar.a

Файл #4: world/Makefile.am

  bin_PROGRAMS = world
  world_SOURCES = world.h world.c island.c
  world_DEPENDENCIES = $(top_builddir)/mylib/libstar.a

Для тех, кто не понял, задание такое: в проекте есть 2 программы "hello" и "world", и общая библиотека libstar. Имеется возможность выпустить релиз ("make dist") и инсталлировать бинарники и man страницу, а также возможно libstar в ближайшем будущем, когда API стабилизируется ("make install"). Причем сегодня разработчик может работать над программой "hello" в своей директории, и делать "make", "make install" в ней, а завтра над "world".

scons зависим от питона, а маке есть в любой unix системе

>Нет. Это *императивный* набор правил.

Вообще-то makefile, это как раз набор декларативных правил.

>Зачем писать программу для сборки своей программы? Какая-то странная >рекурсия получается. Я так понимаю, что билдер тоже надо scons-ом >собирать :)

ПРежде чем спорить о вкусе ананасов, желательно бы их попробовать...

1. писать программу не для сборки *одной* программы, в этом нет смысла. а *расширять* "ИИ" сконса умением собирать ранее не "известные" ему цели. ПРичём не в виде кучи правил в мэёкфайле, а в виде модуля самой системы сборки. Указания в SConstruct/SConscript, при этом, остаются простыми. ПРимер, твоё сборочное правило собирало dll для OS/2: env.SharedLibrary(target='mylib1',source=VeryLargeListOfSources, LIBS=BigBigListOfAdditionalLibraries)

В точности то же паравило (НИЧЕГО не надо менять ни в каких сборочных скриптах), соберёт ту же библиотеку для windows, причём, естественно, будут пересобраны все эти VeryLargeListOfSources, BigBigListOfAdditionalLibraries. Это возможно, именно благодаря билдеру, который понял, что мы "сменили" платформу, компилятор теперь, не icc, а msvc и способ сборки библиотек импорта изменился. И для новой платформы, был вызван новый билдер, без каких-либо изменеий в "правилах" "мэйка". О чудо, точно также соберётся и .so на линуксе. Более того, при использовании этой .so/dll на разных платформах, при сборке окончательного экзешника, scons поймёт с чем именно -- .so или библиотеками импорта и каким образом мы должны работать и соотв. выполнит окончательную линковку. Более того, очень небольшое усложнение в головном SConsctruct -- и мы можем выполнять кросс-компиляцию и сборку. Система освобождает разработчика от неблагодарной работы по отслеживанию всего этого безобразия в "мэйкфайлах", вы всегда работете на высоком уровне, в терминах цели проекта. Вот для этого, и нужны специализированые билдеры. Если готового билдера для некоторого хитрого случае в сконсе нет, и писать его не хочется -- никто не заставляет, можн решить задачу и в стиле классического мэйка, но право, написать билдер ниразу не сложно и экономит кучу усилий для более интересных дел.

Ну а поскольку билдеры пишутся на том же питоне, "собирать" их - не надо. НЕт, конечно, особо эстетствующие могут сделать билдер на c/c++, стандартный сконс прекрасно поддерживает сборку модулей расширения питона посредством swig/sip, ради бога.

>Магия? Время сборки нетривиального проекта с помощью make и scons на >мультипроцессоре в студию! Можно заодно упомянуть время затраченное >на написание волшебной программы, которая объяснит scons-у как >собирать (я правильно понял его смысл?)

На 2 процессорном интеле, время сборки проекта из смеси c/с++/фортран (около 800 файлов), на 10% - 30% (!) меньше, в пользу сконса. Никакой магии. Мэйк выполняетися последовательно, правило за правилом, а в случае сконса -- все сбоорчные скрипты выполняются *перед* сборкой и на момент запуска целевых действий, уже известны все зависимости и порядок сборки для разрешения зависимостей. Правда, честности ради, сказать, что этот механизм никогда не даёт осечек -- нельзя: я сталкивался при сборке qt-проекта, в котором библиотеки виджетов собирались из кучи разрозненых c++/ui и видимо, кое-где возникли циклические зависимости. Впрочем, ничего стравшного, немного подумать, и проблемы не стало, благо сборочные "скриты" весьма короткие. А вот что делать в аналогичном случае, при использовании классического мэка... бррр.

Для того чтобы это сделать на SCons-е придётся думать и читать доку, в основном из-за make dist, всё остальное вобщем-то фигня.

То под что autotools заточен изначально в SCons придётся делать ручками (возможно). Но сравнивали то с Make :-) Может имеет смысл сделать autotools поверх SCons :-D

Встречное задание для make: У нас есть цель и список её зависимостей, т.е. исходников. Нужно сформировать комманду следцющим образом:

compiler -u $(зависимость с расширенем .ucf) $(все остальные зависимости)

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

>Сборкой действительно должны управлять императивные языки. Тогда их и >отлаживать не придётся, и библиотеку можно будет подключить лёгким >движением руки. Судя по твоему описанию scons этот принцип игнорирует.

Библиотеки, естественно, одключаются именно "простым движением" (LIBS=...)

Что касается отладки: ещё раз, не хочется писать свой билдер (а скорее всего, и не придётся: в поставке для всех мыслимых случаев, уже всё написано до нас) -- не надо, можете решать задачу в стиле мэйка. Если не хотите работать удобно -- это ваши проблемы.