[Evgeny_CD 0]

Я себе так представляю процесс правильной 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

[Седой 0]

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

 

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/

[Evgeny_CD 0]

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

[spf 0]

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

1. В мире нет ничего идельного.

2. Искуственный интелект еще не реализован.

3. У каждого свои задачи и требования.

 

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

 

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

Не пользуюсь IDE, поэтому мне разбирать ихние файлы проектов нет надобности.

Держать ide-файлы-проектов под контролем версий неудобно.

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

 

makefile состоит из двух частей.

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

Вторая - конфиг, списки каталогов, если надо некоторые файлы, ключи сборки и дефайны. Правится для каждого проекта, правки простые и понятные.

[Andy_Mozzhevilov 0]

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

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

 

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

src
   common
   ucos
   prоj_name1
   prоj_name2
   ...

 

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

 

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

 

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

 

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

prоj_name
   cfg 
      indep      - здесь cfg h файлы для независимых от платформы исходников
      target     - здесь cfg h файлы для зависимых от платформы исходников
   indep         - здесь исходники, не зависимые от платформы 
   target        - здесь исходники, зависимые от платформы 
   makefile    
      target     - здесь makefile проекта для конкретной платформы 
   doc           -  здесь файл сопровождения изменений проекта

 

Для контроля версий использую 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.

Проект на локальном диске выглядит примерно так:

proj_name
  abs
  lst
  obj
  src

 

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

 

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

[xyzzy 0]

Довольно интересная альтернатива 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

[Evgeny_CD 0]

Довольно интересная альтернатива 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

[spf 0]

Довольно интересная альтернатива make - cook

http://www.canb.auug.org.au/~millerp/cook/cook.html

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

Бинарник для win/CYGWIN (+doc) тут

http://hobbes.nmsu.edu/pub/os2/dev/util/cook-2.26-os2-nt.zip [3.7M]

[raider 0]

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

 

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

Сейчас как раз этим самым и занимаюсь, но для mb90.

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

[Andy_Mozzhevilov 0]

 

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

 

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

Сейчас как раз этим самым и занимаюсь, но для mb90.

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

 

И для фуджитсу у меня тоже смое сделано.

Я использую для генерации зависимостей утилиту depgen (не зависимо от платформы).

Вот здесь описание

http://scmrtos.igpss.com/tools.html

Вот прямая ссылка:

http://scmrtos.igpss.com/files/Tools/depgen.rar

На всякие вопросы отвечу в icq

[klen 1]

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

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

 

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

 

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

[spf 0]

Сейчас как раз этим самым и занимаюсь, но для mb90.

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

 

Все он умеет, используй ключ '-H'.

Выдержки из моего makefile

CC    :=    $(ST_root)\bin\fcc907s.exe

DFLAGS_C    :=    -cpu $(CPU) -B -H \
            $(foreach buff, $(D_inc_c),-I$(buff)) \
            $(foreach buff, $(DEF_ALL),-D $(buff)) \
            -D MEMMODEL_$(MODEL)

$(D_dep)/%.d:    %.c
    @$(CC) $(DFLAGS_C) $< >$*.dd
# Первой строкой вывести цели
# Каждую строку сдвинуть на табуляцию, завершить табуляцией и
# переносом строки
    @$(OS_cmd_sed) -e 1i"$(*F).obj $(D_dep)/$(*F).d:"\\ \
    -e "s/.*/\t&\t\\/" \
    $(*F).dd > $(D_dep)\$(*F).d
    @$(OS_cmd_rm) $(*F).dd

[dxp 34]

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

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

 

Добавление от 10.01.2007

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

[raider 0]

2 Andy Mozzhevilov

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

 

2 klen

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

 

2 spf

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

[klen 1]

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

 

Добавление от 10.01.2007

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

 

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

 

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

 

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