Проблема с связыванием объектных файлов из проекта в тестах

Я пытаюсь связать некоторые объектные файлы, чтобы писать тесты с помощью UnitTest++ в Codelite IDE. Как ни странно, руководство не говорит, как использовать .o файлы из (другого) проекта.

Если бы я использовал командную строку, этот поток показывает мне, как это сделать. Однако у меня больше проблем с редактором Codelite. Принятый ответ в этой другой теме говорит: «[i] в ​​IDE codelite это добавляется в текстовое поле опций компоновщика», однако я не считаю, что это так.

Я добавляю путь к этим .o файлам в месте Library Search Path, а затем добавляю имена отдельных файлов в месте Libraries чуть ниже этого. Когда я это делаю, я получаю ошибку /usr/bin/ld: cannot find -l<stuff>. Если я опускаю имена конкретных файлов в месте Library, я получаю ошибку undefined reference to.

Должен ли я компилировать исходный проект в виде библиотеки, чтобы обойти это? Или есть решение, которого я не вижу? Файл my_class_test.cpp, который я хочу запустить, выглядит примерно так:

#include <UnitTest++/UnitTest++.h>

#include "my_class.h"

SUITE(MyClassTest)
{

class MCFixture
{
public:
    MyClass me;
    MCFixture() : me("a", "b", "c") {};
};

TEST_FIXTURE(MCFixture, ConstructorTest)
{
    CHECK_EQUAL(1.0, 1.0);
}

} //SUITE(MyClassTest)

c++ linker codelite object-files
person Taylor    schedule 14.12.2017    source источник

Ответы (1)


arrow_upward
1
arrow_downward

CodeLite предполагает, что имена, которые вы пишете в поле Библиотеки, являются значениями, которые вы хотите передать параметру компоновщика -l.

Параметр компоновщика -lfoo указывает компоновщику выполнить поиск сначала в каталогах, указанных вами с помощью параметра -Ldir, а затем в каталогах поиска по умолчанию для любого из файлов libfoo.so (разделяемая библиотека) или libfoo.a (статическая библиотека). Он прекращает поиск, когда находит любой из них. Если он найдет оба или их в одном и том же каталоге поиска, он предпочтет libfoo.so. Выбранная библиотека, если она будет найдена, будет введена в компоновку. В противном случае компоновщик выдаст ошибку: cannot find -lfoo.

Таким образом, если вы указали каталог поиска компоновщика — скажем, /home/me/other/project/Debug — и в поле Библиотеки вы ввели, возможно, foo.o, bar.o, тогда компоновщик будет искать файлы:

/home/me/other/project/Debug/libfoo.o.{so|a}
/home/me/other/project/Debug/libbar.o.{so|a}

которого не существует, и собирается сказать вам: cannot find -l{foo|bar}.o

Существует вариант параметра -l, -l:name, который указывает компоновщику, что name — это точное имя искомого файла. Итак, если вы удалите foo.o, bar.o из поля Библиотеки и введете:

-l:foo.o
-l:bar.o

в поле Параметры связывания ваша связь будет выполнена успешно (за исключением других ошибок).

Конечно, foo.o и bar.o являются объектными файлами, а не библиотеками, статическими или динамическими, поэтому принудительное связывание для их поиска в поиске по библиотеке — непростая задача, даже если вы делаете это правильно.

Похоже, вы написали какой-то проект приложения и теперь хотите написать еще один проект для функций модульного тестирования и/или классов, используемых приложением.

Это банальная ситуация, для которой стандартным решением является три проекта:

  • Проект A: создает (статическую или общую) библиотеку, которая реализует тестируемые компоненты и экспортирует их API.
  • Проект B: создает ваше приложение, #include создавая заголовочные файлы и связывая библиотеку из проекта A.
  • Проект C: создает средство запуска модульных тестов, а также #include загружает файлы заголовков и связывает библиотеку из проекта A.

Сделать проекты B и C зависимыми от проекта A. В CodeLite это можно сделать с помощью настроек проекта Порядок сборки.

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

person Mike Kinghan    schedule 21.12.2017