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

Ответ 1

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

• Создайте управляемый проект (File > New С++ Project > Executable)
• Добавить исходный код, содержащий несколько основных() функций
• Перейдите в Project > Properties > C/С++ General > Путь и символы > Управление конфигурациями
• Создайте конфигурацию сборки для каждого исполняемого файла и назовите ее соответствующим образом (вы можете клонировать существующие конфигурации, такие как Debug и Release).
• В проводнике проекта щелкните правой кнопкой мыши на каждом исходном файле, который содержит функцию main() > Конфигурации ресурсов > Исключить из сборки, и исключите все конфигурации сборки, кроме той, которая строит исполняемый файл с помощью этой функции main()
• Все остальные коды включены во все конфигурации сборки по умолчанию. Возможно, вам придется изменить это в зависимости от вашего приложения.
• Теперь вы можете создать исполняемый файл для каждой основной функции, перейдя в Project > Build Configurations > Set Active, Project > Build Project

Ответ 2

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

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

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

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

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

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

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

Ответ 3

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

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

/*
 *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 файла, имя которого выведено из preprocessor и символ, заданный в параметрах компилятора. Символ ${CfgName} и автоматически заменяется текущим именем конфигурации eclipse.

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

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

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