У меня есть программа, которая состоит из нескольких проектов в eclipse (работающих под ubuntu и проектов, находящихся в С++), эти проекты состоят из основного исполняемого файла и других файлов общих объектов и статических библиотек.
Я хочу, чтобы все эти проекты были созданы для вывода их файлов в одну общую двоичную папку вместо их соответствующих папок отладки. Это упрощает создание ссылок с основным исполняемым файлом. Если есть лучшие решения, пожалуйста, не стесняйтесь делиться ими.
К сожалению, я обнаружил, что вкладка C/С++ Build не позволяет вам устанавливать место сборки, если вы не создаете свой собственный make файл.
Вероятно, вы обнаружили, что вкладка Настройки Builder в разделе Свойства проектa > C/С++ Build не отображается в проекте по умолчанию C/С++. Это связано с тем, что CDT по умолчанию назначает внутренний строитель для новых проектов. Чтобы изменить это, вы можете перейти к Project Properties > C/С++ Build > Tool Chain Editor и изменить Current Builder на Gnu Make Builder. Затем перейдите в Свойства проектa > C/С++ Build и измените Тип Builder на Внешний Builder. Теперь вы можете выбрать свой собственный make файл для проекта, если хотите; хотя я бы рекомендовал оставить CDT для автоматического создания файла makefile.
У меня одинаковые требования к проекту вывода в /project _path/bin (хотя я все еще поддерживаю разделение между сборками Debug и Release). Для этого я выполняю операцию копирования на выходе как шаг после сборки.
Для этого перейдите в Свойства проектa > C/С++ Build > Настройки и выберите вкладку Сборка. На шаге После сборки в разделе Команда: введите:
cp ${BuildArtifactFilePrefix}${BuildArtifactFileName} "/path/to/bin/directory/";
Очевидно, что нужно заменить "/путь/на/bin/directory/" по мере необходимости.
Я лично предпочитаю поддерживать файлы проекта в каталоге workspace/build; копирование двоичных файлов в каталог рабочей области /bin и библиотеки в каталог рабочей области/библиотеки. Сначала я обнаружил, что это обходное решение для копирования является неудобством, но постигло его, потому что оно изолирует межстрочные файлы сборки из финальной бинарной библиотеки.
Для двоичных файлов я бы использовал:
cp ${BuildArtifactFilePrefix}${BuildArtifactFileName} "${WorkspaceDirPath}/bin/";
Для библиотек я бы использовал:
cp ${BuildArtifactFilePrefix}${BuildArtifactFileName} "${WorkspaceDirPath}/lib/";
Я включаю переменную "$ {BuildArtifactFilePrefix}", потому что CDT включает в себя "lib" в качестве префикса по умолчанию для статических библиотек, который я действительно предпочитаю.
Вам просто нужно убедиться, что целевой каталог существует до создания; Eclipse/CDT не создаст для вас каталог.
Также помните, что эти копии будут оставлены в каталоге /bin или/lib на чистом, но перезаписаны при любой последующей перестройке.
Попробуйте Project->Properties
В C/C++ Build->Settings у вас есть вкладка Build Artifact.
Под ним есть Artifact name. Это значение по умолчанию ${ProjName}.
Измените это, чтобы указать относительный путь к каталогу, в котором вы действительно хотите, чтобы конечный файл закончил. Так может быть ../../lib/${ProjName}
Промежуточные файлы (.o и .d) по-прежнему будут создаваться в подкаталоге (Debug или Release), но я думаю, что это лучше, если они есть в любом случае, и это только окончательно построенная библиотека, для которой вы хотите измените путь сборки.
Если вы обнаружите, что неудобно печатать относительный путь, подобный этому, я использую среду для создания переменных среды с относительными путями, возвращающими меня к "корню". Один из них у меня есть ${LIBDIR}, и это относительный путь от того, откуда строится проект. Он обычно используется для связи в других библиотеках, но также может использоваться как цель. Затем вы должны установить Artifact Name в ${LIBDIR}/${ProjName}, который хорошо работает, если вы используете разные каталоги для отладки и выпуска сборок.
Идти к
Шаблон командной строки показан справа
${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
В моем проекте путь сборки по умолчанию соответствует имени конфигурации сборки, поэтому я могу использовать макрос ${ConfigName} для получения пути сборки на этапе после сборки:
${workspace_loc:/${ProjName}}/${ConfigName}/${BuildArtifactFileName}
Затем вы можете скопировать целевые двоичные файлы в общую двоичную папку или сделать что-то другое в папке сборки этой конкретной конфигурации.
Если вы откроете свойства проекта, появится вкладка C/С++ Build. У этого есть опция для местоположения сборки, где вы можете указать каталог сборки. Кажется, вы можете изменить это для своих нескольких проектов, чтобы они делились одним и тем же каталогом сборки.
Просто случилось работать над чем-то, что привело меня к тому же пути, поэтому я предлагаю его в качестве альтернативного решения/напоминания для себя:
В Eclipse (по крайней мере, в Luna) сгенерированные make файлы на самом деле довольно приличные и удобные. Мне лично нравится создавать несколько конфигураций сборки (варианты выпуска и отладки с 32-разрядными и 64-разрядными архитектурами) и дополнять их конфигурациями отладки и запуска (соответственно F5 и Execute).
Чтобы продолжить: я тренировался с упаковкой на Debian и обнаружил - во время действия упомянутого toying - что мне нужно было создать и протестировать цель установки. Eclipse не генерирует для вас и не предоставляет интерфейс для конфигурации - для настройки или добавления цели установки; Кроме места, где вы можете указать, что существует другая цель.
Итак, технически Eclipse действительно предоставляет интерфейс; вроде. Следовательно, я наткнулся на файлы makefile.init, makefile.defs и makefile.targets.
Процесса/рабочий процесс:
Создайте файл makefile.targets в корневом каталоге вашего проекта eclipse; В указанном файле укажите цель установки вручную. Это, конечно же, позволяет вам указать каждую маленькую деталь, как вам хотелось бы, но с дополнительным преимуществом всей конфигурации, предоставляемой Eclipse, уже завершена и доступна вам для использования с определением правил для указанной цели.
После определения новой цели в файле makefile.targets щелкните правой кнопкой мыши имя вашего проекта или основной файл cpp в Eclipse project explorer, а затем выберите Make Targets → Build... и, наконец, Add для создания всплывающего окна. В качестве альтернативы вы можете выбрать "создать" на последнем шаге вместо "build", и он предоставит такое же всплывающее окно, которое требуется для следующей части. Добавьте имя своей новой цели и - оставив все остальное по умолчанию - нажмите ok
Если вы решили добавить новую цель make, щелкнув правой кнопкой мыши в Project Explorer и выбрав Make Target- > Build..., добавив новую цель make, вы вернетесь к первому всплывающему окну которые возникли в результате выбора Build... В противном случае найдите свой путь к всплывающему окну Make Targets → Build... Выберите желаемую цель и нажмите Build.
Просматривая автоматически созданные автозавершения 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)