gnu make

Hello, Sergey!
You wrote to All on Thu, 18 Sep 2003 11:00:33 +0400:

[...]
 SN> %.d: %.c     #
[...]
 SN> Если указать путь явно $(addprefix
 SN> $(OBJ_DIR)/, $(DEP)),  то выскакивает ошибка

 SN> *#────────────────── begin of Windows Clipboard ──────────────────#*
 SN> makefile:66: d:/projects/btnode/extract/obj/btnode/avr128_uart1.d:
 SN> No such file or directory make: *** No rule to make target
 SN> `d:/projects/btnode/extract/obj/btnode/avr128_u art1.d'.  Stop.
 SN> *#─────────────────── end of Windows Clipboard ───────────────────#*
 SN> Почему не задано правило? Оно же существует?

    Нет, правило существует для _конкретных_ файлов .d, которые удалось
найти на этот момент (%.d). А их нет.

 SN> Как можно обойти такую тонкость?

    Замени %.d:%.c на $(DEP): $(SRC), правда, правило тоже придётся
переработать, используя в нём только имя  текущей цели, а соответствующий
исходник "добывать" из него.

Alexander Derazhne

Для чего?

Hello Dimmy.

18 Sep 03 20:10, Dimmy Timchenko wrote to Sergey Nazarkin:

 DT> Потом обрабатывать c-файл специальной маленькой утилитой, "экстрагируя" из
 DT> неё h-файл.  А утилиту эту вызывать с помощью make, объявив зависимость
 DT> h-файлов от соответствующих c-файлов.

gcc, softune (fujitsu) yмеют анализиpовать деpево вложенных хидеpов.
подсовывая его гнyсномy мейкy, все полyчается кpасиво.

Alexey

Hi Alexey.

19 Sep 2003, 12:39, Alexey Musin writes to Dimmy Timchenko:

 AM> gcc, softune (fujitsu) yмеют анализиpовать деpево вложенных
 AM> хидеpов. подсовывая его гнyсномy мейкy, все полyчается кpасиво.

Собственно, многие компиляторы (и тот же IAR C) умеют выдавать список
зависимостей.  А моя идея ещё немного расширяет такую автоматизацию.

Hеудобство тут в том, что мы пытаемся автоматизировать то, что в языке
реализовано как "ручное".  А если б были модули, всё это обрабатывалось бы
компилятором совершенно прозрачно, и нам ничего не надо было бы знать про
"проекты", h-файлы, зависимости, линковку.


Dimmy.

Hi Dimmy!
You wrote to Alexey Musin on Fri, 19 Sep 2003 11:44:03 +0400:

AM>> gcc, softune (fujitsu) yмеют анализиpовать деpево вложенных
AM>> хидеpов. подсовывая его гнyсномy мейкy, все полyчается кpасиво.

DT> Собственно, многие компиляторы (и тот же IAR C) умеют выдавать список
DT> зависимостей.  А моя идея ещё немного расширяет такую автоматизацию.

DT> Hеудобство тут в том, что мы пытаемся автоматизировать то, что в языке
DT> реализовано как "ручное".  А если б были модули, всё это обрабатывалось бы
DT> компилятором совершенно прозрачно, и нам ничего не надо было бы знать про
DT> "проекты", h-файлы, зависимости, линковку.

    Все же непонятно, как же будет осуществляется раздельная компиляция?

Вот есть функция:

void slon(int x, char* pC) { ... // }

    Она, к примеру, в src1.c.

    Теперь в src2.c мы хотим ее использовать:

void f()
{
    char buf[16];

    ... //

    slon(2, buf);

}

    Hо для этого мы должны объявить прототип, чтобы компилятор мог проверить
правильность использования. Механизм #include упрощает и устраняет проблемы
синхронизации при задании прототипа. А ты как предлагаешь решить эту задачу?

Bye.

P.S. Кстати, если заглянуть сюда: http://sourceforge.net/projects/avr-ada/ и
http://avr-ada.sourceforge.net/, то можно предположить, что скоро и на твоей
улице будет праздник! :-)


### Обидно, когда твои мечты сбываются у других!

Hi Harry.

19 Sep 2003, 21:37, Harry Zhurov  writes to Dimmy Timchenko:

 HZ> Все же непонятно, как же будет осуществляется раздельная
 HZ> компиляция?

Точно так же, как и раньше, только "исходник" h-файла будет находиться в начале
c-файла.  В одном флаконе.  Просто для удобства восприятия и редактирования.  И
на паскалевский юнит будет смахивать. :)

 HZ> Вот есть функция:

 HZ> void slon(int x, char* pC) { ... // }

 HZ>     Она, к примеру, в src1.c.

Вот в src1.c и пишем

/*HEADER BEGIN*/

extern void slon(int x, char* pC);

/*HEADER END*/


В эту секцию помещаем всё, что поместили бы в h-файл.  Можно таких секций
делать несколько, если надо сформировать несколько h-файлов, относящихся к
одному исходнику.


 HZ> Теперь в src2.c мы хотим ее использовать:

А тут пишем, как обычно, #include src1.h.  Ведь этот файл будет сгенерирован
make с помощью специальной утилитки.

Я вообще люблю такие доработки.  Hапример, ещё когда в 80-е работал с
ассемблером i8080, написал для него "структурные" макросы.  Потом переносил их
и на ассемблеры x86 и x51.

 HZ> P.S. Кстати, если заглянуть сюда:
 HZ> http://sourceforge.net/projects/avr-ada/ и
 HZ> http://avr-ada.sourceforge.net/

:)  Спасибо.  Только там, как я понял, всё в зачаточном виде...


Dimmy.

Sat Sep 20 2003 11:05, Dimmy Timchenko wrote to Harry Zhurov:

 HZ>> Все же непонятно, как же будет осуществляется раздельная
 HZ>> компиляция?

 DT> Точно так же, как и раньше, только "исходник" h-файла будет находиться в
 DT> начале c-файла.  В одном флаконе.  Просто для удобства восприятия и
 DT> редактирования.  И на паскалевский юнит будет смахивать. :)

 Как было справедливо замечено AD, на Сях это можно сделать через
 условную компиляцию. Только в начале зависимых файлов
 надо будет писать не "#include *.h" а "#include *.c",
 и откусывать ненужные части.

 VLV

Hello, Vladimir!
You wrote to Dimmy Timchenko on Sat, 20 Sep 2003 15:51:35 +0400:

 VV>  Как было справедливо замечено AD, на Сях это можно сделать через
 VV> условную компиляцию.

    Я не это имел в виду! :-)))

 VV> Только в начале зависимых файлов   надо будет писать не "#include *.h"
 VV> а "#include *.c",   и откусывать ненужные части.

    В проекте, который мне сейчас приходится сопровождать, некий нехороший
человек написал так (во всех местах :-( ):
=== <db.h> ===
/* ... */
#ifdef _DB_C_
#define GLOBAL
#else
#define GLOBAL extern
#endif
/* */
GLOBAL int prarm;
GLOBAL uint32 get_db_first_byte();
/* */
#undef GLOBAL
=== </db.h> ===

=== <db.c> ===
#define _DB_C_
#include "db.h>
#include "wr.h"
=== </db.c> ===

Найти место где определяется переменная и её тип бывает очень непросто.
Глубина вложенности хидеров тоже внушаИтЬ. Они мне скоро сниться будут.
    В мейк-файле работа начинается с копирования одного из h-файлов в
другой - в зависимости от указанной цели. А целью является _бренд_ под
который идёт сборка. Поскольку этот файл потом включается всюду, всякий раз
идёт полная перекомпиляция. Спрашивается - а на фига такой мейк?!
Повбывав-бы...

With best regards,
            Alexander Derazhne.

20-Sep-03 17:36 Alexander Derazhne wrote to Vladimir Vassilevsky:

AD>     В проекте, который мне сейчас приходится сопровождать, некий нехороший
AD> человек написал так (во всех местах :-( ):
AD> === <db.h> ===
AD> /* ... */
AD> #ifdef _DB_C_
AD> #define GLOBAL
AD> #else
AD> #define GLOBAL extern
AD> #endif
 М-мать!

Видать человек попытался сунуть int param в h-файл, получил
от линкера "многократное определение" и "с честью вышел из ситуации" :-)
Даже если считать, что компилятор не умеет нормально отрабатывать
extern int param;
int patram;
(что-то я таких компиляторов не видел или уже давно и счастливо забыл),
можно было всё-же переменную определить в c-файле а в h-файле написать

#ifndef _DB_C_
extern int param;
extern uint32 get_db_first_bute();
#endif

AD> Найти место где определяется переменная и её тип бывает очень непросто.
AD> Глубина вложенности хидеров тоже внушаИтЬ. Они мне скоро сниться будут.
AD>     В мейк-файле работа начинается с копирования одного из h-файлов в
AD> другой - в зависимости от указанной цели. А целью является _бренд_ под
AD> который идёт сборка. Поскольку этот файл потом включается всюду, всякий
AD> раз идёт полная перекомпиляция. Спрашивается - а на фига такой мейк?!
 КrЮт0й хакер работал :-) Хадействовал возможности на всю катушку :-))

AD> Повбывав-бы...
 Угу. От "трудов" таких потом во все стороны идут мифы о ненужности
make и глупости C.

wbr,

Hello, Oleksandr!
14:07:36 +0000 (UTC):

 OR>  КrЮт0й хакер работал :-) Хадействовал возможности на всю катушку
 OR> :-))

    Это что... Он смешал "обычное" написание программ (не знаю как это по
научному называется) с event-driven model. Это надо видеть!

 AD>> Повбывав-бы...
 OR>  Угу. От "трудов" таких потом во все стороны идут мифы о ненужности
 OR> make и глупости C.

    В другом проекте (C++, Java) дела пошли на лад только после того как
вычистили последние следы его деятельности. Так-что это языковонезависимо
:-)).

With best regards,
            Alexander Derazhne.

Hello Harry.

19 Sep 03 21:37, Harry Zhurov wrote to Dimmy Timchenko:

 HZ> P.S. Кстати, если заглянуть сюда: http://sourceforge.net/projects/avr-ada/
 HZ> и http://avr-ada.sourceforge.net/, то можно предположить, что скоро и на
 HZ> твоей улице будет праздник! :-)

а пока:      :)

=== Begin Windows Clipboard ===
The compiler crashes very often!
=== End Windows Clipboard ===

Alexey

Привет!

 DT>> Потом обрабатывать c-файл специальной маленькой утилитой, "экстрагируя"
 DT>> из  неё h-файл.  А утилиту эту вызывать с помощью make, объявив
 DT>> зависимость  h-файлов от соответствующих c-файлов.

 AM> gcc, softune (fujitsu) yмеют анализиpовать деpево вложенных хидеpов.
 AM> подсовывая его гнyсномy мейкy, все полyчается кpасиво.

 Hе вводи пользователей Softune в заблуждение. Формат файла зависимостей
Softune несколько отличается от gnu make, чтоб все было красиво необходимо
выполнить пару операций.

 Еще существует забытая утилита makedepend из комплекта X11. Она формирует
файл зависимостей в формате gnu make. Собрал ее win-версию для работы с
компиляторами, которые не умеют создавать списки зависимостей. Если кому надо,
сообщите - выложу на ftp.

_______
Сергей.

Пpивет Sergey !

 SP>  Еще существует забытая утилита makedepend из комплекта X11. Она
 SP> формирует
 SP> файл зависимостей в формате gnu make. Собрал ее win-версию для работы с
 SP> компиляторами, которые не умеют создавать списки зависимостей. Если кому
 SP> надо,
 SP> сообщите - выложу на ftp.

Вот что я нашел в портированном дистрибутиве winavr(gcc)

*#────────────────── begin of Windows Clipboard ──────────────────#*
# Automatically generate C source code dependencies.
# (Code originally taken from the GNU make user manual and modified (See
README.txt Credits).)
# Note that this will work with sh (bash) and sed that is shipped with WinAVR
(see the SHELL variable defined above).
# This may not work with other shells or other seds.
%.d: %.c
    set -e; $(CC) -MM $(ALL_CFLAGS) $< \
    | sed 's,\(.*\)\.o[ :]*,.o .d : ,g' > $@; \
    [ -s $@ ] || rm -f $@


# Remove the '-' if you want to see the dependency files generated.
-include $(SRC:.c=.d)
*#─────────────────── end of Windows Clipboard ───────────────────#*
Делает тоже самое. Хотя makedepend был бы удобнее в том контексте,  что не
нужно переделывать makefile каких-нибудь уже готовых проектов под *nix.
Поэтому, будь добр, выдожи на ФТП.

With best regards,
    Sergey

Hello Sergey.

Понедельник Сентябрь 22 2003 07:43, you wrote to Alexey Musin:

 SP>  Еще существует забытая утилита makedepend из комплекта X11. Она
 SP> формирует файл зависимостей в формате gnu make. Собрал ее win-версию
 SP> для работы с компиляторами, которые не умеют создавать списки
 SP> зависимостей. Если кому надо, сообщите - выложу на ftp.

 Вот если бы она оказалась еще и С-препроцессором, было бы замечательно.
Почему-то отдельный препроцессор мне не попадался, а использовать тот же gcc в
виде препроцессора кажется неразумным.

Leha

Привет!

 SP>>  Еще существует забытая утилита makedepend из комплекта X11. Она
 SP>> формирует файл зависимостей в формате gnu make. Собрал ее win-версию
 SP>> для работы с компиляторами, которые не умеют создавать списки
 SP>> зависимостей. Если кому надо, сообщите - выложу на ftp.

 LB>  Вот если бы она оказалась еще и С-препроцессором, было бы замечательно.

Так оно и есть в некоторой степени, цитата из man:
(не С-препроцессором, а _с_ С-препроцессором)

DESCRIPTION:
Makedepend reads each sourcefile in sequence and parses it like a
C-preprocessor, processing all #include, #define, #undef, #ifdef,
#ifndef, #endif, #if and #else directives so that it can correctly
tell which #include, directives would be used in a compilation.  Any
#include, directives can reference files having other #include
directives, and parsing will occur in these files as well.

Every file that a sourcefile includes, directly or indirectly, is
what makedepend calls a "dependency".  These dependencies are then
written to a makefile in such a way that make(1) will know which
object files must be recompiled when a dependency has changed.

 LB> Почему-то отдельный препроцессор мне не попадался, а использовать тот же
 LB> gcc в виде препроцессора кажется неразумным.
Завтра постараюсь выложить на ftp.

_______
Сергей.

Привет, уважаемый All!

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

   Задачка такая - контроллер встраиваемого термопринтера. Этот
   принтер относится к классу GDI-устройств (бо зело проще было
   написать  драйвера), то есть весь рендеринг графики производится
   в недрах Windows, по интерфейсу принтера передается уже или текст
   или компрессированная графика. Собственно, уже разработан
   контроллер на базе Mega128-16МГц, но он хорошо (достаточно быстро)
   работает только с узкими термоголовками (2", 3", 4").

   А вот потом пришел _ОН_ - термоголова ширина 8"/200dpi (есть еще варианты
   300 dpi) с улучшенной энергетикой. Эти головы, способны отображать данные
   со скоростью не менее 2 Мбит/сек. При этом интерфейс загрузки у них
   типа SPI (двухканальный) и пропускает до 8 МБит/сек.

   Второе узкое место - интерфейс - сейчас есть варианты RS-232 (до
   460800), USB (кривоватый FTDI232, в итоге тот же RS внутри, зато
   быстро USB "освоил" :-( и Centronics, экономно (но медленно)
   реализованный на сдвиговом регистре с параллельной загрузкой.

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

   Короче, понятно - AVR 16МГц еле дышит (я это предвидел, но мне
   никто не дал ни времени/ни денег реализовывать это нормально, да
   и на узких форматах все более/менее шуршит). Скорость от 2 до 6
   pps формата A4 в зависимости от картинки. Но это не самое плохое.
   Еще хуже то, что процессор не успевает прогружать голову (одновременно
   обрабатывая 50-100К прерываний от интерфейса и декомпрессируя данные),
   при этом падает частота шагов на системе позиционирования (до 50-100
шагов/сек)
   и в системе развиваются приличные механические колебания, мало того
   что это дело начинает шуметь (с модуляцией по плотности поступаемой
   графики), так и резко возрастает износ (шестерни-то капроновые).
  
   Посему, чего же я хотел бы от нового микроконтроллера (в порядке
   убывания приоритета):

   - internal program flash memory - от 64К, ессно ISP;
   - internal RAM - ну пусть от 8К минимум, хотя и напряг;
   - непременно DMA или его аналог (типа DTC у Atmel для UART);
   - SPI (SIO, SCI или чего еще), обязательно с DMA;
   - external DMA channel (для Centronics);
   - UART (DMA желателен, но FIFO тоже поможет, да
     и скорости уже обычно не те);
   - USB-device 1.1, обязательно c DMA, можно low-speed;
   - от 10 МИПС (если будет DMA, то интерфейсы и голову уже
     обслуживать почти не надо, а декомпрессия RLE это простой
     и малокушающий алгоритм);

   Ну еще пожелания (во губу раскатал-то :-)
   - встроенный контроллер внешней DRAM/SDRAM памяти (пару метров RAM
   были бы кстати на будущее);
   - ARM архитектура (хорошо распространена - ИМХО это "аналог"
   i51 среди 8-битников, тоже толпой производителей выпускается,
   с разной периферией). Но с архитектурой уж как повезет, сгодится
   любая другая, лишь бы периферия приличная была.

   Вот такая проблема, месяц неспешно ищу - ничего не попадается, смотрел
   Fujitsu/Hitachi/Mitsubishi/Siemens/ST/Philips/OKI/Samsung/Hynix/Sharp/Cirrus.
   В-основном ARMы. Может, плохо смотрел, или еще где надо поискать?
   Проблема в USB - все еще маловато чипов с ним. Но я уж готов и
   внешний типа USBN9604 ставить. Монстры в >400 pin BGA тоже грустновато
   как-то и у них с внутренним флешом обычно напряг.

What do you think about sharp blades, Leha?

[Answer on] [Leha Bishletov wrote to Sergey Pinigin at [22 Sep 03 14:04]]:

 LB>  Вот если бы она оказалась еще и С-препроцессором, было бы
 LB> замечательно. Почему-то отдельный препроцессор мне не попадался, а
 LB> использовать тот же gcc в виде препроцессора кажется неразумным.
  gcc -- это ведь только драйвер. И он звоет внешний препроцессор cpp, который
выдирается влегкую.
  Сам gcc вообще ничего не умеет, кроме как звать препроцессор, два компилятора
и линкер в правильном порядке и с правильными ключами :)

    Remember, pain is part of pleasure, Leha.
... Что там колышется над твоей головой -/Северный Мост или Южный Крест?

Sergey Pinigin wrote to Alexey Musin on Mon, 22 Sep 2003 07:43:23 +0400:


SP>  Еще существует забытая утилита makedepend из комплекта X11. Она формирует
SP> файл зависимостей в формате gnu make. Собрал ее win-версию для работы с
SP> компиляторами, которые не умеют создавать списки зависимостей. Если кому
SP> надо, сообщите - выложу на ftp.

    Конечно выложи! Только адрес ftp потом скажи? :))


...so long!

### Съисть-то он все ето - съисть, тольки хто ему все ето дасть?

22-Sep-03 07:43 Sergey Pinigin wrote to Alexey Musin:

SP>  Еще существует забытая утилита makedepend из комплекта X11. Она формирует
SP> файл зависимостей в формате gnu make. Собрал ее win-версию для работы с
SP> компиляторами, которые не умеют создавать списки зависимостей. Если кому
SP> надо,
SP> сообщите - выложу на ftp.

Она же есть в комплекте UnxUtils (GNU utilites for Win32,
что особо приятно, работает без cygwin), лежат на

http://unxutils.sourceforge.net/

Там есть make/grep/sed/gawk/zip/unzip/bzip2/which/less
и куча всякого другого добра типа indent (такая форматировалка
C-шных текстов в разных стилях) и uuencode/uudecode.

wbr,