Установить выходной каталог Build в Eclipse - c ++

Question

У меня есть программа, которая состоит из нескольких проектов в eclipse (работающих под ubuntu и проектов на c ++), эти проекты состоят из основного исполняемого файла и других файлов общих объектов и статических библиотек.

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

Answer 1

К сожалению, я обнаружил, что вкладка C / C ++ Build не позволяет вам указать расположение сборки, если вы не создаете свой собственный make-файл.

Вы, вероятно, обнаружили, что вкладка Настройки построителя в Свойства проекта> Сборка C / C ++ неактивна в проекте C / C ++ по умолчанию. Это связано с тем, что CDT назначает внутреннего компоновщика по умолчанию для новых проектов. Чтобы изменить это, вы можете перейти к Свойства проекта> Сборка C / C ++> Редактор цепочек инструментов и изменить Current Builder на Gnu Make Builder . Затем перейдите к Свойства проекта> C / C ++ Build и измените Тип построителя на Внешний построитель . Теперь вы можете создать свой собственный make-файл для проекта, если хотите; хотя я бы порекомендовал оставить CDT для автоматической сборки make-файла.

У меня те же требования к проекту, что и при выводе в / project_path / bin (хотя я по-прежнему поддерживаю разделение между сборками Debug и Release). Для этого я выполняю операцию копирования на выходе как шаг после сборки.

Для этого перейдите в Свойства проекта> Сборка C / C ++> Настройки и выберите вкладку Шаги сборки . В шагах после сборки в Команда: , введите:

cp ${BuildArtifactFilePrefix}${BuildArtifactFileName} "/path/to/bin/directory/";

Очевидно, что при необходимости нужно заменить «/ path / to / bin / directory /».

Лично я предпочитаю хранить файлы моего проекта в каталоге workspace / build ; копирование двоичных файлов в каталог workspace / bin и библиотек в каталог workspace / lib . Сначала я нашел этот обходной путь копирования неудобным, но начал ценить его, потому что он изолирует промежуточные файлы сборки от окончательного двоичного файла / библиотеки.

Для двоичных файлов я бы использовал:

cp ${BuildArtifactFilePrefix}${BuildArtifactFileName} "${WorkspaceDirPath}/bin/";

Для библиотек я бы использовал:

cp ${BuildArtifactFilePrefix}${BuildArtifactFileName} "${WorkspaceDirPath}/lib/";

Я включаю переменную "$ {BuildArtifactFilePrefix}", потому что CDT включает "lib" в качестве префикса по умолчанию для статических библиотек, что я на самом деле предпочитаю.

Вам просто нужно убедиться, что целевой каталог существует перед сборкой; Eclipse / CDT не создаст каталог для вас.

Также просто помните, что эти копии останутся в каталоге / bin или / lib в чистом виде, но будут перезаписаны при любом последующем перестроении.

Answer 2

Попробуйте Project->Properties

Под C/C++ Build->Settings у вас есть вкладка под названием Build Artifact.

Там у вас есть Artifact name. По умолчанию это ${ProjName}.

Измените это, чтобы указать относительный путь к каталогу, где вы на самом деле хотите, чтобы конечный файл заканчивался. Так может быть ../../lib/${ProjName}

Промежуточные файлы (.o и .d) будут по-прежнему создаваться в подкаталог (Debug или Release), но я думаю, что лучше, если они там есть, и это только окончательно собранная библиотека, для которой вы хотите изменить путь сборки.

Если вам неудобно вводить относительный путь подобным образом, я использую Среду для создания переменных среды с относительными путями, возвращающими меня в «корень». У меня есть ${LIBDIR}, и это относительный путь, с которого проект создается. Обычно он используется для ссылок в других библиотеках, но также может использоваться в качестве цели. Затем вы должны установить имя артефакта на ${LIBDIR}/${ProjName}, что хорошо работает, если вы используете разные каталоги для отладки и выпуска сборки.

Answer 3

Перейти к

Свойства проекта -> Сборка C / C ++ -> Настройки -> (вкладка) GCC C ++ Linker

Шаблон командной строки показан справа

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

Поставлен перед ${OUTPUT}

${COMMAND} ${FLAGS} ${OUTPUT_FLAG}${OUTPUT_PREFIX} ${ProjDirPath}/bin/${OUTPUT} ${INPUTS}

или

${COMMAND} ${FLAGS} ${OUTPUT_FLAG}${OUTPUT_PREFIX} MyMainProject/path/bin/ ${INPUTS}

Сhttps://www.eclipse.org/forums/index.php?t=msg&th=207500&goto=665566&#msg_665566

Answer 4

В моем проекте в качестве пути сборки по умолчанию используется имя конфигурации сборки, поэтому я могу использовать макрос $ {ConfigName} для получения пути сборки в шаге после сборки:

${workspace_loc:/${ProjName}}/${ConfigName}/${BuildArtifactFileName}

Затем вы можетескопируйте целевые двоичные файлы в вашу общую двоичную папку или сделайте что-нибудь другое в папке сборки этой конкретной конфигурации.

Answer 5

Просто случилось, что я работал над чем-то, что привело меня по тому же пути - поэтому я предложу это как альтернативное решение / напоминание для себя:

В Eclipse (по крайней мере, в Luna) сгенерированныйmake-файлы на самом деле довольно приличные и удобные.Мне лично нравится создавать несколько конфигураций сборки (версии Release и Debug с 32- и 64-разрядными архитектурами) и дополнять их конфигурациями отладки и запуска (соответственно F5 и Execute).

Продолжение: я играюс упаковкой на Debian и обнаружил - во время акта упомянутой игры - что мне нужно было создать и протестировать цель установки.Eclipse не генерирует для вас и не предоставляет интерфейс - конфигурацию - для настройки или добавления цели установки;Кроме места, где вы можете указать, что существует другая цель.

Так что технически Eclipse предоставляет интерфейс;своего рода.Поэтому я наткнулся на файлы makefile.init , makefile.defs и makefile.targets .

Процесс / рабочий процесс:

• Создайте файл makefile.targets в корневом каталоге вашего проекта Eclipse;В указанном файле определите цель установки вручную. Это - конечно, - позволяет вам указывать каждую мелочь по вашему усмотрению, но с дополнительным преимуществом всех конфигураций, предоставляемых Eclipse, уже завершенных и доступных вам для использования с определением правил для указанной цели.

• После определения новой цели в файле makefile.targets, щелкните правой кнопкой мыши на имени вашего проекта или на главном файле cpp в Eclipse project explorer,а затем выберите Make Targets -> Build... и, наконец, Add, чтобы создать всплывающее окно. В качестве альтернативы, вы можете выбрать «создать» на последнем шаге вместо «сборки», и это обеспечит такое же всплывающее окно, которое требуется для следующей части. Добавьте имя вашего новогоtarget и - оставив все остальное в их значениях по умолчанию - нажмите ok

• Если вы решили добавить новую цель создания, щелкнув правой кнопкой мыши в Project Explorer и выбор Make Target -> Build ... , после добавления новой цели make вы вернетесь к первому всплывающему окну.в результате выбора Build ... .В противном случае, найдите свой путь к всплывающему окну Make Targets -> Build.. прямо сейчас.Выберите нужную цель, а затем нажмите Build.

Просмотр автоматически сгенерированных make-файлов Eclipse - это отличный способ изучить синтаксис make-файла и общую структуру, а также перейти к более сложному использованию.of includes и условных выражений.

Вот некоторые части примера make-файла, который - по крайней мере, я надеюсь - продемонстрирует ручную настройку выходного каталога сборки:

prefix = /usr/local
bindir = $(prefix)/bin
sharedir = $(prefix)/share
mandir = $(sharedir)/man
man1dir = $(mandir)/man1

...
# Typical all target
all: <binaryname>

#Typical clean target
clean:
rm -f <binaryname> <objectname>.o

# Target invokes all, then installs to specified locations
install: all
install <binaryname> $(DESTDIR)$(bindir)
install -m 0644 <objectname>.1 $(DESTDIR)$(man1dir)

Answer 6

Если вы откроете свойства проекта, появится вкладка C / C ++ Build.У этого есть опция для местоположения сборки, где вы можете указать каталог сборки.Похоже, вы можете изменить это для нескольких проектов, чтобы они использовали один и тот же каталог сборки.