2011-02-03 5 views
12

У меня есть программа, которая состоит из нескольких проектов в eclipse (работающих под ubuntu и проектов, находящихся в C++), эти проекты состоят из основного исполняемого файла и других файлов общих объектов и статических ЛИЭС.Установить Build output directory в Eclipse - C++

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

ответ

13

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

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

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

Чтобы сделать это, перейдите к Project Properties> C/C++ Построить> Настройки и выберите Построить шаги вкладку. В шагов после сборки под Command: введите:

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

Очевидно заменяя "/ путь/к/бен/каталог /" по мере необходимости.

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

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

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

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

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

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

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

Кроме того, помните, что эти копии будут оставлены в /бен или /Lib каталога на чистом, но перезаписаны на любом последующем восстановлении.

+0

Отличное решение, спасибо –

+0

Существует опция для этапа после сборки, поэтому проще всего создать его там, где он есть, и если это работает, используйте шаг после сборки, чтобы скопировать/переместить/связать его. Есть ли специальный макрос для Debug или Release, поэтому я могу использовать общий для обеих конфигураций? – CashCow

0

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

4

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

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

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

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

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

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

+1

Это не имеет никакого эффекта. Использование Luna release 4.4.0. Я могу изменить имя исполняемого файла, но часть пути игнорируется. – truthseeker

+0

Интересно, это сработало для меня. – CashCow

+0

Работал для меня тоже, спасибо! $ {workspace_loc: MyProject}/_ runtime/$ {ProjName} – macroland

0

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

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

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

Так что технически Eclipse действительно обеспечивает интерфейс; вроде. Следовательно, я наткнулся на makefile.init, makefile.defs и makefile.targets файлов.

Process/Workflow:

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

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

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

Просматривая автоматически сгенерированную Makefiles в Eclipse был отличным способом изучить синтаксис Makefile и общую структуру, и попасть в какое-то расширенному использования включает в себя и условных.

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

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) 
1

Перейти к Свойства проекта -> 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

1

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

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

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