Ошибка в вычислениях адресов у GCC ?

В этом заслуга rar'а, а стандартная команда "cd" это не поймет (под W98).

Это точно ;-)

_______ Сергей.

Да:

- легко организуется компиляция "тонких мест" - могу в одной строке записать что один из 102 файлов компилить с отличными от default ключиками.(не важно где он лежит, и какой build выполняется) - работает с либами.

Все это, в конечном счете расширенные возможности зависимостей.

_______ Сергей.

Э-э-к-хм, что-то я не помню когда ты последний раз появлялся на моей загородной вилле?

Ты будешь первым, таким разносторонним (или неустойчивым в выборе)... ;-)

Hачнем считать.

Здрасте... приплыли ;-)

Условной копиляцией не пользуешься?

Простейший пример:

......

#ifdef DEBUG

#include "dbg.h" static char ver[] = "DBG-1.0."

#else

static char ver[] = "REL-1.0"

#endif

......

makedepend ... -D DEBUG ...

"dbg.h" будет включен в зависимость.

_______ Сергей.

Hello Yuriy.

YK> echo # ----------------------------------- >files.lkf YK> echo # files added by link.bat: >>files.lkf YK> echo # >>files.lkf YK> for %%I in (obj\*.o) do echo %%I >>files.lkf YK> echo # ----------------------------------- >>files.lkf

YK> echo src1 >pdir YK> echo src2 >>pdir YK> del c_obj YK> del asm_obj YK> del all_obj YK> for /F %%I in (pdir) do for %%J in (%%I\*.c) do echo %%~nJ.o >>

YK> c_obj YK> for /F %%I in (pdir) do for %%J in (%%I\*.asm) do echo %%~nJ.o >>

YK> asm_obj copy /b c_obj + asm_obj all_obj

Итого предлагается написать make на bat'е?

Тогда лучше спорить, чем лучше написанная программа, от ненаписанной, но которую можно написать.

ps: Возьмите вместо bat, какой-нить bash или tcsh. Или WSH (Windows Scripting Host)

Alexey

Hello, Sergey Pinigin !

Hе думаю.

С уважением, Дима Орлов.

Доброго здоровья, Alexey!

AVB>>> Я считаю тему интересной, поэтому все-таки расскажи какое именно AVB>>> масштабирование не возможно без перекомпиляции проекта.

ST>> реализация функций может быть выполнена по разным алгоритмам, в ST>> зависимости от наличия/отсутствия определенных возможностей. на уровне ST>> исходников это делается #ifdef`ами, а вот на уровне объектников только ST>> if/else, а это оптимизации линкером не подлежит

AVB> Что мешает нагенерить автоматом либов для разных вариантов конфигурации? AVB> Я не AVB> верю, что для какой-то конкретной платформы их будет больше нескольких AVB> штук. У AVB> меня мейк собирает ось для всех известных процессоров семейства сразу AVB> и раскладывает в разные либы.

ничего не мешает, равно как и ничего не доказывает преимущество этого варианта (при наличии исходников библиотеки)

WBR, Сергей. ICQ: 101347299

Доброго здоровья, Jurgis!

JA>>> Лень - рулез! :) ST>> видимо, я чего-то недопонимаю. я мыслю так - в исходнике ты указываешь ST>> сегмент, в который помещается данный элемент (функция/массив/переменная ST>> и т.п.), а потом в линкерном файле указывается расстановка сегментов по ST>> адресам памяти. собственно, ты описываешь примерно то же самое, тогда ST>> непонятно, какие еще (нестандартные) средства компилятора для этого ST>> нужны, разговор же о них? и причем тут порядок линковки? все нужные ST>> секции либо помещаются в определенную область (порядок тогда не важен), ST>> либо не помещаются, и тогда тоже порядок не важен :)

JA> О порядке линковки я ничего не говорил. Я говорил о том, что гораздо проще JA> переставлять модули (грубо говоря, куски программы) в скрипте линкера, чем JA> задавать их расположение в исходном тексте (посредством указания, в каких JA> сегментах их нужно располагать). В остальном я с тобой согласен :)

удобство сомнительное :) впрочем, на вкус и цвет :)

WBR, Сергей. ICQ: 101347299

... Hоги - лицо женщины.

Mon, 07 Feb 2005 11:41:31 +0300 Sergey Pinigin wrote to Alexey Krasnov:

SP>>> Он у тебя и дефайны обрабатывать умеет ?

SP> Здрасте... приплыли ;-)

SP> Условной копиляцией не пользуешься?

Я тоже думал, что без нее при формировании автозависимостей никак. :)

SP> Простейший пример:

SP> ......

SP> #ifdef DEBUG

SP> #include "dbg.h" SP> static char ver[] = "DBG-1.0."

SP> #else

SP> static char ver[] = "REL-1.0"

SP> #endif

SP> ......

SP> makedepend ... -D DEBUG ...

SP> "dbg.h" будет включен в зависимость.

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

Доброго здоровья, Harry!

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

HZ> Если ты посмотришь выше по дискуссии на эту тему, то увидишь там:

HZ> ========= begin ============== YK>> Приведи пример задачи, которую нельзя решить батником.

HZ> Речь не столько о том, можно или нет, сколько об адекватности HZ> выбранного HZ> средства. Тем же батником ты можешь вызывать самописную утилиту, которая HZ> тебе HZ> обработает весь текст как надо. Только в случае make это не требуется. HZ> Пример: HZ> задаю директории, где лежат сорцы (из реального проекта): HZ> ========= end ================

HZ> Подчеркиваю, речь идет в первую очередь об адекватности средства. А HZ> реализовать можно массой способов. И то, что make самый распростаненный, HZ> указывает на его адекватность.

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

WBR, Сергей. ICQ: 101347299

Если конкретно в ucos-ii то

- режим проверки аргументов (условная компиляция по#define OS_ARG_CHK_EN)

- имена задач (... #defineOS_TASK_NAME_SIZE)

Да это, не самый лучший выход, но другого пока не вижу, в свете embedded/MCU/RTOS.

Hа либы могут влиять потребности собрать проект в режиме

- debug режим и т.п.

- различные ключи компиляции (speed, size).

Если все реализовывать через либы (для каждой платформы), то придется делать кучу либ и следить какую когда использовать. Понятно что это можно, но зачем. К тому же все лежит в исходниках (CVS).

_______ сергей.

Mon, 07 Feb 2005 17:35:08 +0300 Sergey Pinigin wrote to Harry Zhurov:

SP> Harry Zhurov wrote: SP>>>>> Он у тебя и дефайны обрабатывать умеет ?

SP>>> Здрасте... приплыли ;-)

SP>>> Условной копиляцией не пользуешься?

SP> А перестал думать когда исключил для себя из СИ средства препроцессора. SP> Так?

???

SP>>> Простейший пример: SP>>> ...... SP>>> #ifdef DEBUG SP>>> #include "dbg.h" SP>>> static char ver[] = "DBG-1.0." SP>>> #else SP>>> static char ver[] = "REL-1.0" SP>>> #endif SP>>> ......

SP>>> makedepend ... -D DEBUG ...

SP>>> "dbg.h" будет включен в зависимость.

SP> В твоих простейших проектах ...

??? :-\

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

SP> Тебя не интересует что в проекте от чего зависит, на этом можно SP> поставить точку. Все уже поняли твою позицию. ^^^^^

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

??? Ты меня с кем-то перепутал. В любом случае в таком тоне найди себе другого собеседника! Всего хорошего.

Mon, 07 Feb 2005 14:43:06 +0300 Sergei Tuchinski wrote to Harry Zhurov:

HZ>> Подчеркиваю, речь идет в первую очередь об адекватности средства. А HZ>> реализовать можно массой способов. И то, что make самый распростаненный, HZ>> указывает на его адекватность.

ST> судя по горячим спорам, здесь в том числе, об адекватности винды, вывод о ST> следовании адекватности из распространенности следует подвергнуть сомнению ST> :)впрочем, я этого делать не собираюсь

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

Привет!

Mon Feb 07 2005 13:24, Sergei Tuchinski wrote to Jurgis Armanavichius:

JA>> О порядке линковки я ничего не говорил. Я говорил о том, что гораздо JA>> проще переставлять модули (грубо говоря, куски программы) в скрипте JA>> линкера, чем задавать их расположение в исходном тексте (посредством JA>> указания, в каких сегментах их нужно располагать). В остальном я с JA>> тобой согласен :) ST> удобство сомнительное :) впрочем, на вкус и цвет :)

Ты прав :) А удобство я усматриваю в том, что в исходнике ничего не нужно менять, если понадобилось модуль переставить.

Юргис

А перестал думать когда исключил для себя из СИ средства препроцессора. Так?

В твоих простейших проектах ...

Тебя не интересует что в проекте от чего зависит, на этом можно поставить точку. Все уже поняли твою позицию.

_______ Сергей.

Mon Feb 07 2005 12:51, Alexey Boyko wrote to Yuriy K:

YK>> echo src1 >pdir YK>> echo src2 >>pdir YK>> del c_obj YK>> del asm_obj YK>> del all_obj YK>> for /F %%I in (pdir) do for %%J in (%%I\*.c) do echo %%~nJ.o >>

YK>> c_obj YK>> for /F %%I in (pdir) do for %%J in (%%I\*.asm) do echo %%~nJ.o >> YK>> asm_obj copy /b c_obj + asm_obj all_obj

AB> Итого предлагается написать make на bat'е?

Предлагается объяснить преимущества make перед bat. Одно есть: ускорение сборки больших проектов. Приведи еще одно.

AB> ps: Возьмите вместо bat, какой-нить bash или tcsh. Или WSH (Windows AB> Scripting Host)

Зачем?

WBR, Yuriy.

Mon Feb 07 2005 09:27, Sergey Pinigin wrote to Yuriy K:

SP> Да:

SP> - легко организуется компиляция "тонких мест" - могу в одной строке SP> записать что один из 102 файлов компилить с отличными от default SP> ключиками.(не важно где он лежит, и какой build выполняется)

Зачем этот файл надо компилить с другими настройками?

SP> - работает с либами.

Что значит "работает с либами"?

WBR, Yuriy.

Удобный синтаксис для преобразований файлов по расширениям.