Eclipse CDT не создает проект при изменении файла заголовка

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

Когда я хочу создавать заголовки "Build All" из других проектов рабочей области, не учитываются как зависимости, и ничего не перестраивается.

У меня есть приложение hello world и статический проект библиотеки. Статическая библиотека устанавливается в качестве ссылки в свойствах проекта → c/С++ general → Paths и SYmbols → вкладка "Ссылки" → "Активно". Это единственная настройка, которую я изменил.

Кстати, он полностью бьет меня, почему Eclipse имеет дополнительный элемент "Project References" верхнего уровня в разделе "Свойства проекта".

Во всяком случае, я попробовал как внешний Builder (который по умолчанию выбирается при создании проекта), так и встроенный Builder, а также сочетания глобальной настройки "Preferences → С++ → Build → Build конфигурации только тогда, когда есть Изменения ресурса Eclipse........ '

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

Обновление: Это консольный вывод при построении зависимого проекта Proj2 (Proj1 - это lib). вызывается "сделать все", но он просто переписывается, он не перекомпилирует 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

Ответ 1

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

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

Все кредиты Кшиштофу Цяньскому

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

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

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

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

Ответ 2

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

Ответ 3

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

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

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

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