Да, на местный фтп, если не сложно - очень интересно.

И это правильно.
Этим остальным пусть занимаются другие.
Unix-way во всей мощи: программа делает что-то одно, но делает это хорошо.
Давйте изобретать велосипед вместо того, чтобы использовать уже имееющееся. Тем более, что никакой монолитный суперпупермегакомбайн не сравнится по гибкости с конструктором.

Ок. Тогда посмотрим с другой стороны. Компилятор не GCC, компилятор не умеет выдавать зависимости. Как их добывать? Даже если компилятор умеет, но не умеет ассемблер, хотя ассемблер поддерживает препроцессор (это нынче обычная штука) в части #include и #if/#ifdef..., т.е. надо чтобы и включенные в ассеблерные файлы заголовки тоже попадали в список зависимостей. Кто построит этот список для ассеблерных файлов? Не иначе надо где-то брать генератор зависимостей для этого. Сторонний.

Далее. Такая задача: компилятор у меня выдает сообщения с ошибками в несколько строк, если строка не умещается в 70 (с небольшим) символов. Подавляющее большинство таких сообщений не умещаются - там только текст "Error xxxx, line nnn, column mmm, ... " занимает полстроки, а текст самого сообщения переносится на следующую строку. Когда я в редакторе перехожу на место ошибки, у меня в строке статуса показывается сообщение об этой ошибке (стандартная фича многих программерских редакторов), только вижу я только первую строку, хотя все сообщение прекрасно умещается в строке статуса. Некоторые комиляторы - например, IAR, имеют специальный ключ (--no_wrap_diagnostics) для подавления переноса строк сообщений. Но не все. Как быть?


Во! Целый гиг!. А тем не менее все вышеописанное (и многое другое - практически все, что может понадобиться) легко решается одним единственным инструментом, который весит далеко не гиг.




Сильный аргумент! А если серьезно - чем это правильнее по сравнению со случаем, когда система сборки может легко и эффективно выполнять сопутствующую работу?


Чем это лучше, если программа умеет делать все сразу и делает это хорошо? И при этом возможности можно расширять сколько угодно, не привлекая сторонние тулзы. И все будет делаться хорошо. Во всяком случае не хуже, чем это делает весь сонм разнородных тулзов.


А речь и не идет про супермегакомбайн. Речь идет именно про конструктор, но основанный не на жестко написанной программе, а на гибком движке. Который (движок) позволяет легко расширять функциональность в рамках текущей идеологии и инструментария.

Это зачин . Все свои аргументы я изложил в том посте ниже.
make и есть этот движок. Точнее, связка make+shell.

Не канает. Во-первых, более-менее приличный шел бывает под никсами, но не под виндой. Это кроссплатформенность связки. Всякая эмуляция под виндой - это гемор еще тот. Во-вторых, это ни в коем случае не достаточно - сюда еще надо обычно +sed (или аналогичный) +генератор зависимостей (в общем случае, не везде же GCC используется, не везде компилятор умеет строить зависимости, ассеблеры вообще этого не умеют как правило) +различные дополнительные утилиты (нужны не всегда, но кое-где без них тяжело). А еще некоторым нужны функции automake. Это еще одна тулза. И т.д.

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

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

Выскажу и я свои 5 копеек!

Некоторые итоги. Итак пути такие:
1. Ручное создание мэйфайла, со всеми вытекающими.
Пока файлов не много, или все правила общие, не так уж и трудно, но времязатратно.

2. Пользование различных IDE где всё это скрыто, а наружу торчат проперти проекта/файлов.
Довольно удобно, но привязано к IDE/платформе/компилятору

3. Использование утилит по созданию мэйкфайла (а то и прочих полезностей) для проекта
3.1. autoconf/automake
Ниасилил (пока ).
3.2. tmake
Приятны утиль (перловый скрипт), когдато начал пользовать с Qt приложениями, а потом легко написал шаблончик для пректов на AVR (были цели по компиляции с avr-gcc, программированием с uisp и т.д.). При этом для каждого проекта вручную создавался только простой *.pro файл.

3.3. - 3.ХХХ .... Добавьте по вкусу

4. ???


PS ИМХО:
1. Вручную создавать мейкфайлы удовольствия мало.
2. Знать как оно работает очень полезно (если не сказать необходимо)
3. Спорить о том что лучше - без толку. Лучше давайте делиться технологиями.

Scons - "SCons is an Open Source software construction tool-that is, a next-generation build tool. Think of SCons as an improved, cross-platform substitute for the classic Make utility with integrated functionality similar to autoconf/automake and compiler caches such as ccache."



Если проекты делать в одном стиле то и makefile надо разработать один раз, а потом только конфигурировать -- указал пару каталогов (и т.п. мелочи) и фсе, получаешь удовольствие .

Поскольку вопрос исходно стоял не в том, какие есть альтернативы, а нужны ли они make, то и посты были в этом ключе. А тайны никакой нет. Лично я переполз на SCons. Все вышеперечисленные задачи решаются в рамках оной тулзы очень легко. Справедливости ради надо отметить, что тут не столько в самой тулзе дело, сколько в ее "бэкграунде", коим является мощный интерпретируемый ЯП.

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

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

Да, и кроме того, практически самым широким списком поддерживаемых платформ (от DOS и до QNX и остальных) обладает все тот же make. Так что если хочется общности средств сборки, то лучше все-таки пользоваться им.

Вот уж нет! Никак не соглашусь с формулировкой полностью освоен...! Достаточно знать азы и базовый синтаксис. Он там очень простой. make с его птичьим языком стоит и курит в уголке. На то, чтобы заточить make и сопутствующий инструментарий (генератор зависимостей, например) под свои нужды времени и сил у меня ушло больше на порядок, чем на питон и сконс вместе взятые. Начиная хотя бы с того, что удовлетворяющий генератор зависимостей (для заголовков) я так и не нашел и пришлось написать самому. Свой меня тоже не в полной мере устраивал и я неоднократно повторял попытки найти достойный инструмент, но тщетно. В составе же сконса эта приблуда идет штатно в качестве фукнции и работает замечательно.

Продолжая тему. Я долго использовал make и по причине того, что он умеет только пускть тулзы, эти тулзы пришлось разыскивать или, что чаще, писать самому. Использовались разные средства от использования возможностей убогого виндового шелла до программ на С++ и AWK. Когда довелось познакомиться с Python'ом, произошло постепенное вытеснение всего зоопарка утилит на аналогичные на скриптах питона. Поэтому специального изучения языка не потребовалось.

Python - очень мощный и полезный инструмент, он позволяет решать кучу повседневных задач, начиная от утилит обработки текстов до моделирования и математики (в ряде случаев вполне успешно заменяет, например, Матлаб ).

Смею заверить, что по кроссплафторменности питон мейку не уступит. А по переносимости скриптов пожалуй и превозойдет. В частности, я столкнулся с проблемами использования make на платформе Windows когда в путях были указаны папки, содержащие никсовые шеллы. Пришлось удалить эти папки из путей (либо удалить сами исполняемые шеллов).

Что касается общности средств сборки, то как раз сконс и рулит - там все в одном флаконе. Включая autoconf/automake.

Кстати, сконс не первый и не единственный такой конструктор - сам он произрастает из конструктора Cons, написанного на языке Perl; на Python есть также еще конструктор Waf. На последнем, вроде, строится сборка популярной под никсами системы KDE. Т.ч. что ни говорите, а это конструкторы нового поколения и тенденция четкая уже давно наметилась.

Не уверен, сильно не уверен, т.к. реально натыкался на отсутствие кроссплафторменности у питоновских инструментов. Кроссплафторменность в питоне -- отдельные танцы с бубном, если еще и бубен есть. основное конечно катит, но узкие места есть.

PS:
На каких платформах работал? Уверен, на одной -- виндовс

За выходные попробую покопаться.
Самая главная проблема наверное будет понять, зачем мне нужны-ли всякие "auto" конфигураторы.
В общем-то программы все равно писать-то надо и добавляя файл в проект добавить несколько символов или строчек в , например, makefile - в чем проблема? Начиная новый проект надо думать как он будет организован, ну и сразу излагать свое видение.
Явная проблема есть одна - синтаксис make.
Если он уже привычен, то проблем нет, а вот толкать новичков к изучению, тут уже конечно думать надо.....