amiller 2 16 июня, 2019 Опубликовано 16 июня, 2019 · Жалоба Использую IAR 7.80.4. При работе с новым проектом решил использовать несколько исходников от старого проекта. Соответственно включил их в новый проект. Но физически файлы остались в каталогах старого проекта. В этих файлах есть строки типа: #include "define.h", где настраивается функционал. Соответственно нужные хидеры в новом проекте лежат в каталоге, который прописан в путях проекта в опциях "include". И я предполагал, что они будут взяты именно оттуда. Но выяснилось, что в каталоге, где находится подключаемый "*.c", лежит хидер с таким же именем. При компиляции был подключен файл из старого проекта, а не из нового (молча). Когда доступный хидер из старого проекта был переименован, то также молча был найден и подключен хидер уже из нового проекта. Естественно, что каталог, где находится подключаемый "*.c", в новом проекте нигде не упоминается. Вышел из положения, скопировав нужные файлы в новый проект, но это вроде как не совсем правильно. Что скажете, так и должно быть? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
k155la3 27 16 июня, 2019 Опубликовано 16 июня, 2019 · Жалоба Компилятор ищет инклуды сперва в текущем каталоге, затем в наборе, указанном в опциях компилятора "include directoried" (не помню точно). Или, если путь указан сразу в #include "C:\MyDir\MyFile.h" - то там. Если файл не в кавычках, а в < > - поиск ведется в системных (IARа) каталогах. Если хотите включить конкретные (или с макро-перемнными) пути, см. опции проекта, C/C++compiler, preprocessor, additional include directories. Если в проекте обязательно должны использоваться файлы с одним и тем же именем, укажите для каждого из них индивидуальные пути загрузки, или - "научите" каждый из них грузиться (или не грузиться) с помощью #ifdef. Если один и тотже код используется в нескольких проектах, его можно скомпилировать в библиотеку, или вынести каталог с этим кодом из каталога проекта на один уровень выше. В каждом проекте можно указать относительный стандартный путь поиска к нему, как ..\MyLib\ \MyWorks\ \Proj1 \Proj2 \MyLib Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 231 16 июня, 2019 Опубликовано 16 июня, 2019 · Жалоба 3 часа назад, amiller сказал: Вышел из положения, скопировав нужные файлы в новый проект, но это вроде как не совсем правильно. Так лучше. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 56 17 июня, 2019 Опубликовано 17 июня, 2019 · Жалоба 9 часов назад, k155la3 сказал: Компилятор ищет инклуды сперва в текущем каталоге, затем в наборе, указанном в опциях компилятора "include directoried" (не помню точно). Или, если путь указан сразу в #include "C:\MyDir\MyFile.h" - то там. Если файл не в кавычках, а в < > - поиск ведется в системных (IARа) каталогах. Если совсем точно, то #include "" ищется сперва в директории, где находится исходный файл, содержащий директиву включения, а затем по всем остальным путям, указанным компилятору в качестве поисковых для включаемых файлов (обычно это опция командной строки -I ...). А #include <> ищется разу по поисковым путям, минуя директорию текущего исходного файла. Такое разделение сделано для оптимизации поиска: библиотечные заголовки как правило лежат по своим путям и поэтому нет смысла их искать в директориях проекта, поэтому такие файлы лучше заключать в <>. А заголовки проекта как правило лежат прямо тут же рядом с с/срр файлами, поэтому их надо заключать в "". Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
amiller 2 17 июня, 2019 Опубликовано 17 июня, 2019 · Жалоба 1 hour ago, dxp said: Если совсем точно, то #include "" ищется сперва в директории, где находится исходный файл, содержащий директиву включения, а затем по всем остальным путям, указанным компилятору в качестве поисковых для включаемых файлов (обычно это опция командной строки -I ...). А #include <> ищется разу по поисковым путям, минуя директорию текущего исходного файла. Такое разделение сделано для оптимизации поиска: библиотечные заголовки как правило лежат по своим путям и поэтому нет смысла их искать в директориях проекта, поэтому такие файлы лучше заключать в <>. А заголовки проекта как правило лежат прямо тут же рядом с с/срр файлами, поэтому их надо заключать в "". Спасибо всем. Я всегда думал, что <> означают поиск в системных каталогах. Но если это позволяет исключить каталог, где находится текущий файл, то это как раз то, что мне нужно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
scifi 1 17 июня, 2019 Опубликовано 17 июня, 2019 · Жалоба 12 hours ago, jcxz said: Так лучше. +1. Смешивать разные проекты в кучу себе дороже. Заимствования из других проектов правильнее делать средствами системы контроля версий. Например, в SVN есть такая штука - externals. То, что доктор прописал. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
k155la3 27 17 июня, 2019 Опубликовано 17 июня, 2019 · Жалоба 11 hours ago, dxp said: Если совсем точно, . . . Спасибо за инф. Не приходилость (по причине отсутствия необходимости) досконально изучать. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться