Я себе так представляю процесс правильной embedded (и не только) разработки кода.

Есть большоооой репозиторий кода. Там лежит масса всего, упорядоченная по папочкам и подпапочкам. Есть CVS | SVN, разумеется.

Есть папки архитектур и платформ. Там лежат специфические для них вещи.

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

Собственно, это не новость; все большие проекты так и делаются, и то, что я только что это осознал - это мои проблемы.

Вопрос в том, как оптимизировать процесс сборки кода.

Make - сильня штука, но писать "руками" кучу make файлов я пас.

Automake, Autoconf - хорошие штуковины, но хочется большой поддерджки для родных виндовых тулзов (M$ Visual C, например)

Некоторое время назад я постил различные (нетривиальные | бредовые) идеи
"Концептуальный вопрос по написанию прототипа в среде "похожей на embedd Ось"
http://www.caxapa.ru/echo/arm.html?id=58541

Но поизучав вопрос, я понял, что многое уже изобретено, надо только осознать его

************************************* CMake *************************************
!!! KDE chooses CMake as its build system
http://www.cmake.org/HTML/News.html

http://www.cmake.org
Welcome to CMake, the cross-platform, open-source make system. CMake is used to control the software compilation process using simple platform and compiler independent configuration files. CMake generates native makefiles and workspaces that can be used in the compiler environment of your choice. CMake is quite sophisticated: it is possible to support complex environments requiring system configuration, pre-processor generation, code generation, and template instantiation.

* Supports complex, large build environments. CMake has been proven in several large projects.
* Generates native build files (e.g., makefiles on Unix; workspaces/projects on MS Visual C++). Therefore standard tools can be used on any platform/compiler configuration.
* Has powerful commands include the ability to locate include files, libraries, executables; include external CMake files that encapsulate standard functionality; interfaces to testing systems; supports recursive directory traversal with variable inheritance; can run external programs; supports conditional builds; supports regular expression expansion; and so on.
* Supports in-place and out-of-place builds. Multiple compilation trees are possible from a single source tree.
* Can be easily extended to add new features.
* CMake is open source.
* CMake operates with a cache designed to be interfaced with a graphical editor. The cache provides optional interaction to conditionally control the build process.

Статья по CMake
Cross-Platform Software Development Using CMake
http://www.linuxjournal.com/article/6700

The CMake Build Manager
Cross platform and open source
http://www.ddj.com/184405251

Хорошая обзорная статья Make alternatives
http://freshmeat.net/articles/view/1715/

Какой-то тестировщик есть
http://www.cmake.org/Wiki/CMake_Scripting_Of_CTest
CTest is a cross-platform, open-source testing system distributed with CMake. CTest can peform several operations on the source code, that include retrieving from CVS or Subversion repository, configure, build, perform set of predefined runtime tests. It also includes several advanced tests such as coverage and memory checking. The results can be submitted to a Dart testing dashboard.

С документацией не густо, по сути одна страница (но большая
http://www.cmake.org/HTML/Documentation.html

************************************* SCons *************************************
Раньше это был "выбор KDE".

http://www.scons.org/
http://www.scons.org/doc/HTML/scons-user/book1.html - дока
*********** What is 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. In short, SCons is an easier, more reliable and faster way to build software.

************ What makes SCons better? ************
* Configuration files are Python scripts--use the power of a real programming language to solve build problems.
* Reliable, automatic dependency analysis built-in for C, C++ and Fortran--no more "make depend" or "make clean" to get all of the dependencies. Dependency analysis is easily extensible through user-defined dependency Scanners for other languages or file types.
* Built-in support for C, C++, D, Java, Fortran, Yacc, Lex, Qt and SWIG, and building TeX and LaTeX documents. Easily extensible through user-defined Builders for other languages or file types.
* Building from central repositories of source code and/or pre-built targets.
* Built-in support for fetching source files from SCCS, RCS, CVS, BitKeeper and Perforce.
* Built-in support for Microsoft Visual Studio .NET and past Visual Studio versions, including generation of .dsp, .dsw, .sln and .vcproj files.
* Reliable detection of build changes using MD5 signatures; optional, configurable support for traditional timestamps.
* Improved support for parallel builds--like make -j but keeps N jobs running simultaneously regardless of directory hierarchy.
* Integrated Autoconf-like support for finding #include files, libraries, functions and typedefs.
* Global view of all dependencies--no more multiple build passes or reordering targets to build everything.
* Ability to share built files in a cache to speed up multiple builds--like ccache but for any type of target file, not just C/C++ compilation.
* Designed from the ground up for cross-platform builds, and known to work on Linux, other POSIX systems (including AIX, *BSD systems, HP/UX, IRIX and Solaris), Windows NT, Mac OS X, and OS/2.

Очень сильная штука. Я сижу в листе SCons несколько недель - обстановка здоровая.

************************************* RAKE *************************************

http://rake.rubyforge.org/
RAKE — Ruby Make
Rake has the following features:
* Rakefiles (rake’s version of Makefiles) are completely defined in standard Ruby syntax. No XML files to edit. No quirky Makefile syntax to worry about (is that a tab or a space?)
* Users can specify tasks with prerequisites.
* Rake supports rule patterns to sythesize implicit tasks.
* Flexible FileLists that act like arrays but know about manipulating file names and paths.
* A library of prepackaged tasks to make building rakefiles easier

Не знаю, что это такое. Просто привел для полноты обзора

************************************* Классика жанра *************************************

GNU Automake
http://sources.redhat.com/automake/
Automake is a tool for automatically generating Makefiles compliant with the GNU Coding Standards.
Automake is currently written in Perl, and requires a Perl interpreter on the developer's system. The resulting Makefile.in's do not require Perl or any other "nonstandard" tool (the complete list of standard tools is mentioned in the coding standards).

Autoconf
http://www.gnu.org/software/autoconf/
Autoconf is an extensible package of m4 macros that produce shell scripts to automatically configure software source code packages. These scripts can adapt the packages to many kinds of UNIX-like systems without manual user intervention. Autoconf creates a configuration script for a package from a template file that lists the operating system features that the package can use, in the form of m4 macro calls.

Producing configuration scripts using Autoconf requires GNU m4. You must install GNU m4 (version 1.4 or later) before configuring Autoconf, so that Autoconf's configure script can find it. The configuration scripts produced by Autoconf are self-contained, so their users do not need to have Autoconf (or GNU m4).

GNU m4
http://www.gnu.org/software/m4/
http://savannah.gnu.org/projects/m4/
GNU m4 is an implementation of the traditional Unix macro processor. It is mostly SVR4 compatible although it has some extensions (for example, handling more than 9 positional parameters to macros). GNU m4 also has built-in functions for including files, running shell commands, doing arithmetic, etc.

GNU m4 is a macro processor in the sense that it copies its input to the output expanding macros as it goes. Macros are either builtin or user-defined and can take any number of arguments. Besides just doing macro expansion m4 has builtin functions for including named files, running UNIX commands, doing integer arithmetic, manipulating text in various ways, recursion etc... m4 can be used either as a front-end to a compiler or as a macro processor in its own right.

************************************* Нестандартные идеи *************************************

Формат .proj и прочих фалов далеко не от всех IDE описан. И хачить каждый раз его для новой IDE - тоскливо.

Если нужно сделать проект под новую IDE, то, возможно, стоит поступить так:

* делаем в директории проекта папку под IDE
* пишем скрипт на любом удобном языке
* делаем hard link на все необходимые файлы в эту директорию (с поддирами, если надо)
* в IDE выбираем "включить все файлы"
* линковочные и пр. опции придется вводить ручками в IDE - ничего не поделаешь.

************************************* Вопрос *************************************

У кого как организован процесс сборки проектов из репозитория кода?

Критика раздела "Нестандартные идеи"?

************************************* Ссылки по теме *************************************

Сквозная система разработки embedded устройств
Полноценная GNU среда для embedded разработки
http://www.caxapa.ru/echo/arm.html?id=60891
http://electronix.ru/forum/index.php?showtopic=17562

Членомер C компилеров: GCC 4.xxx зажигает! (данные за август 2005)
http://www.caxapa.ru/echo/arm.html?id=60918
http://electronix.ru/forum/index.php?showtopic=17607

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

http://www.spacenews.ru/spacenews/live/ful...ws.asp?id=17326

к чему это может привести
http://www.osp.ru/text/302/179592/

и как действует лидер рынка

http://www.osp.ru/text/302/179369/

2 Седой: "адназначна". Вот именно таких отзывов я и ждал. Ушел читать & думать. Надолго

1. В мире нет ничего идельного.
2. Искуственный интелект еще не реализован.
3. У каждого свои задачи и требования.

Поэтому, если желания выходят за рамки существующего то приходится рамки расширять самостоятельно (поэтому и существует такое море всевозможных разноплановых инструментов) или желания упаковывать в рамки при помощи других инструментов...


Не пользуюсь IDE, поэтому мне разбирать ихние файлы проектов нет надобности.
Держать ide-файлы-проектов под контролем версий неудобно.
Все собираю gmake+sed+makedepend(если инструмен не умеет этого сам) на платформах MB9X, W32, FreeBSD, QNX(уже в прошлом), www на протяжении нескольких лет.

makefile состоит из двух частей.
Первай - базовые правила по формированию списков исходников, сборке проекта и дополнительные инструменты (CRC и т.п.) для целевой платформы. Создается и рихтуется один раз, один на все проекты для этой платформы.
Вторая - конфиг, списки каталогов, если надо некоторые файлы, ключи сборки и дефайны. Правится для каждого проекта, правки простые и понятные.

Написано много, читать всего нет времени, но на этот вопрос отвечу:


У меня сделано так. Есть репозиторий вот такой организации:


В common расположены общие исходники, используемые в разных проектах, например драйвера последовательных портов, i2c , реализации протоколов и т.п.

ucos и другая ось - понятно

prоj_name - папки исходников проекта

В папках каждого проекта такая организация:


Для контроля версий использую CVS
Для сборки проекта использую gnumake

Makefile реально разбит на 3, которые инклудят друг друга.
1. Makefile проекта
2. Makefile для платформы
3. Makefile общий для всех.

Технология кратко такая:
Из репозитория извлекаются в локальный каталог те модули из common, что нужны в данном проекте.
Как правило, модуль из common имеет ассоциированный с ним конфигурационный файл, чтобы настроить его в соотвествии с потребностями конкретного проекта. Этот конфигурационный файл создается и помещается в папке prоj_name/cfg/indep или prоj_name/cfg/target в зависимости от того, каков сам извлеченный common модуль - indep или target.
В папках prоj_name/indep и prоj_name/target помещаются файлы, относящиеся исключительно к этом проекту.
В prоj_name/makefile/target помещается makefile с опциями для данного проекта.

В результате на локальном диске все модули проекта оказываются размещенными в корневом директории src.
Проект на локальном диске выглядит примерно так:


Makefile написан так, что в проект автоматически включаются все файлы, расположенные внутри src, а получающиеся в результате сборки прокта файлы obj, lst и т.п. раскидываюся по соотвествующим папкам.

Если есть интерес, могу привести для обсуждения свои makefile, скажем для проекта под ARM и IAR.

Довольно интересная альтернатива make - cook
http://www.canb.auug.org.au/~millerp/cook/cook.html

В качестве десерта - статья, написаная автором cook'a:
Recursive Make Considered Harmful,
http://www.canb.auug.org.au/~millerp/rmch/...-cons-harm.html

Сильная штука, мой слабый разум сразу ее осознать не может.

Что меня принципиально привлекает в CMake, SCons - то, что они знают про M$ VC, и умеют генерить файлы проекта под него. Под винду как конечный продукт я ничего писать не собираюсь, но вот натравить на кусок кода test unit - это очень и очень привлекательно, и делать в среде Win32 это куда приятнее, чем по JTAG

Бинарник для win/CYGWIN (+doc) тут
http://hobbes.nmsu.edu/pub/os2/dev/util/cook-2.26-os2-nt.zip [3.7M]

Сейчас как раз этим самым и занимаюсь, но для mb90.
Запнулся на автоматической генерации файлов зависимостей *.d gcc умеет создавать такие файлы, а вот фуджитсовский компилятор - нет. Не подскажите, как Вы решили данную проблему?

И для фуджитсу у меня тоже смое сделано.
Я использую для генерации зависимостей утилиту depgen (не зависимо от платформы).
Вот здесь описание
http://scmrtos.igpss.com/tools.html
Вот прямая ссылка:
http://scmrtos.igpss.com/files/Tools/depgen.rar
На всякие вопросы отвечу в icq

Кроме ембедерства занимаюсь разработкай игрушек (контора Eagle Dynamics, например игрушка LockOn , занимаюсь моделированием радиолокаторов и пишу с коллегами 3D engine). Так вот GNU make вполне всех устраивает пока я и мой товарищь пишет макефайлы всем остальным побарабану - они только о коде чешутся. Проект собирается и под Win32/MinGW и под Win32/MSVC и под Linux/GCC, пожже и под Sun пробывать будем, следующее поколение продуктов будет мультиплатформенными. Все происходит единообразно. Редактирование текста проекта в редакторе соответствующей ОС, отладка соответствующим отладчиком, сборка make'ом который определяет на какой платформе ему все собирать и какой компиллер использовать. Дерево макафайлов и исходников едино.
По поводу писания макефайлов - сложность их создания это большой миф, не миф - нужно себя заставить и поработать с make чтоб уметь его готовить. Причем чем сложнее проект тем больше выйгрыш от использования такой инфраструктуры, при создании мультиплатформенных программных комплексов это вообще единственное средство от необоснованного роста сложности проекта.

Эмбедерские (мои) проекты разумеется строятся по такой же технологии.

Так что вот, че сам съел о том все расказал. Лично пока необходимости использовать альтернативы make не нашел.

Все он умеет, используй ключ '-H'.
Выдержки из моего makefile

make, к сожалению, сам по себе умеет только запускать тулзы, а это далеко не все, что нужно. Поэтому приходится помимо штатных тулзов - компилятора, линкека и т.д. еще использовать всякие сторонние, начиная от генераторов зависимостей и заканчивая утилитами для обработки строк (и текста). Хотелось бы иметь возможность решать эти задачи без привлечения дополнительных инструментов и при этом иметь более универсальный подход в реализации. Это, имхо, более чем причина для поиска альтернативы и перехода на нее.

Добавление от 10.01.2007
P.S. Тем более, что альтернативы достойные уже есть.

2 Andy Mozzhevilov
Спасибо за наводку, буду иметь ввиду.

2 klen
Я в общем-то и хочу использовать make, точнее хочу перейти к использованию одного IDE для написания ПО под разные платформы (x86, avr, mb90, arm). Пока присматриваюсь к eclipse, где проекты собираются как раз с помощью make.

2 spf
Спасибо за подсказку, а также за высланный makefile. Сейчас попробую адаптировать его под свою систему и проекты.

Дэк чтож мешает все эти средства собрать самому, они же есть все сто лет в обед (команды unix). У меня все сделана так: установлена стандартная MinGW (unix environment под Win32) . далее с помощю егоного GCC комипиляю-собираю BINUTILS/GCC свежий для Win32/AVR/ARM, далее скачиваю исходники и разворачиваю среду до нужной функциональности. Таким образом в результате все средства доступны для make. К примеру если ветка компиляции для MSVC то тутже используя перл (ессено собранный и установленный ) генерятся зависисмотси, а если под GCC то он сам их генерит. Для обработки промежуточных результатов сборки проекта используются все многообразие unix-команд командной строки.

Причем заметте!! полная универсальность по отношению к платформам. Все только то что есть на всех платформах!

Если нада могу выложить архив всего этого барахла, (гиг в *.rar обесчаеццо !) Мне не жалко - у меня upload трафик бесплатно. Кто в Москве на Infoline сидит можно бесплатно через пиринг качнуть.

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

И это правильно.
Этим остальным пусть занимаются другие.
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.
Если он уже привычен, то проблем нет, а вот толкать новичков к изучению, тут уже конечно думать надо.....

Например, где?


Узкие места есть всегда. В питоне это относится в основном к реализации функций библиотек, поддерживающих фичи ОС - работа с файлами/папками/путями и подобным. Чаще всего несовместимость сводится к тому, что под линухом так или иная фича поддерживается, а под виндой нет.

Если не нужны, то и не использовать, никто не заставляет. Просто есть такая встроенная возможность.


Я не это имел в виду, а то, что частенько нужны какие-то сопутствующие утилиты. В случае сконса они реализуются прямо тут же, по месту. И инструменатрий для реализации очень на высоте.


Еще какая.


Тоже зависит от сложности мейкфайла. Да и не только от этого. Я до сих пор не могу запомнить, что означают эти все $<, $(F), $? и прочие - всякий раз приходится доку штудировать.

Эдак мы далеко уйдем.
Из последнего:
roundup - нормально работает под юниксами, под виндами для "посмотреть", под os/2 и остальные - облом.
trac - только под юниксами нормально ставится (сам не пробовал, читал в конфах).

выложил к себе
http://klen.org/Files/DevTools/MinGW.rar

архив MinGW, 99% собрано ручками. Все самое свежее, начиная GCC и кончая библиотеками. Имеется GCC под Win32/ARM/AVR и куча всякой остальной дряни не относящейся к разработке встроееных систем. Размер 330мег.

Чтоб все заработало нада все положить в D:\MinGW и прописать путь в путях пользователя D:\MinGW\ local\bin;D:\MinGW\bin