Совместное использование промежуточных файлов между проектами C ++? - PullRequest
1 голос
/ 28 сентября 2011

В настоящее время я пытаюсь выяснить, возможно ли двум разным собственным проектам 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 проекта (необходимо поддерживать три проекта), когда вам действительно нужны только два проекта, которые совместно используют один и тот же код с одинаковыми настройками компиляции, но используют другой основной / автозапусктакелаж.

1 Ответ

1 голос
/ 28 сентября 2011

Установив одинаковые флаги компиляции для обоих проектов и сделав промежуточные компоненты проекта A предпосылками проекта B, вы удалите все степени свободы из B. Невозможной возможности компилировать B отдельно, и ваша ссылка предполагает, что B не имеетraison d'etre, кроме тестирования 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.

...