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

Конечно, очень просто, замени все "\" на "/"... Кстати, пользую несколько отличную конструкцию: -I path1 -I path2 ...

_______ Сергей.

Reply to
Sergey Pinigin
Loading thread data ...

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

Это точно ;-)

_______ Сергей.

Reply to
Sergey Pinigin

Да:

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

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

_______ Сергей.

Reply to
Sergey Pinigin

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

Reply to
Sergey Pinigin

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

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

Reply to
Sergey Pinigin

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

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

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

......

#ifdef DEBUG

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

#else

static char ver[] = "REL-1.0"

#endif

......

makedepend ... -D DEBUG ...

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

_______ Сергей.

Reply to
Sergey Pinigin

Hello Yuriy.

06 Feb 05 17:56, you wrote to Harry Zhurov:

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

Reply to
Alexey Boyko

Hello, Sergey Pinigin !

Hе думаю.

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

Reply to
Dima Orlov

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

04 Feb 05 19:31, Alexey V Bugrov написал для Sergei Tuchinski:

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

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

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

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

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

Reply to
Sergei Tuchinski

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

05 Feb 05 00:31, Jurgis Armanavichius написал для Sergei Tuchinski:

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

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

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

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

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

Reply to
Sergei Tuchinski

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" будет включен в зависимость.

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

Reply to
Harry Zhurov

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

06 Feb 05 12:50, Harry Zhurov написал для Sergei Tuchinski:

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

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

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

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

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

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

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

Reply to
Sergei Tuchinski

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

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

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

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

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

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

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

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

_______ сергей.

Reply to
Sergey Pinigin

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> поставить точку. Все уже поняли твою позицию. ^^^^^

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

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

Reply to
Harry Zhurov

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

[...]

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

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

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

Reply to
Harry Zhurov

Привет!

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

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

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

Юргис

Reply to
Jurgis Armanavichius

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

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

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

_______ Сергей.

Reply to
Sergey Pinigin

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.

Reply to
Yuriy K

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

SP> Да:

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

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

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

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

WBR, Yuriy.

Reply to
Yuriy K
2005-02-07, Yuriy K snipped-for-privacy@taekwondo.co.nz> пишет:

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

Reply to
Ilya Anfimov

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.