Альтернативы Make'у

2 anonymous (*) (11.07.2005 19:54:35)

Я пытался тремя разными способами пояснить, к чему может приводить концептуальный конфликт Наверно мне удалось это не очень.

Но виной тому, что вы не хотите мыслить абстрактно. Пытаетесь все свести к сумме простых шагов. А я вам пытаюсь объяснить, между ними не расстояние, а пропасть, и что пропасть в два шага преодолеть невозможно. Невозможно полностью согласовать две разные позиции, это можно сделать лишь для ограниченного круга вопросов. Два разных объекта, не могут занимать одно положение в пространстве, иначе это один объект. Естественно, кто понимает, тому кажется, что я многословен, кто не понимает - тому кажется , что это бред. Но я пытаюсь объясниться. Если конкретно, то высокоуровневый make , по сравнению с профессионально написанным на С(++) ... будет или : медленнее(см. COM RPC) ошибочнее менее гибкий, или все вместе . Но суть вопроса не в этом. Разным задачам - разные инструменты. Мир многообразен, где то используют мeнфреймы, а где то используют писюки. И только оффтопик всем навязывает одну точку зрения.

> Такая б-а-а-льшая. Конфиг в не хьюманридабл XML.

И шо бы ви этим хотели сказать? Ну да, конфиг не в хьюманридабл XML, а в хьюманридабл Python. И что? Кому должен быть ридабл этот XML? Разработчику? По мне, так нормальный питоновый скрипт намного читабельнее XML-ных соплей, которые развешиваются на большом проекте. А больше никому (кроме компа) этот конфиг читать и не надо. Так что нужность XML-ной хуманридабилити - это еще вопрос.

Флаг в руки... Не забудь только про то, что нужно предусмотреть механизм расширения. И если расширение будет производиться без перекомпиляции, разработчики тебе памятник поставят. При жизни.

> Я пытался тремя разными способами пояснить, к чему может приводить
> концептуальный конфликт Наверно мне удалось это не очень.
> ...

8-) Поделись травкой, а?

> Ну тогда попробую написать свою систему сборки с анализом кода... XML форматом описания(текстовым).... и усё на C++.

Не надо, пожалуйста. Очень просим. Даже пробовать не надо, пожалуйста.

>И шо бы ви этим хотели сказать?

Именно это я и хотел сказать. Система сборки - система для разработчика. И описание процесса сборки должно быть на легко читаемом человеком неизбыточном языке.

На албанском штоль? :-)

Во-во, на албанском :-)

Разработчик гораздо чаще читает код. И если система сборки тоже является кодом, то читать его намного проще, чем XML. Потому что формат того же build.xml Антовского - это тоже своеобразный язык, синтаксис которого выражается на не предназначенным для этого XML-м.

Зато к нему куча плюшек ко всяческим IDE прилагается. :-)

Ну так к Eclipse CDT тоже есть sconsbuilder. Это все дело времени.

>Так что нужность XML-ной хуманридабилити - это еще вопрос.

А что, разве XML <<хьюман реадабл>> формат? Мне всегда казалось,
что единственная сфера применения XML это как замена закрытых
бинарных форматов. Тоже не конфетка, но зато хоть как-то читаемая.

> Мне всегда казалось, что единственная сфера применения XML это > как замена закрытых бинарных форматов. Тоже не конфетка, но зато > хоть как-то читаемая.

В каком-то смысле так оно и есть. Ну, еще конфиги приложений на нем делать любят. Но это, IMHO, не столько от читабельности, сколько от наличия стандартов DOM и их (в том числе и кроссплатформенных) реализаций. Да и не говорю я, что читабельность не нужна вообще - я сам пищал от восторга, когда свои первые Антовские build'ы писал :-) Просто после знакомства со SCons'ом я считаю, что Ant по этому показателю проигрывает SConstruct'у, выигрывая, впрочем, с большим отрывом у make.

>Не надо, пожалуйста. Очень просим. Даже пробовать не надо, пожалуйста.

Тебе что жалко? Зделаю... посмотрим мож чё путное и получиться. :)
Если нет значит нет... зато мозги потренерую на предмет XML мне счас всёравно писать имплементацию обьектов для игры...

> концептуальный конфликт

не наблюдаю

> Наверно мне удалось это не очень.

Наверное.

> Пытаетесь все свести к сумме простых шагов. А я вам пытаюсь объяснить, между ними не расстояние, а пропасть, и что пропасть в два шага преодолеть невозможно. Невозможно полностью согласовать две разные позиции, это можно сделать лишь для ограниченного круга вопросов.

Я со школы привык (спасибо учителю физики Андрею Андреевичу, светлая ему память!), что за сравнение килограмм с ангстремами, можно и канделябром схлопотать. Система сборки абсолютно ортогональна собираемым проектам, не па?

> Если конкретно, то высокоуровневый make , по сравнению с профессионально написанным на С(++) ... будет или : медленнее(см. COM RPC) ошибочнее менее гибкий, или все вместе .

Уууууууу... Н-да.

1. Какая разница на каком языке система написана? Выбор высокоуровневого языка просто позволяет быстро и с много меньшими, чем в случае кодирования на низкоуровневом языке, создать и отладить *сложную* систему. Ради бога, переписывайте на ++, это вполне возможно, просто займёт огромное число человеко-лет. Здоровье позволяет -- да пожалуйста! 2. Сам поняли, что сказали? *Сложная, высокоуровневая система* будет менее гибка, чем примитивный мэйк, который тлолько и умеет, что сравнивать тданные и интерпретировать сценарии, написаные на достаточно примитивном и плохо воспринимаемом человеке языке (тоже языке программирования! только алгоритмически неполном). Сходите на речку, отдохните -- и посмотрите ещё раз на ваш тезис!

3. Практика показывает, что о замедлении работы речь не идёт: тут бороться за микросекунды без надобности, узкие места совсем не в замедлении работы программы сборки из-за интерпретации команд байткода.

4. Практика показывает, что аргумент о меньшей гибкости также в глубоком пролёте: scons является расширяемой системой, причём для добавления новых возможностей, не надо вмешиваться в базовый код scons'а или перекомпилировать систему.

/GLeb

> Тебе что жалко? Зделаю... посмотрим мож чё путное и получиться. :) Если нет значит нет... зато мозги потренерую на предмет XML

Да "наздоровье". только два обстоятелсьтва:

1. XML в системе сборки должен будет читать не только автоматический builder для той или иной IDE, который тебе тоже надо будет написать, иначе затея смысла не имеет, но и человек -- разработчик. А разрабатывали XML люди, которые, похоже, ничего, кроме HTML в жизни не видели, и получилось то, что получилось: нечитабельное угрёбище.

2. Время разработки (полный цикл, включая отладку) на C++, в среднем, в 7 раз (так!!!) больше, чем на Питоне.

Вперёд.

/GLeb

> Ключевые слова не подскажешь по этой теме? Всего Геделя перечитывать не предлагать :D Но устойчивость больших систем, состоящих из неустойчивых элементов мне интересна :)

не стоит. я физик, а не математик. Совру обязательно :)

/GLeb

>А разрабатывали XML люди, которые, похоже, ничего, кроме HTML в жизни не видели

благородный дон никогда не слышал о SGML? подсказка: подмножеством чего должен был быть html изначально?

>устойчивость больших систем, состоящих из неустойчивых элементов

дык *элементы* как раз устойчивы :) если речь идет о c++ кусках + python glue.

> вот ещё интересно, кто-нибудь реально использовал Boost.Build?

Оно нерасширяемое, а остальное... делается теми же сконсовыми средствами. Короче, я игрался, но серьёзно использовать не стал.

/GLeb

> благородный дон никогда не слышал о SGML? подсказка: подмножеством чего должен был быть html изначально?

благородный дон слышал... и всегда удивлялся...

К моменту разработки SGML уже существовали синтаксически удачные описательные языки, например, Лэмпортовский LaTeX. Ну кто мешал двигаться в этом направлении? Нет, уцепились за парные теги, а то, что ценой весьма незначительного упрощения парсера стала нечитабельность -- никого не волновало.

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

В майкрософте, наверное, хохочат и бьются в корчах, глядючи на попытки заставить ворочаться OpenOffice и проч., основанные на xml-форматах документах, хоть чуточку быстрее.

/GLeb

> Испольщующие *только* базовый функционал -- безусловно. Варниниги -- не в счёт.

Что ж. Ответ получен. Минус возможности использования питона есть. Поэтому: "втопку". Пока не устранят этот недостаток все проекты на это приблуде можно считать хаком. Я не спорю, что хаки иногда полезны, но это хаки. Да используя хаки сделать что-то гораздо легче. Но при смене базы хаки надо переписывать.

> И вот тут на сцене и появляются сборочные системы второго и третьего поколений. Которые не только должны выполнять некий сборочный сценарий, но и делать это осмысленно.

Сборка должна происходить так, как надо, а не так, как нужно по мнению системы сборки.

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

Вот с этого и надо было начинать. Похоже, что вы просто не умеете писать makefiles, ничего не знаете про template rules и gcc -MD. Каждый имеет право на свое мнение, но если вы не смогли осилить даже 10% info make, то не надо пинать эту утилиту ногами и возводить scons в абсолют.

Automake -- это, конечно, дикая вещь. Наверное, ей просто надо уметь пользоваться. Я, к сожалению, не умею. А вот autoconf вполне удобен и пригоден для того, чтобы пользовать его отдельно от automake. Пример -- MPlayer.

>Время разработки (полный цикл, включая отладку) на C++, в среднем, в 7 раз (так!!!) больше, чем на Питоне.

а чего не в 10? не в 20? отчего у вас, фанатиков, всегда так плохо с аргументацией, зато голословных утверждений выше крыши?

>python glue

новая разновидность "момента" для гурманов? :)

>> Испольщующие *только* базовый функционал -- безусловно. Варниниги -- не в счёт.

> Что ж. Ответ получен. Минус возможности использования питона есть. Поэтому: "втопку". Пока не устранят этот недостаток все проекты на это приблуде можно считать хаком.

Н-да... Это не бред, это собачий бред, ты бы хоть посмотрел, *как именно* задаётся сборочный сценарий. Посмотрел? тогда попробуй написать такой "хак", который не заработает на любой произвольно взятой версии SCons (разумеется, сохраняя правило "снизу вверх"!).

Зуб даю, тебе это не удастся. Я вижу только один способ: интенсивно использовать в сборочном сценарии фишки питона, не существовавшие ранее (списковые включения и интенсивное определние классов, которые ране не были обязаны наследовать от Object), и подложить в систему сильно устаревший питон. Но это не аргумент, так как 1) совместимость сверху вниз -- никто н еобещал и никогда обещать не будет! и 2) так просто никто никогда не делает -- за ненадобностью!

Смена версий что питона, что сконса (по крайней мере, до сих пор) шла абсолютно незаметно -- не сравнить с модификациями мэйка (make - gnu make - dmake) и без малейших модификаций сборочных сценариев. Хак, блин... верхоглядство! в стиле "Пастернака не читал, но...".

/Gleb

> основанные на xml-форматах документах, хоть чуточку быстрее.

сходил бы ты на xml.org да тесты посмотрел

>> основанные на xml-форматах документах, хоть чуточку быстрее.

>сходил бы ты на xml.org да тесты посмотрел

А зачем тесты? - я до сих пор с содраганием вспоминаю как всего
на всего 300к документ в emacs в psgml моде редактировал -
пришлось сделать несколько приседаний, чтобы это безобразие ускорить.

Это не формат для человека.

> Сборка должна происходить так, как надо, а не так, как нужно по мнению системы сборки.

кто-то спорит? Другой вопрос, что система сборки *уже* знает, как правильно производиь сборку в типовых случаях, а в сильно нестандартных -- ты всегда можешь или написать соответствующие хуки руками. а-ля "простой мэйк", либо создать собственный билдер и *научить* систему сборки строить проект для данного случая -- если действо сие повторяется достаточно часто и усилия окупаются.

> Вот с этого и надо было начинать. Похоже, что вы просто не умеете писать makefiles, ничего не знаете про template rules и gcc -MD.

Да что ви гоффорите! а более простая мысль -- я *слишком* хорошо знаю, что это такое, и предпочитаю забыть, как о страшном сне -- в голову не приходит? Нафига мне тратить время на написание мэйкфайлов, если сборка прекрасно идёт более простым, удобным и кстати, предсказуемым, образом? У меня есть дела поважнее и поинтереснее.

> утилиту ногами и возводить scons в абсолют

Я не пинаю ногами. Тезис прост: мэйк примитивен, есть более мощные, более совершенные и удобные средства. Насчёт абсолюта -- ничего не скажу. Мне (пока) не опадалась ситуация, в которой сконс не справлялся бы. Попадётся -- тогда посмотрим.

Я просто пытаюсь пролоббировать :) хорошую разработку, о которой (к сожалению!) знает не очень много народа. и в этом есть чисто шкурный интерес: чем шире она будет использоваться, тем легче будет моя собственная жизнь :) а то ведь ситуация, когда большой пакет не собирается, а по работе -- кровь из носу надо! -- из-за того, что разработчики использовали экзотический или устаревший мэйк, или просто напичканый sed'ом - awk'ом и сдобно подправленый configure, а конфигурация программного окружения не совпадает -- не выдумка! Причём сами разработчики отвечают, что не будут решать эту проблему, поскольку сами уже неспособны разобраться в нагромождениях собственного мэйка и предлагают переустановить машину (хе-хе! хорошо, если это не кластер! щас!) в точности, как у них. Спасибо, кушайте сами.

/GLeb

> а чего не в 10? не в 20?

не знаю, я не психолог.

Моя личная цифра -- примерно в 7 - 8 раз быстрее, сосед раза в 4, но всегда быстрее.

> отчего у вас, фанатиков, всегда так плохо с аргументацией, зато голословных утверждений выше крыши?

я готов и могу доказать свои слова. Кроме цифр для опытных пользователей, могу немного сказать о работе обучающихся -- школьников и студентов. Там разрыв ещё больше, так как просто нормально изучить технологию работы с шаблонами вообще и STL в частности -- не так то быстро, а подобные проблемы перед питон-программистами не стоят вообще.

Попробуй сам, в конце концов, о результатах -- сообщи.

/Gleb

BINARY_OBJECTS=obj1.o obj2.o

all: binary

-include .dep

binary: $(BINARY_OBJECTS)
        $(LD) -o $@ $^ $(LDFLAGS)

%.o: %.cpp
        $(CXX) -c $< $(CXXFLAGS)

%.o: %.c
        $(CC) -c $< $(CFLAGS)

И что здесь ^^^ непредсказуемого? Утилита должна быть достаточно тупой,
чтобы беспрекословно, быстро и четко выполнять свою функцию и только 
ее. Это unixway. AI, вшитый в систему сборки не может быть хорош для 
всех случаев, так как он -- AI, а от него требуется, чтобы он тупо делал
то, что просят, а не то, что, как ему кажется, нужно.

> . Хак, блин... верхоглядство! в стиле "Пастернака не читал, но...".

Что ж, ты явно не способен думать понятийными категорями. Если мне ясна концепция, то для понимания того, что концепция неработоспособна мне не нужно знать детали реализации. Ошибка в концепции не может быть исправлена реализацией, ибо это ошибка концепции. Так что бред несешь ты. И хуже чем собачий. Ибо пропагандируешь хак. А это может привести к появлению проблем у остальных. Так вот: Пока не уберут возможноть использования питона для сборки проекта эта приблуда будет хаком и ты от этого не избавишься. Вот если уберут и она будет работоспособна я сам первый начну ее изучать проверяя возможность использования в своих проектах.

> BINARY_OBJECTS=obj1.o obj2.o

>all: binary

>-include .dep

>binary: $(BINARY_OBJECTS) > $(LD) -o $@ $^ $(LDFLAGS)

> И что здесь ^^^ непредсказуемого?

-include .dep

особенно, если сборка obj неявно влечёт за собой сборку _obj_n. Например, в случае использования метакомпиляторов .cpp файлов, неявно порождающих дополнительные цели сборки.

> AI, вшитый в систему сборки не может быть хорош для всех случаев, так как он -- AI, а от него требуется, чтобы он тупо делал то, что просят, а не то, что, как ему кажется, нужно.

AI не AI, а "интеллектуальная" система, стереотипно разруливающая типовые, рутинные операции ещё никому не мешала. Что же до "ему кажется, нужно" -- в большом проекте, с нетривиальными зависимостями и неявно порождаемыми файлами, я положусь на этот самый AI и полезу исправлять руками только в случае. если автосборка обломится. Почему -- неочевидно?

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

/GLeb

> Что ж, ты явно не способен думать понятийными категорями

ну, значит, не судьба.

> концепция неработоспособна мне не нужно знать детали реализации

на здоровье. но ты и концепцию явно не знаешь.

> Ибо пропагандируешь хак.

> Пока не уберут возможноть использования питона для сборки проекта эта приблуда будет хаком и ты от этого не избавишься

проект собирает (явным образом) *не* сценарий сборки, а сборочная система сконса. Убрать из неё питон - нонсенс, поскольку на питоне она собственно,и реализована. И естетсвенно, на питоне и расширяется, при необходимости.

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

Ещё раз: где хак?

И ещё раз, для определённости: в сборочные сценарии сконса, последовательности команд для сборки, *в норме*, не включаются -- это дело AI, если угодно.

/GLeb

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

P.S. если чуть-чуть усложнить, то можно впарить автоматическую генерацию .dep файлов в makefile, но мне впадлу было вписывать. Имея один единственный фаблон makefile'а можно повторно его использовать.

BTW: в дипломном проекте у меня была довольно замороченная структура каталогов, куча объектников и shared libraries. Autoconf + make разрулил все; значит, make все еще на плаву и не вам его топить.

понятно. Выростешь из студентов -- продолжим разговор, пока факт -- бесполезно. Кто хотел, надеюсь, что-то полезное для себя из дискуссии вынес.

/GLeb

>> концепция неработоспособна мне не нужно знать детали реализации

> на здоровье. но ты и концепцию явно не знаешь.

>> Пока не уберут возможноть использования питона для сборки проекта эта приблуда будет хаком и ты от этого не избавишься

> проект собирает (явным образом) *не* сценарий сборки, а сборочная система сконса. Убрать из неё питон - нонсенс, поскольку на питоне она собственно,и реализована. И естетсвенно, на питоне и расширяется, при необходимости.

Вот именно это и является коцепцией: Возможность расширения на питоне.

Я это не понял? Не бросайся просто так словами а то станешь восприниматься как просто болтун.

Причем концепция содержит грубую ошибку. Все. Дальше можно не смотреть. А учитывая то, что ты говоришь, что эту возможность убрать невозможно, то у этой приблуды нет будущего.

Прочитал и понял, что альтернативы make пока нет:-) Scons который тут пропеарили имеет один офигенный недостаток, а именно то что сделан он на питоне, переписали бы его на C/С++ (не верю что нельзя) и вот тогда... А так сам по себе проект неплох, но скажем на серваке иметь питон:-) Да и вообще будет тема как на FreeBSD где modula ставят тока из-за cvs-up ибо на ней написан

>Да и вообще будет тема как на FreeBSD где modula ставят тока из-за cvs-up ибо на ней написан

Е-мое, ты если чего не знаешь, так лучше молчи !

$ which cvsup
/usr/local/bin/cvsup
$ ls -l /usr/local/bin/cvsup
-rwxr-xr-x 1 root wheel 873592 29 июн 12:33 /usr/local/bin/cvsup
$ pkg_info -Ix cvsup
cvsup-without-gui-16.1h_2 General network file distribution system optimized for CVS
$ pkg_info -rx cvsup
Information for cvsup-without-gui-16.1h_2:

Depends on:

$

modula требуется только для для сборки !
После сборки имеем бинарик без динамических библиотек
- ибо статикой все собрано.
А если как нормальный юзер ты ставишь собранный пакет, то нету там никакой модулы и дополнительных зависимостей.

И только если ставишь порт, то он долго собирает эту модулу
чтобы статически ее подключить ;)

>Моя личная цифра -- примерно в 7 - 8 раз быстрее, сосед раза в 4, но всегда быстрее.

т.е. из этого всего лишь следует что вы с соседом знаете питон лучше плюсов.

> подобные проблемы перед питон-программистами не стоят вообще

что то учить? а т.е. программисты-дауны?

>Попробуй сам, в конце концов, о результатах -- сообщи

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

зы. ты напиши что такого восстребованого народом и использующего autotools у тебя не собралось?

>особенно, если сборка obj неявно влечёт

OBJS=... moc_mainwin.o ...

...

moc_%.cpp: %.h moc $< -o $@

>Это долбоёбвей, извините

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

> Вот именно это и является коцепцией: Возможность расширения на питоне.

ну и в чём проблема?

очевидный пример #1. года три я начал использовать scons и сразу столкнулся с тем, что сборка dll (и более широко, поддержка компилятора icc 3.6.5, это из мира OS/2), была сделана неправильно. Дописывается свой билдер для c++, указывается в проекте сборки, всё. Работы -- на 15 минут.

очевидный пример #2: изначально scons не имеет билдеров для поддержки сборки KDE приложений. Ну и что? Появляется набор расширений bksys, который закрывает этот недостаток (и делает это очень удачно, по сравнению с кошмаром имени autotools).

ну, и где тяжёлая идеологическая проблема? Ещё раз, если до тебя не доходит. Аналог мэйкфайлов в сконсе -- это пара скриптов Sconscript / SConstruct. в *них*, расширения *НЕ ПИШУТСЯ*. Там, обычно, пишут или простые правила сборки, или максимум, простые подготовительные действия, типа получить список исходников, если он явно не указан, выбрать платформу для компиляции и т.п. А расширения -- оформляются в отдельный инструмент (tool, в терминологии сконса). И либо включаются в проект, как пользовательский инструмент, либо становятся частью сконс-системы. Поэтому волноваться, мол, кто-то напишет такое расширение, которое не будет работать на произвольной машине -- глупо и действительно, такого не происходит.

И где грубая ошибка концепции? Что тебе дали гибкий (и модульный) инструмент, с функционалом, принципиально недостижимым в классическом мэйке? Ну, можно, конечно, возмущаться прогрессом и изобржать из себя луддита современности, только с идеологической подоплёкой, но как-то это выглядит глупо и неубедительно. "Дяденька, я просил клубнику маленькую и червивую, а мне дали красивую и крупную! а, мошенники, верните мои деньги"

/GLeb

> долбоевэй это призывать выучить "один из скриптовых языков" ради того чтобы собирать свою программу.

Во первых, где граница между "скриптовым языком и полноценным"? Питон -- полноценная система программирования, и очень высокого уровня.

Во-вторых, для сборки своей программы, учить питон -- не обязательно, и если не хочется - то и не надо. Незнание ровно ничему не помешает.

В третьих -- "красноглазые пионеры" -- это скорее, выучившие пару заклинаний джентельмены, не желающие и главное, не умеющие осваивать новое и придумывать новое.

> moc_%.cpp: %.h moc $< -o $@

В четвёртых, moc'ом дело дааалеко не ограничивается, представь себе, бывает и многоходовая компиляция. А о том, что написаное тобой правило способно породить дурную рекурсию и никогда н разрешиться -- я и не говорю.

Учи матчасть, короче.

/GLeb

> т.е. из этого всего лишь следует что вы с соседом знаете питон лучше плюсов.

А это не только моя статистика. Это же самое говорят *все* без исключения (по крайней мере, исключения мне неизвестны), кто использовал или использует реально питон.

Вполне объяснимое дело.

1. Не надо думать о технических деталях, типа правильного истанцирования шаблонов привидения типов 2. Не надо думать о распределнии памяти и заниматься этим вручную. 3. Нет проблемы диких указателей и многократно освободёных блоков памяти. 4. Концепция ООП реализована полноценно (в терминоголии известного обзора Тимоти Бадд, Объектно-ориентированное программирование в действии, сравни со Smaltalk), в том числе не надо череж ж. реализовывать персистнентные объекты. 5. Обработка исключений полноценная, не загромождающая программу и "дешовая". 6. За счёт интерпретации, всегда известно место возникновения ошибки, возможен отлов любых типов ошибок (в том числе, синтаксических) и при некоторой фантазии, нетрудно соорудить откат. 7. Наконец, нетрудно заставить программу писать саму себя, а-ля лисповая идеология.

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

Разумеется, у всего есть обратная сторона, но не об этом речь :)

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

тебя кто-то заставляет? КБССЗВ.

> давай лучше ты мнемоники пмк-52

мил друг, вот это я с удовольствием забыл лет 15, как. А сам МК лежит на столе и активно используется -- польская нотация для калькуляторов -- это Вещь.

> Прочитал и понял, что альтернативы make пока нет:-) Scons который тут пропеарили имеет один офигенный недостаток, а именно то что сделан он на питоне

И в чём недостаток?

> переписали бы его на C/С++ (не верю что нельзя)

без проблем. Но 1. если принять пропорцию "день разработки на питоне == 7 дней разработки на C++", а развивается сконс уже более 5 лет -- возьмёшся? 2. сразу потеряется возможность расширений без перекомпиляции системы сборки.

Ну и нафига? Чтобы оно начало работать на 1 микросекунду быстрее?

PS: ещё раз, на сервере питон весьма полезен. для администрирования.

/GLeb

> А расширения -- оформляются в отдельный инструмент (tool, в терминологии сконса). И либо включаются в проект, как пользовательский инструмент, либо становятся частью сконс-системы.

То есть ты говоришь что есть возможность создать на питоне расширение для для этой приблуды и она будет частью проекта? Я так думаю возможность проконтролировать все проекты на совместимость с будующими версиями питона еще никто не реализовал? :)

Вот этого достаточно для негатвиного отношения к приблуде. Ибо хак, и идеология поощряющая хак.

> но как-то это выглядит глупо и неубедительно. "Дяденька, я просил клубнику маленькую и червивую, а мне дали красивую и крупную! а, мошенники, верните мои деньги"

Если ты не видищь, как здесь ошибаешься, то это твои проблемы. Кто сказал что я буду есть ее. Она мне нужна и именно такая, какую попросил, и не тебе советовать какая мне нужна, ибо ты не знаешь зачем она мне нужна.

To: bzlmage Я так понял что те люто ненавидимые тобой расширения для scons - сиречь плагинЫ. Соответственно при обновлении питона (если работоспособность все же поломается) - просто поставишь обновленный плаг ....

Ещё о недостатках мэйка, есть там такая замечателтная вещь как переменная $<, а если нам надо вставить не все зависимости для данной цели сборки, а только часть, а другую часть файлов предварить ещё какими-нибудь ключиками, в зависимости от типа файлов, то что делать?

Такой пробелмы не возникает при использовании GCC, но при использовании какого-нибудь хитро-выделанного toolchain-а всё может быть не так гладко, и у меня как-то раз такая проблема возникла.

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

(Кстати, если кто скажет как таки можно было решить эту проблему красиво, буду очень благодарен :-) )

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

Ну в принципе фанатикам что-либо объяснять бесполезно, а всем здравомыслящим людям я могу посоветовать если собираете что-нибудь мало-мальски серьёзное, то потратьте на SCons хотя-бы час, вдруг понравится. Забудете make / autotools как страшный сон.

Кстати, об Ant-e, читал интервью толи с автором, толи одним из авторов, так вот он сказал, что Ant скрипты уже давно превратились в программы, только вместо того чтобы использовать для написания программ предназначенные для этого языки, они используют не предназначенный для эторго xml. И что, если бы он сейчас стал делать Ant с нуля, то в качестве языка он бы использовал какой-нибудь полноценный язык программирования, например питон :-)

Расширения сконса можно делать различным образом: Можно например просто встроить новые функции непосредственно в скрипт сборки (SConstruct/SConscript), так например поступают при сборке PyOgre, т.е. питонвского байнда для Ogre3D, а это ни хухры мухры, а был проектом месяца (в марте) на сорсфордже.

Не нравятся лишние функции в скрипте сборки, вынеси их в отдельный файл, например custombuilders.py, а в скритпте добавь: from custombuilers import *.

При таком подходе скрипт сборки будет самодостаточен и никаких проблем не будет при смене версии питона на более новую.

Я когда пишу расширения к SCons-у, все их запоковываю в отдельный пакет, и мне теперь при переустановке питона придётся его переустанавливать, ажна придётся написать cd ~/projects/sconshelper; python setup.py install

Ну да ладно, авось не надорвусь.

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

>А так сам по себе проект неплох, но скажем на серваке иметь питон

3 ха-ха. 1) иметь на "серваке" perl благородный дон не боится? 2) иметь на сервере шелл не страшно? а вдруг в какой-нибудь Makefile засадили зловредный код на чистом /bin/sh :) 3) самое главное: если уж у Вас на сервере *компилятор* и *autotools*... теперь хоть питон, хоть visual basic - хуже не будет.

2 anonymous \Gleb Для физика, ты слишком избегаешь абстракции. Скорость это часть концепции - как физик, ты просто недопустимо инфантильно относишься к скорости.

То что на любом высокоуровневом языке(инструменте) быстро писать, это часть их концепции, но у этой концепции есть обратная сторона - ресурсоемкость и скорость исполнения.

Я совсем не обсуждаю достоинства и недостатки альтернатив make, по причине того, что их просто не знаю. Но есть несколько концептуальных вопросов, вполне очевидных, я собственно о них и говорю.

И наконец напоследок хочу еще раз напомнить, вряд ли можно ожидать, что может существовать одна программа, подходящая для всех случаев. Должны быть разные программы для разных случаев.