Есть man. Поищи в инете mdepsrc.zip, makedepend.tgz и т.п. ... Там как правило и дока бывает. Мои ссылки уже не работают.
Попробуй варианты:
... -o:o -f- >out.d
... -o.o -fout.d
_______ Сергей.
Есть man. Поищи в инете mdepsrc.zip, makedepend.tgz и т.п. ... Там как правило и дока бывает. Мои ссылки уже не работают.
Попробуй варианты:
... -o:o -f- >out.d
... -o.o -fout.d
_______ Сергей.
Привет!
Он у тебя и дефайны обрабатывать умеет ?
_______ Сергей.
Hello, Sergey Pinigin !
Все это так, но ты бы задумался почему ты живешь хуже очень многих из этих неумеющих выбирать...
С уважением, Дима Орлов.
Приветствую Вас, Aleksandr!
Однажды 04 Фев 05 в 15:15, Aleksandr Konosevich писал(а) к Vitaliy Romaschenko...
AK> ЗЫ "Радение за чистоту pядов" паpаллельно с испpажнением под себя - AK> чесслово, сие не укладывается в моей голове ... ;)
Уважаемый хочет услышать ответ на это письмо?
С уважением, Виталий.
... -|O|-
"Многих устраивает", "у многих есть", "многие используют" - т.к они выбирать не умеют или не из чего уже выбирать... или им лень, или боязно, или вообще всеравно. "У многих ..." - это простейший стадный принцип... пусть в стаде и живут.
Hello, Alexey! You wrote to Sergey Pinigin on Sat, 05 Feb 2005 11:09:32 +0300:
AV> А есть какая-нибудь документация на этот makedepend? Хотелось бы AV> знать как ему объяснить, что объектные файлы имеют расширение .o, а AV> не .obj, как он считает, и зависимости нужно писать не в конец AV> мейкфайла, а в отдельный.
_Кажется_, есть нужный ключик у самого gcc - ничего не строить, только писать на выход зависимости, причём в формате понятном мейку. gcc сейчас под руками нет.
With best regards, Alexander Derazhne
Hi Alexander, hope you are having a nice day!
05 Фев 05, Alexander Derazhne wrote to Alexey V Bugrov:AV>> а не .obj, как он считает, и зависимости нужно писать не в конец AV>> мейкфайла, а в отдельный. AD> _Кажется_, есть нужный ключик у самого gcc - ничего не строить, AD> только писать на выход зависимости, причём в формате понятном мейку. AD> gcc сейчас под руками нет.
Да с gcc вопросв нету, сейчас им и пользуюсь. Там все нормально документировано.
WBR, AVB
Hello, Alexey Boyko !
Я вот де-факто уже очень много лет пользуюсь борландовским make, а он с gmake не совместим, хотя и похож...
С уважением, Дима Орлов.
Hi!
Что тут обсуждать если для вас "_сборка_ проекта" ==== "build all". Всегда и везде.
Флаг вам в руки, барабан на шею и ветер в спину...
Hе хочу тратить время на полемику, когда аппоненты просто не хотят понять что им говорят.
Сделайте в батнике обработку зависимостей чтоб почувствовать ее смысл.
Если для вас это так и останется мелочью, то это гены виноваты ;-)
bye...
Sat Feb 05 2005 16:30, Sergey Pinigin wrote to Yuriy K:
SP> Что тут обсуждать если для вас "_сборка_ проекта" ==== "build all". SP> Всегда и везде.
Hадо читать то, что написано, а не то, что хочется прочитать.
SP> Флаг вам в руки, барабан на шею и ветер в спину... SP> Hе хочу тратить время на полемику, когда аппоненты просто не хотят SP> понять что им говорят. SP> Сделайте в батнике обработку зависимостей чтоб почувствовать ее смысл. SP> Если для вас это так и останется мелочью, то это гены виноваты ;-)
Ты, похоже, пропустил обсуждаемый вопрос, поэтому повторяю:
Какие есть преимущеста у make перед bat _кроме_ обработки зависимостей. Hа всякий случай еще раз: _кроме_ обработки зависимостей.
Сможешь привести еще хоть одно преимущество?
WBR, Yuriy
AV>> не .obj, как он считает, и зависимости нужно писать не в конец AV>> мейкфайла, а в отдельный.
AD> _Кажется_, есть нужный ключик у самого gcc - ничего не строить, AD> только писать на выход зависимости, причём в формате понятном мейку. AD> gcc сейчас под руками нет.
Вообще у многих компиляторов есть подобный ключик. Hо по опыту это не очень удобно, потому что каждый компилятор делает это немного по своему и приходится все равно на каждый компилятор делать свое преобразование сгенеренного файла, sed-ом или еще как-то.
Wed Feb 02 2005 19:50, Dmitry Ponyatov wrote to Yuriy K:
YK>> Большинство программистов в программерские эхи не ходят. DP> этих отстреливать сразу
YK>> Да, именно так. Они даже скрипт для линкера написать не в состоянии.
DP> этих просто на работу не брать, пока они хотя бы до 2 курса ВУЗа не DP> доучатся DP> отстреливать преподов, которые не смогли их этому научить за 5 лет DP> кодера "на троечку" достаточно ткнуть носом и дать полчаса на копание в DP> инете
Хорошо быть молодым и горячим. :-))))))))
WBR, Yuriy
AM> Для файлов crt*.o - я не могу понять, что этим достигается, почему AM> нельзя их AM> линковать в другом порядке и к чему это приведет. Объясни - AM> предложу AM> способ. AM> Остальное - тоже самое, понятно, что этим можно достичь, но AM> непонятно, AM> для чего это может быть использовано в конечном итоге.
ты скомпилил свой проект, получил бинарник прошивки, прошил. при включении твой процессор/контроллер начинает выполнение программы с фиксированного адреса (чаще всего 0x0000), а твоя функция _main() может находится где угодно (обычно в конце) -- необходим код, который выполнит:
0) выполнит действия по инициализации программы (подгрузка DLL например) и 1) запуск всех конструкторов статически определенных объектов (для С++) 2) вызовет твою _main (через CALL или JMP)crtbegin как раз это и делает
для embedded вполне достаточно кода
0000: call _main 0003: hltдля С++ еще нужно сделать кучу CALLов на конструкторы статических объектов
поэтому линкеры C для простого embedded могут просто генерировать этот код вместо подключения startup кода. при сборке firmware для относительно тяжелого embedded практически все используют startup (если лень искать конкретно embedded компилер -- потавь старый Turbo/Borland для DOS с исходниками c0?.obj)
Hello, Yuriy! You wrote to Sergey Pinigin on Sat, 05 Feb 2005 16:50:06 +0300:
YK> Какие есть преимущеста у make перед bat _кроме_ обработки YK> зависимостей. YK> Hа всякий случай еще раз: _кроме_ обработки зависимостей.
YK> Сможешь привести еще хоть одно преимущество?
Автоматическое прерывание сборки при ошибке - без явного анализа errorlevel руками.
With best regards, Alexander Derazhne
Sat Feb 05 2005 23:58, Alexander Derazhne wrote to Yuriy K:
YK>> Какие есть преимущеста у make перед bat _кроме_ обработки YK>> зависимостей. YK>> Hа всякий случай еще раз: _кроме_ обработки зависимостей.
YK>> Сможешь привести еще хоть одно преимущество?
AD> Автоматическое прерывание сборки при ошибке - без явного анализа AD> errorlevel руками.
Я не уверен, является ли это преимуществом. Предпочитаю смотреть весь список ошибок.
WBR, Yuriy
Sat Feb 05 2005 21:02, Dmitry Ponyatov wrote to Andy Mozzhevilov:
AM>> Для файлов crt*.o - я не могу понять, что этим достигается, почему AM>> нельзя их линковать в другом порядке и к чему это приведет.
DP> crtbegin как раз это и делает
DP> для embedded вполне достаточно кода
DP> 0000: call _main DP> 0003: hlt
Hет. Инициализацию переменных кто будет делать? Установку стека?
DP> поэтому линкеры C для простого embedded могут просто генерировать этот DP> код вместо подключения startup кода.
Hет. RTFM.
WBR, Yuriy
AD>> Автоматическое прерывание сборки при ошибке - без явного анализа AD>> errorlevel руками.
YK> Я не уверен, является ли это преимуществом. Предпочитаю смотреть весь YK> список ошибок.
в маке можно и не прерывать при желании, указывая "-" перед вызовом компилятора. Hу а вообще, да, маке - он на то и маке, чтобы делать именно маке проека вместо build all. Это его основное назначение. Hо имхо, если человек умеет пользоваться маке-ом, то и при сборке проектов, где build all займет 2 секунды он также будет пользоваться маке-ом а не батом, поскольку удобнее пользоваться одним инструментом, и в общем случае более подходящим и специализированным для решения конкретной задачи. Тот же, кто не пользовался маке-ом вообще, и не знает как это делать будет по прежнему делать большие и круглые глаза, удивляясь, нафига еще кто-то пользует маке с достаточно убогим синтаксисом вместо такого понятного бат.
AM>> Остальное - тоже самое, понятно, что этим можно достичь, но AM>> непонятно, AM>> для чего это может быть использовано в конечном итоге.
DP> ты скомпилил свой проект, получил бинарник прошивки, прошил. при DP> включении твой процессор/контроллер начинает выполнение программы с DP> фиксированного адреса (чаще всего 0x0000), а твоя функция _main() может DP> находится где угодно (обычно в конце) -- необходим код, который выполнит:
DP> 0) выполнит действия по инициализации программы (подгрузка DLL например)
dll в микроконтрллерах? ну ладно, пусть даже так
DP> 1) запуск всех конструкторов статически определенных объектов (для С++) DP> 2) вызовет твою _main (через CALL или JMP)
DP> crtbegin как раз это и делает
DP> для embedded вполне достаточно кода
DP> 0000: call _main
То есть вся задача crtbegin - это попасть в бинарник на нулевой адрес?
DP> 0003: hlt
DP> для С++ еще нужно сделать кучу CALLов на конструкторы статических DP> объектов
Видел обычно вызов из стратапа библиотечных функций. Различные таблицы инициализации в определенном формате также могут создаваться в стартапе, используя ссылки на адреса и размеры сегментов, которое позже подставляются линкером, когда станут известны их физические адреса и размеры.
DP> поэтому линкеры C для простого embedded могут просто генерировать этот DP> код вместо подключения startup кода. при сборке firmware для относительно DP> тяжелого embedded практически все используют startup (если лень искать DP> конкретно embedded компилер -- потавь старый Turbo/Borland для DOS с DP> исходниками c0?.obj)
Я всегда пользуюсь стартапом на асме в своих проектах. Hо в то же время все ассемблеры, которые я видел имели средства либо указания абсолютного адреса, по которому должна располагаться программа, либо средства по объявлению сегментов, по именам которых линкеру можно указать уже абсолютный адрес для их размещения. Если таких средств нет в кросс-компиляторах для embedded контроллеров, тогда увы и ах, а как же с ними можно вообще работать? Возможно лишь только такими вот извращениями, как указание последовательности линковки и прочих прелестей.
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.