Совместное использование промежуточных файлов между проектами C++?

Question

В настоящее время я пытаюсь выяснить, возможно ли двум разным собственным проектам Visual-C++ (которые имеют одинаковые настройки компилятора) совместно использовать свои промежуточные файлы (obj, pch, ...)

Пример должен помочь:

Это нормальная настройка:

PROJECTS \ P1 \ p1.vcproj; p1.cpp; ...
              \ Release_Intermediate_Dir \ p1.obj
                                         \ tool1.obj
         \ P2 \ p2.vcproj; p2.cpp; ...
              \ Release_Intermediate_Dir \ p2.obj
                                         \ tool1.obj
         \ COMMON \ tool1.cpp; ...

Как насчет этой настройки:

PROJECTS \ P1 \ p1.vcproj (uses: p1.cpp; p1_main.cpp)
              \ p1_test.vcproj (uses: p1.cpp; p1_test.cpp)
              \ Release_Intermediate_Dir \ p1.obj      (used by both projects p1 and test)
                                         \ tool1.obj
                                         \ p1_main.obj (only p1.vcproj)
                                         \ p1_test.obj (only p1_test.vcproj
         \ COMMON \ tool1.cpp; ...

Могу ли я использовать одну и ту же промежуточную папку для двух проектов C++, тем самым разделяя obj файлы напрямую?

Или мне всегда нужно иметь дополнительный статический проект lib? (Насколько я понимаю, статическая библиотека - это просто контейнер для obj файлы.)

---

Зачем мне это делать? Посмотрите на это сообщение в блоге: Написание модульных тестов в Visual Studio для Native C++.

Он использует статическую библиотеку с единственной целью иметь два разных исполняемых файла (основные функции, если хотите). (Забудьте об управляемых вещах /CLI.) Это означает, что в вашем решении должно быть 3 проекта (необходимо поддерживать три проекта), когда вам действительно нужны только два проекта, которые совместно используют один и тот же код с одинаковыми настройками компиляции, но используют другой главный / запуска такелаж.

Answer 1

Применив одинаковые флаги компиляции для обоих проектов и сделав промежуточные компоненты проекта А необходимыми для проекта Б, вы удалите все степени свободы из В. Нет никакой мыслимой возможности скомпилировать В отдельно, и ваша ссылка предполагает, что В не имеет смысла d' Кроме тестирования A. Самым простым и чистым решением было бы объединить тесты из B в A и сделать все это одним проектом (который, честно говоря).

На языке automake вы объявляете модульные тесты в B как check_PROGRAMS, и они будут скомпилированы только для проверки вашей программы. Я не эксперт по Visual-C++, но это чистое решение и должно быть как-то выполнимо с VC++.

Приложение: Чтобы прояснить язык Automake, проект, например, будет выглядеть так:

noinst_LTLIBRARIES = libthings-to-test.la libthings-not-tested.la
bin_PROGRAMS = production
check_PROGRAMS = unit_test_a

production_SOURCES = main.cpp
production_LDADD = libthings-to-test.la libthings-not-tested.la
unit_test_a_SOURCES = test.cpp
unit_test_a_LDADD = libthings-to-test.la
libthings_to_test_la_SOURCES = foo.cpp bar.cpp baz.cpp

со всей базой кода (производственный код, общие библиотеки, тесты) в одном проекте, то есть с одним модулем, который полностью сконфигурирован и распространяется и к которому прикреплен единственный номер версии. При установке конечным пользователем / дистрибьютором единой программы production.exe будет связан. Когда скомпилировано с make allудобные библиотеки и необходимые объекты будут скомпилированы в каталоге сборки, а когда make check вызывается, объекты, необходимые только для модульных тестов, компилируются, производственный код связывается и тесты запускаются. Опять же, извините, я не могу перевести это на Microsoft Speak.