Eclipse CDT не строит проект при изменении файла заголовка - PullRequest
17 голосов
/ 27 марта 2012

У меня есть Eclipse Platform 3.7.2 и CDT 8.0.2.

Когда я хочу сделать заголовки «Построить все» из других проектов рабочей области, они не считаются зависимостями и ничего не перестраивается.

У меня есть приложение hello world и проект статической библиотеки.Статическая библиотека задается в качестве ссылки в свойствах проекта -> общие сведения о c / c ++ -> пути и символы -> вкладка «Ссылки» -> отмечена как «активная».Это единственная настройка, которую я изменил.

Кстати, меня совершенно не удивляет, почему в Eclipse есть дополнительный элемент верхнего уровня «Ссылки на проект» в разделе «Свойства проекта».

В любом случае, я пробовал обаExternal Builder (который выбирается по умолчанию при создании проекта) и INternal Builder, также в сочетании с комбинациями глобального параметра «Предпочтения -> c ++ -> Построить -> Построить конфигурации только при изменении ресурса Eclipse ........ '

Спасибо за любые мысли по этому поводу.

Обновление: это вывод консоли при построении зависимого проекта Proj2 (Proj1 - библиотека).'make all' вызывается, но он просто пере-связывает, он не перекомпилирует Main.cpp, как следует.Кто-нибудь знаком с созданными затмениями make-файлами?Еще раз спасибо.

**** Build of configuration Debug for project Proj2 ****

make all 
Building target: Proj2
Invoking: Cross G++ Linker
g++ -L"/home/user/.eclipse-workspace/Proj1/Debug" -o "Proj2"  ./Main.o   -lProj1
Finished building target: Proj2


**** Build Finished ****

Редактировать: Это уже 1,5 года, хотел бы добавить, что ошибка Eclipse была подана для этого: https://bugs.eclipse.org/bugs/show_bug.cgi?id=375800

Ответы [ 3 ]

7 голосов
/ 19 сентября 2013

существует ошибка для этой проблемы: https://bugs.eclipse.org/bugs/show_bug.cgi?id=375800

И рабочий и аккуратный обходной путь (оригинальный запросчик это уже знает). Поэтому я просто ссылаюсь на фактический ответ :) https://bugs.eclipse.org/bugs/show_bug.cgi?id=375800#c11

Все кредиты для Krzysztof Czaińsk

В настройках компилятора c или c ++ добавьте -MT ${OUTPUT_PREFIX}${OUTPUT} после флагов:

${COMMAND} ${FLAGS} -MT ${OUTPUT_PREFIX}${OUTPUT} ${OUTPUT_FLAG} ${OUTPUT_PREFIX}${OUTPUT} ${INPUTS}

Это создаст правильные .d-файлы


Дополнение: Обходной путь имеет один побочный эффект. После очистки make all всегда запускается дважды, прежде чем ничего не говорит. Еще лучше, чем не компилировать после изменения; -)

1 голос
/ 23 сентября 2012

Самое безопасное, что нужно сделать - это сначала очистить основной проект, а затем перестроить.Часто, когда я знаю, какие файлы в основном проекте используют измененные заголовочные файлы, я просто «касаюсь» эти файлы и затем перестраиваю.Для меня «прикосновение» - это просто добавление пробела в строке, обычно это одна из #include строк в верхней части файла.Затем этот файл перестраивается и получает измененный заголовок.Другие файлы, которые могут использовать этот заголовок, не будут восстановлены, так что это опасно.Например, если вы изменили сигнатуру вызова метода и перестроили таким образом, только один файл будет правильно вызывать новый метод.Вызов из других исходных файлов может вызвать перехват вашей программы.Преимущество, конечно, в скорости восстановления.Особенно когда я выполняю модульное тестирование, я точно знаю, какие тесты я буду запускать, поэтому я просто касаюсь соответствующих файлов, перестраиваю прогон.В какой-то момент для безопасности я всегда делаю цикл очистки / сборки.обычно я жду, пока мне не понадобится больше кофе.

0 голосов
/ 27 марта 2012

Просто добавьте это, но разве вам не нужно включать заголовки из статической библиотеки в ваш клиентский код?В этом случае, я думаю, вам нужно добавить заголовки на вкладке includes свойств проекта для вашего клиента.В противном случае я не уверен, как бы вы на самом деле получили доступ к реализации статической библиотеки на вашем клиенте.

Что касается двух вкладок references, я считаю, что одну из общих версий C / C ++ можно определить отдельно для разных конфигураций.в то время как более общий - для любой конфигурации.

Обновление:
Я бы предложил использовать более общую вкладку reference, на которую вы отметили.Это должно гарантировать, что ваш клиент ссылается на другие проекты, независимо от того, какая конфигурация клиента или ссылка на проект выбрана в данный момент.

Другое обновление:
Я только что понял, что вы упомянули только значение, которое вы изменили, было references.Это еще один длинный путь, но я бы также проверил, отображаются ли пути включения для статической библиотеки на вкладке включения настроек проекта (возможно, так и есть).Я понимаю, что правильный путь включения используется во время компиляции, но eclipse (возможно) использует эту вкладку , чтобы определить зависимости включения при принятии решения инициировать перекомпиляцию клиентского проекта.Возможно, стоит также проверить вкладку «Местоположение источника» и попытаться добавить местоположение заголовка в качестве расположения источника.

enter image description here

...