Создание нескольких двоичных файлов в рамках одного проекта Eclipse - PullRequest
24 голосов
/ 11 марта 2010

Как я могу заставить Eclipse создавать множество двоичных файлов одновременно в одном проекте (без написания Makefile вручную)?

У меня есть проект CGI, в результате которого веб-сервер запускает несколько программ .cgi, а также несколько используемых ими библиотек. Созданный вручную Makefile, медленно используемый для его сборки, становится непригодным для использования. Мы используем «Внутреннюю сборку» Eclipse для сборки всех других проектов, и мы бы предпочли использовать ее и здесь, но, к счастью, я не могу найти, как заставить Eclipse создавать несколько небольших программ в результате вместо того, чтобы связывать все в один двоичный файл.

Ответы [ 3 ]

29 голосов
/ 04 октября 2013

Решение для этого описано здесь: http://tinyguides.blogspot.ru/2013/04/multiple-binaries-in-single-eclipse-cdt.html. Есть выдержка:

  1. Создание управляемого проекта (Файл> Новый проект C ++> Исполняемый файл)
  2. Добавить исходный код, содержащий несколько функций main ()
  3. Перейдите в Проект> Свойства> C / C ++ Общие> Путь и символы> Управление конфигурациями
  4. Создайте конфигурацию сборки для каждого исполняемого файла и назовите ее соответствующим образом (вы можете клонировать существующие конфигурации, такие как Debug и Release).
  5. В проводнике проекта щелкните правой кнопкой мыши каждый исходный файл, который содержит функцию main ()> Конфигурации ресурсов> Исключить из сборки, и исключите все конфигурации сборки, кроме той, которая создает исполняемый файл с этой функцией main ()
  6. Все остальные коды включены во все конфигурации сборки по умолчанию. Возможно, вам придется изменить это в зависимости от вашего приложения.
  7. Теперь вы можете создать исполняемый файл для каждой основной функции, выбрав «Проект»> «Конфигурации сборки»> «Установить активную», «Проект»> «Построить проект»
4 голосов
/ 28 июня 2010

Использование Eclipse в качестве системы сборки для производственного кода в целом кажется плохой идеей. Я думаю, что это отличная IDE, и она широко использовалась для проектов как на Java, так и на C ++, но для системы сборки я твердо верю, что Ant, make и другие специализированные утилиты сборки - это путь.

Для этого есть несколько причин:

  • Выделенные утилиты сборки предлагают ту гибкость, которую вы ищете при создании нескольких исполняемых целей.

  • Ant и make поддерживают самые мыслимые цепочки процессов произвольной сборки (хотя и не все).

  • Специальная утилита сборки, вероятно, предложит большую стабильность и обратную совместимость для форматов файлов описания сборки, чем инструмент IDE, такой как Eclipse. Кроме того, я уверен, что внутренняя возможность сборки Eclipse зависит от описания файла ".project", и формат последнего, вероятно, не так стабилен, как формат описания сборки для Ant или make.

  • Базовые утилиты общего назначения обычно основаны на командной строке, что позволяет легко интегрировать их с более сложными, высокоуровневыми утилитами сборки для автоматического управления сборкой, такими как Pulse, CruiseControl и т. Д.

Необходимость, которая мотивирует ваш вопрос, говорит вам, что пришло время переключиться на лучший инструмент для сборки.

2 голосов
/ 03 августа 2015

Существует способ использовать s для создания одного двоичного файла (или разделяемой библиотеки, в моем случае) из каждой конфигурации сборки. Используя ответ выше, это означает, что нужно вручную исключить все, кроме эффективного основного файла, из каждой конфигурации сборки.

Я просто использовал приведенные выше ответы, чтобы упростить работу над моим проектом , который создает 14 общих библиотек через 14 конфигураций сборки. Однако настройка отдельного параметра «исключить из сборки» была довольно громоздкой, поэтому я перешел к использованию следующего кода, опирающегося на директиву препроцессора , в качестве моего основного файла:

/*
 *main.cpp
 */
/* Within
 *  Project | Properties | C/C++-Build | Settings
 *  | GCC C++ Compiler | Preprocessor
 * set the following defined Symbol:
 *  _FILENAME=${ConfigName}
 */
#define __QUOT2__(x) #x
#define __QUOT1__(x) __QUOT2__(x)
#include __QUOT1__(_FILENAME.cpp)
#undef __QUOT1__
#undef __QUOT2__
/* The above include directive will include the file ${CfgName}.cpp,
 * wherein ${CfgName} is the name of the build configuration currently
 * active in the project.
 *
 * When right clicking in
 *  Project Tree | (Project)
 * and selecting
 *  Build Configuration | Build all
 * this file will include the corresponding .cpp file  named after the
 * build config and thereby effectively take that file as a main file.
 *
 * Remember to exclude ALL ${CfgName}.cpp files from ALL build configurations.
 */

Обратите внимание, что он больше ничего не делает, кроме того, включает еще один файл .cpp, имя которого выводится из препроцессора и символ, который устанавливается в параметрах компилятора. Символом является $ {CfgName}, и он будет автоматически заменен текущим именем конфигурации на eclipse.

Не нужно настраивать, какой файл включен в конфигурацию сборки. Просто исключите все файлы $ {CfgName} .cpp в каждой сборке и включите main.cpp в каждую сборку.

PS: ответ от hovercraft дал мне идею иметь основной файл, который не содержит сам по себе код. Если кто-то включает общий код из разных эффективных основных файлов $ {CfgName} .cpp, работа над их кодом может оказаться невозможной, поскольку заголовочные файлы в main.cpp не будут видны в них. Я делал это до вчерашнего дня, но поддержание кода с неработающим индексом и т. Д. Было большой болью.

PPS: эта процедура в настоящее время нарушает автоматическое восстановление основного файла, если был изменен только включенный файл .cpp. Кажется, что eclipse не распознает изменения в $ {CfgName} .cpp (который исключен из сборки). Таким образом, ручная перестройка требуется после каждого изменения. Это в настоящее время меня беспокоит;)

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...