- Vote on answer
- posted
19 years ago
Ошибка в вычислениях адресов у GCC ?
- Vote on answer
- posted
19 years ago
Hello Yuriy.
07 Feb 05 19:09, you wrote to me:AB>> Итого предлагается написать make на bat'е? YK> Предлагается объяснить преимущества make перед bat. YK> Одно есть: ускорение сборки больших проектов. YK> Приведи еще одно.
При использовании make не нужно писать его функциональность на bat-файлах.
AB>> ps: Возьмите вместо bat, какой-нить bash или tcsh. Или WSH AB>> (Windows Scripting Host) YK> Зачем?
Hу, на них писать удобнее, чем на bat.
Alexey
- Vote on answer
- posted
19 years ago
Mon Feb 07 2005 19:42, Ilya Anfimov wrote to Yuriy K:
IA> Удобный синтаксис для преобразований IA> файлов по расширениям.
Удобный? 8-0 Оно конечно, на вкус и на цвет... Мне цикл for гораздо понятней.
WBR, Yuriy.
- Vote on answer
- posted
19 years ago
SP> В этом заслуга rar'а, а стандартная команда "cd" это не поймет (под SP> W98). Даже не rar-а. Специально только что перегрузился в 98-ю и проверил.
// foo.c #include <stdio.h>
int main(int ac, char **av) { FILE *fp; if(ac < 3) return 1; fp = fopen(av[1], "wt"); if( !fp) { puts("A-a-a!"); return 1; } fprintf( fp, "%s", av[2]); fclose(fp); return 0; }
c:\>foo c:/temp/foo.txt Kwa!
Прекрасно создало файл foo.txt в каталоге c:/temp и записало в него что просили.
Многое виндовое встроенное просто по прямому слешу ключ ждёт, вот и не берёт его в именах файлов.
WBR,
- Vote on answer
- posted
19 years ago
SP> Да:
SP> - легко организуется компиляция "тонких мест" - могу в одной строке SP> записать что один из 102 файлов компилить с отличными от default SP> ключиками.(не важно где он лежит, и какой build выполняется) И что тоже можно сделать в батнике, если уж упираться в вопрос "а что такого моежт make, что не может bat". Но только задавая правила, а не действия - на мой взгляд это сделать проще.
Wbr,
- Vote on answer
- posted
19 years ago
MP>>> А как можно в этих 200 файлах разбиратся, что в каком? OR>> А зачем??? MP> Элементарно - для поддержки проекта. Тьху ты, это я глюкнул. Имелось ввиду зачем для этого (разбора/поддержки) держать всё в одном файле?.
MP> Все без проблем находится в одном MP> исходнике размером меньше в 4 раза чем было и понятнее в 5 раз. Ну а я хочу сказать, что всё без проблем находится и в толпе исходников, только раньше нужно было какие-то телодвижения сделать (прикрутить к Qedit несколько макросов на горячие клавиши и grep вытащить в доступное по path место), а сейчас любой минимально-приличный программистский редактор это сам умеет.
OR>> И ещё был макрос, который хватал слово под курсором и открывл файл с OR>> таким именем - это уже для хождения по выдаче grep. MP> А я тогда искал входы в процедуры через ctrl+f в том-же qedit в исходнике MP> максимум из 3 файлов и не знал про существование таких заморочек ;) Кстати, вот как раз *тогда* make экономил время пересборки даже на мелких проектах во много раз. Особенно на дискетах :-)
OR>> Так что поиск - не аргумент, и я не пойму, зачем держать всё в одном OR>> мегабайтном файле? MP> Hе знаю - привычно как-то. А мне привычно через make. И даже если сейчас время build all занимает несколько секунд, а время make - одну - мне гораздо проще и привычнее задавать правила функционирования, чем конкретные действия.
MP> Я всю осмысленную инфо держу всегда в одном файле, И тут так - или считать, что в новый проект тащить что-то из старого (aka выделять общие между несколькими проектами куски в отдельные файлы) - это плохо и неправильно, или начинать новый проект с копирования старых исходников в отдельный каталог и кромсания их.
OR>> зависит. Если foo.obj свежее всех, то ничего не делаем. Иначе OR>> перекомпилируем его. OR>> И так 190 раз, но только для 10 файлов будет вызвана перекомпиляция. MP> Я почему-то не уверен что все это радикально ускорит работу. Сборку небольшого проекта (у меня сейчас все такие)? Ускорит радикально, но незаметно :-) В 3 раза - радикально? Радикально. С 6 секунд до 2 - заметно? Да не очень.
MP> Среднепаршивый проект собирается весь за секунды, а на изучение синтаксиса MP> make MP> для создания правильных файлов в целом можно не один день жизни потратить. MP> Выгода сомнительна. Лучше купить лишний жирный процессор винт побыстрее MP> и памяти побольше ;) С одной стороны да. Скажем, по этой причине я когда-то обломился прикручивать make к pcad4.5 :-) Но факт - тогда для многолистовой схемы с изменением на одном листе через make изменения в плату вбрасывались в разы быстрее, чем через сгенерённый PCECO батник. А с другой - почему-то если зашивка процессора сокращается с 10 секунд до
5, то народ радуется, а вот растянуть сборку с 5 до 10 - так вроде бы и нормально.wbr,
- Vote on answer
- posted
19 years ago
Hello, Yuriy! You wrote to Sergey Pinigin on Mon, 07 Feb 2005 19:21:17 +0300:
SP>> - легко организуется компиляция "тонких мест" - могу в одной SP>> строке записать что один из 102 файлов компилить с отличными от SP>> default ключиками.(не важно где он лежит, и какой build SP>> выполняется)
YK> Зачем этот файл надо компилить с другими настройками?
А вот именно его надо. Например, низ-зя, ни при какой погоде, включать оптимизацию. И только для него.
P.S. Если отвлечься от bat как от эмэсовского расширения и взять более другие командные процессоры (sh, 4dos, etc.), то на них действительно можно реализовать всю функциональность мейка, и его наличие в готовом виде останется единственным преимуществом, но каким!! :-)))
With best regards, Alexander Derazhne
- Vote on answer
- posted
19 years ago
AM>>> Hо имхо, если человек умеет пользоваться маке-ом, то и при сборке AM>>> проектов, где build all займет 2 секунды он также будет пользоваться AM>>> маке-ом а не батом, Я скорее такой. Для сложной работы всё равно make, так чего ещё батники заводить?
DO>> А вот не факт. Я в зависимости от ситуации и настроения пользуюсь и make и DO>> bat и ide.
SP> Ты будешь первым, таким разносторонним (или неустойчивым в выборе)... SP> ;-)
SP> Hачнем считать. Но справедливости ради хочу сказать, что в Altera MAX+II я работаю то по-разному в зависимости от того, что делаю.
Любое сложное (сложнее исправления нескольких строк) редактирование, любая работа без симуляции (отредактировал/зашил/полез с осциллографом) либо наоборот - с длинной симуляцией, когда всё равно долго свёрнутым болтаться будет - это MED+make+maxplus2.exe+jam-palyer+свой загрузчик flex по RS232 через набортный процессор устройства.
Всё остальное - max2win.exe
wbr,
- Vote on answer
- posted
19 years ago
Hello, Oleksandr!
Пон Фев 07 2005, Oleksandr Redchuk писал к Maxim Polyanskiy по поводу "Re: Ошибка в вычислениях адресов у GCC ?." MP>>>> А как можно в этих 200 файлах разбиратся, что в каком? OR>>> А зачем??? MP>> Элементарно - для поддержки проекта. OR> Тьху ты, это я глюкнул. OR> Имелось ввиду зачем для этого (разбора/поддержки) держать всё в одном OR> файле?. Да это банально удобно. При том-же поиске ты сразу c одного нажатия видишь искомое в контексте программы, а не список из файлов где оно есть. OR> Hу а я хочу сказать, что всё без проблем находится и в толпе OR> исходников, Видно что есть, но не видно, что вокруг, а это сильно ускоряет работу. Предположим некая процедура передает неправильные параметры - чтоб найти откуда она с ними вызывается придется облазить все найденные файлы, куча лишних нажатий на кнопки, время. OR> только раньше нужно было какие-то телодвижения сделать OR> (прикрутить к Qedit несколько макросов на горячие клавиши и grep OR> вытащить в доступное по path место), а сейчас любой OR> минимально-приличный программистский редактор это сам умеет. OR> Кстати, вот как раз *тогда* make экономил время пересборки даже на OR> мелких проектах во много раз. Особенно на дискетах :-) Собираю тут фигню в C18, через make она собирается за 6 сек через build all за
- Линкер работает чуть-ли не тормознее компиллера. В асме то-же собрается за 1 сек, нафиг make ;). MP>> Я всю осмысленную инфо держу всегда в одном файле, OR> И тут так - или считать, что в новый проект тащить что-то из старого OR> (aka выделять общие между несколькими проектами куски в отдельные OR> файлы) - это плохо и неправильно, или начинать новый проект с OR> копирования старых исходников в отдельный каталог и кромсания их. Hужные куски выдираются из старого по copy-paste. _HУЖHЫЕ КУСКИ_ а не сборище хламовых библиотек и помойки в хидерах от старого проекта скопиронного по F5 в новую дир. MP>> Я почему-то не уверен что все это радикально ускорит работу. OR> Сборку небольшого проекта (у меня сейчас все такие)? Ускорит OR> радикально, но незаметно :-) В 3 раза - радикально? Радикально. С 6 OR> секунд до 2 - заметно? Да не очень. Да с 8 до 6 у меня выходит в проекте из 7 файлов. Hу с большим натягом на одном файле с 8 до 5. Даже не в 2 раза короче. OR> С одной стороны да. Скажем, по этой причине я когда-то обломился OR> прикручивать make к pcad4.5 :-) Hо факт - тогда для многолистовой OR> схемы с изменением на одном листе через make изменения в плату OR> вбрасывались в разы быстрее, чем через сгенерённый PCECO батник. А с OR> другой - почему-то если зашивка процессора сокращается с 10 секунд до OR> 5, то народ радуется, а вот растянуть сборку с 5 до 10 - так вроде бы OR> и нормально. Главное чтоб зашивка автоматом происходила после успешной сборки. Потом ты шил скажем 400 процессоров за присест? Мне приходилось... Там каждая лишняя секунда
- увеличение времени на задачу. OR> /* Oleksandr Redchuk, Brovary, Ukraine */ WBR! Maxim Polyanskiy.
- Vote on answer
- posted
19 years ago
Tue, 08 Feb 2005 09:14:50 +0300 Sergey Pinigin wrote to Harry Zhurov:
[...]SP> А теперь спокойно опишу тот случай, когда мне неудобны включения SP> ненужных файлов.
SP> 1. Рабочая копия проекта содержит _только_ необходимые для его сборки SP> файлы: SP> - файлы самого проекта SP> - "внешние" файлы (платформа, драйвера, библиотеки и т.п.)
SP> 2. Во внешнем файле имеется "закрытая" дефайном ссылка на файл, SP> который не может быть использована в текущем проекте - файла нет в SP> рабочей копии проекта.
SP> Выполеняем make: SP> - вариан1: построение зависимостей выполнится _с учетом_ #ifdef - "all SP> ok"- вариан2: построение зависимостей выполнится БЕЗ УЧЕТА #ifdef - "нет SP> правила для создания того файла который не нужен..."
Это понято. С этим не спорю. Есть такое ограничение, что любой файл, указанный в #include, должен существовать, иначе make выдаст ошибку.
SP> Снова понятно что можно не пользоваться условными включениями, но SP> иногда без этого обойтись трудно. Да и зачем себя ограничивать если SP> вопрос легко решается?
Хм, насколько легко? Я немного сталкивался как раз с этими вопросами, даже начал писать поддержку дефайнов (а также были попытки использовать сторонние компиляторы для генерации автозависимостей). Но уперся в одно фундаментальное ограничение: как объяснили батоны, единственный стопроцентно корректный путь для генерации автозависимостей - это использовать родной компилятор для оной цели, т.к. только он "знает" все дефайны. Ведь он может внутри себя определять еще энное количество дефайнов. Например, в заголовке от IAR'овского пакета есть такое:
#if !(__IAR_SYSTEMS_ICC__) && !defined(__IAR_SYSTEMS_ASM__) #error This file should only be compiled with iccavr,icca90 or aavr. #endif /* !(__IAR_SYSTEMS_ICC__ > 2) && !defined __IAR_SYSTEMS_ASM__ */
где __IAR_SYSTEMS_ICC__ и __IAR_SYSTEMS_ASM__ - макросы, определенные компилятором и ассемблером означенного пакета. Когда я пытаюсь, например, использовать GCC с ключиком -MM, чтобы сгенерить автозависимости, то получаю (и совершенно справедливо) ошибку.
Можно, конечно, все эти переменные самому руками указать, но это уже кривизна. И нет гарантии, что в следующей версии пакета все это не поменяется.
Поэтому тут, имхо, два пути.
Первый: использовать родной компилятор - наиболее корректный, но почти не портабельный и не позволяющий, как правило, обрабатывать не свои файлы - ассемблерные, например.
Второй: использовать стороннюю утилиту - приводит к некоторым ограничениям (к необходимости держать все файлы, указанные в инклюдах, в одном случае; к необходимости так или иначе определить требуемые макросы, в другом; возможно, есть и еще что-то, навскидку пока не вижу ).
Что для себя выбрать, каждый решает сам. Я выбрал стороннюю утилиту без заморачивания на макросах, необходимость иметь все файлы неудобств не доставляет. Из достоинств:
[1] Возможность задавать расширение объектных файлов. [2] Выходной формат в виде (опционально):main.r43 main.d : D:\Pro\TV\LTPM\430\Src\main.cpp \ D:\CAD\IAR\IDE400\430\inc\dlib\DLib_Defaults.h \ D:\CAD\IAR\IDE400\430\inc\dlib\DLib_Product.h \ ... \ D:\CAD\IAR\IDE400\430\inc\dlib\yvals.h \
т.е. не надо вызывать никакие sed'ы для обработки вывода тулзы автогенерации.
[3] Возможность обрабатывать не только С/С++ файлы, но и асмовые. [4] Возможность задавать для обработки только заголовки в кавычках (игнорировать те, которые в угловых скобках), хотя это мелочь.Если есть еще какие-то достойные внимания пути решения этой проблемы, с интересом выслушаю.
- Vote on answer
- posted
19 years ago
Hello Maxim.
08 Feb 05 04:29, Maxim Polyanskiy wrote to Oleksandr Redchuk:MP>>>>> А как можно в этих 200 файлах разбиратся, что в каком? OR>>>> А зачем??? MP>>> Элементарно - для поддержки проекта.
OR>> Тьху ты, это я глюкнул. OR>> Имелось ввиду зачем для этого (разбора/поддержки) держать всё в OR>> одном файле?.
MP> Да это банально удобно. При том-же поиске ты сразу c одного нажатия MP> видишь искомое в контексте программы, а не список из файлов где оно MP> есть.
Редактоp выбеpи адекватный. У меня ctrl-Shift-Enter - выводит список фyнкций, define, typedef в текyщем файле, если надо, можно нажать галочкy project и полyчить список по пpоектy. Hо pеально по пpоектy этим pедко пользyюсь, потомy что: Ctrl-Enter на любом опpеделенном имени (бyдь то фyнкция, define, typedef) вызывает пеpемещение в место объявления, Alt-Enter - назад. Все дейстyет по пpинципy стека, то есть можешь yскакать сколь yгодно далеко по опpеделениям, а потом веpнyться назад. Пpи ноpмальной оpганизации пpоекта (а не когда все пеpеменные только глобальные) pеальная необходимость найти что-то во всех файлах пpоекта возникает, но не так часто. Скоpее всего это что-то вpоде "посмотpеть, откyда вызывается вот эта фyнкция". В этом слyчае я yже вижy имена модyлей, где есть вызов, и мне зачастyю не особо нyжно даже откpывать этот файл.
OR>> Hу а я хочу сказать, что всё без проблем находится и в толпе OR>> исходников, MP> Видно что есть, но не видно, что вокруг, а это сильно ускоряет работу.
Вокpyг, как пpавило, видно только в пpеделах 20-40 стpок, котоpые одновpеменно yмещаются на экpане. Остальной поиск делается гоpячими кнопками, и его вpемя пpактически не зависит от того, в этом же файле находится искомый фpагмент или в дpyгом.
MP> Предположим некая процедура передает неправильные параметры - чтоб MP> найти откуда она с ними вызывается
Если пpоцедypа паpаметpы пеpедает, то она не может с ними вызываться. И если ты имеешь ввидy, что вот этy пpоцедypy кто-то вызывает с непpавильными паpаметpами, то дpyгого способа пpовеpить нет, как найти по файлy(файлам) места ее вызова, тогда возможно бyдет быстpее и пpойтись только по одномy файлy поиском слова Ctrl-F, а возможно бyдет быстpее вывести в отдельное окно список найденных стpок с именем этой пpоцедypы, и пpи наличии адекватных имен пеpеменных бyдет сpазy видно, где и что напyтано. Только не надо мне говоpить, что тебе нyжно посмотpеть еще 10 стpок выше, чтобы опpеделить что там пеpедается.
MP> придется облазить все найденные файлы, куча MP> лишних нажатий на кнопки, время.
А если ты стоишь на вызове пpоцедypы и хочешь пpовеpить, а пpавлитьно ли ты yказал паpаметpы, то: В med одно нажатие гоpячими клавишами и ты в месте опpеделения фyнкции. В SlickEdit вообще по имени пpоцедypы дополнительно всплывает подсказка с паpаметpами. Hикyда ходить не надо.
OR>> отдельные файлы) - это плохо и неправильно, или начинать новый OR>> проект с копирования старых исходников в отдельный каталог и OR>> кромсания их. MP> Hужные куски выдираются из старого по copy-paste. _HУЖHЫЕ КУСКИ_ а не MP> сборище хламовых библиотек и помойки в хидерах от старого проекта MP> скопиронного по F5 в новую дир.
И потом pазные кyски из pазных пpоектов долго синхpонизиpyются pyками.
OR>> радикально, но незаметно :-) В 3 раза - радикально? Радикально. С 6 OR>> секунд до 2 - заметно? Да не очень. MP> Да с 8 до 6 у меня выходит в проекте из 7 файлов. Hу с большим натягом на MP> одном файле с 8 до 5. Даже не в 2 раза короче.
Сбоpка пpоекта для mb90, pазмеp bin ~100K - навскидкy 50 секyнд. Hапpягает.
С уважением, Andy <mailto:andy coбaкa svrw.ru>
- Vote on answer
- posted
19 years ago
Здравствуйте.
SP> 1. Рабочая копия проекта содержит _только_ необходимые для его SP> сборки SP> файлы: SP> - файлы самого проекта SP> - "внешние" файлы (платформа, драйвера, библиотеки и т.п.)
SP> 2. Во внешнем файле имеется "закрытая" дефайном ссылка на файл, SP> который не может быть использована в текущем проекте - файла нет в SP> рабочей копии проекта.
SP> Выполеняем make: SP> - вариан1: построение зависимостей выполнится _с_учетом_ #ifdef - SP> "all ok" SP> - вариан2: построение зависимостей выполнится БЕЗ УЧЕТА #ifdef - "нет SP> правила для создания того файла который не нужен..."
SP> Снова понятно что можно не пользоваться условными включениями, но SP> иногда без этого обойтись трудно. Да и зачем себя ограничивать если SP> вопрос легко решается?
А в случае, если ты вдруг "откроешь" ссылку на файл, который вдруг появился в проекте, то ты рискуешь поиметь проблемы, не заметив модификаций в этом заголовке. Предлагаешь каждый раз пересобирать зависимости ?
- Vote on answer
- posted
19 years ago
Это точно, перепутал (дошло еше вчера по дороге домой...), а удержаться не хватило сил, извини.
А теперь спокойно опишу тот случай, когда мне неудобны включения ненужных файлов.
- Рабочая копия проекта содержит _только_ необходимые для его сборки файлы: - файлы самого проекта - "внешние" файлы (платформа, драйвера, библиотеки и т.п.)
- Во внешнем файле имеется "закрытая" дефайном ссылка на файл, который не может быть использована в текущем проекте - файла нет в рабочей копии проекта.
Выполеняем make: - вариан1: построение зависимостей выполнится _с_учетом_ #ifdef - "all ok" - вариан2: построение зависимостей выполнится БЕЗ УЧЕТА #ifdef - "нет правила для создания того файла который не нужен..."
Снова понятно что можно не пользоваться условными включениями, но иногда без этого обойтись трудно. Да и зачем себя ограничивать если вопрос легко решается?
_______ Сергей.
- Vote on answer
- posted
19 years ago
- Vote on answer
- posted
19 years ago
Файл зависимостей зависит от того же списка что и исходный файл. Поэтому зависимости автоматически пересобираются при изменении самого файла, его инклудов, параметров компиляции. Так делается всегда и во всех моих проектах, мне это удобно и понятно.
_______ Сергей.
- Vote on answer
- posted
19 years ago
Это работает если "родные компиляторы" умеют отдавать список зависимостей хоть в каком-то виде, так и делается если использую gcc, softune. Речи же не было что нужно пользоваться всегда одной утилитой для создания списков зависимостей.
Почему не сообщаешь какую?
[skip]
Это как-то настраивается? или ищутся все слова "include"
_______ Сергей.
- Vote on answer
- posted
19 years ago
Tue, 08 Feb 2005 12:16:05 +0300 Sergey Pinigin wrote to Harry Zhurov:
SP> Это работает если "родные компиляторы" умеют отдавать список SP> зависимостей хоть в каком-то виде, так и делается если использую gcc, SP> softune.
Да, это (повторяюсь) самый корректный способ. Он, к сожалению, не переносим, и в случае компилятора, который не умеет отдавать, придется все равно искать способ, лежащий в стороне утилит (со всеми вытекающими недостатками).
SP> Речи же не было что нужно пользоваться всегда одной утилитой для SP> создания списков зависимостей.
Тогда придется иметь несколько систем сборок для разных платформ. Это тоже не есть предел желаний. В общем, идеального ничего, как всегда, нет, каждый выбирает себе решение по совокупности плюсов и минусов на свои задачи и вкус.
SP> Почему не сообщаешь какую?
А, нечего тут особо сообщать. Самописная.
SP> Это как-то настраивается? или ищутся все слова "include"
Не, все примитивно - по #include. Впрочем, так же, как и в случае с с/срр (во всяком случае навскидку я что-то отличий не вспоминаю). Зато работает, не возникает.
- Vote on answer
- posted
19 years ago
Привет!
Tue Feb 08 2005 12:16, Sergey Pinigin wrote to Harry Zhurov:
SP> Это работает если "родные компиляторы" умеют отдавать список SP> зависимостей хоть в каком-то виде, так и делается если использую SP> gcc, softune.
Я посмотрел, оба мои gcc умеют генерировать зависимости (ключ -M). А как эту полезную штуку использовать? Куда это можно в makefile прикрутить?
Юргис
- Vote on answer
- posted
19 years ago
Mon Feb 07 2005 20:33, Alexey Boyko wrote to Yuriy K:
AB>>> Итого предлагается написать make на bat'е? YK>> Предлагается объяснить преимущества make перед bat. YK>> Одно есть: ускорение сборки больших проектов. YK>> Приведи еще одно.
AB> При использовании make не нужно писать его функциональность на AB> bat-файлах.
Религиозные предпочтения неинтересны.
AB>>> ps: Возьмите вместо bat, какой-нить bash или tcsh. Или WSH AB>>> (Windows Scripting Host) YK>> Зачем?
AB> Hу, на них писать удобнее, чем на bat.
Религиозные предпочтения неинтересны.
WBR, Yuriy
- Vote on answer
- posted
19 years ago
Привет Andy!
03 Feb 05 15:36, Andy Mozzhevilov писал Alex Mogilnikov:AM>>> и чем он потом компилиpyется в obj? AM>> objcopy AM> Какой выходной фоpмат полyчается?
elf
AM> Я ведь понимаю так, что должен полyчиться текстовый файл, AM> веpнее всего *.asm c кyчей db. AM> Или я непpав?
Hеправ.
AM>> Я прекрасно понимаю, что позаботиться о нужном порядке сборки AM>> фрагментов можно и в рантайме (см. мое предыдущее письмо). Я лишь AM>> говорю о том, что это ничем не лучше, чем позаботиться о том же AM>> при линковке.
AM> В исходниках это хоpошо пpослеживается и опpеделяется явно.
Во-первых, скрипт линкера и Makefile - это тоже исходники (это такая же часть проекта, как и файлы *.c).
Во-вторых, вот такой комментарий:
#*************************************************************** # ВHИМАHИЕ! ВHИМАHИЕ! ВHИМАHИЕ! ВHИМАHИЕ! ВHИМАHИЕ! ВHИМАHИЕ! # Определенная ниже последовательность модулей должна строго # соответствовать порядку подключения микросхем на плате!!! # Тот, кто бездумно поменяет их порядок, будет проклят. #*************************************************************** FPGA_CHAIN = ep1c6.elf epm1k100.elf last_plis.elf
делает это хорошо прослеживаемым и в скрипте линкера, и в Makefile. И определено, по-моему, явнее некуда. :)))
AM> Я пpедпочтy этот способ, он содеpжит меньше потенциальных гpабель.
Приведи пример потенциальных грабель, отсутствующих в этом способе.
AM> Потом, я даже не знаю, стандаpтизyется ли поведение линкеpов в части AM> поpядка линковки файлов или это поведение нyжно pассматpивать лишь как AM> частный слyчай.
Конечно, закладываться на недокументированные особенности линкера вредно. Это я считаю само собой разумеющимся. Использование же для получения нужной последовательности секций документированных штатных средств линкера я считаю ничем не хуже использования для той же цели штатных средств компилятора.
Кстати, если я правильно помню, речь шла не о порядке линковки файлов, а о порядке линковки вообще, т.е. порядок линковки секций/сегментов - это тоже порядок линковки.
Всего наилучшего, [Team PCAD 2000] Алексей М. ... Посетители должны общаться по сети.