Hay una manera de utilizar buildconfiguration s para crear una biblioteca binaria (o compartido , en mi caso) de cada configuración de compilación. Usando la respuesta anterior, esto significa excluir manualmente todos menos el archivo principal efectivo de cada configuración de compilación.
Acabo de utilizar las respuestas anteriores para facilitar el trabajo en mi proyecto eclipse que crea 14 bibliotecas compartidas a través de 14 configuraciones de compilación. Sin embargo, la configuración de la indivdual "excluir de la acumulación" escenario era bastante engorroso, por lo que pasó a utilizar el siguiente código de depender de un preprocessor-directive como mi principal archivo completo:
/*
*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.
*/
Tenga en cuenta que no hace nada más, entonces incluir otro. archivo cpp cuyo nombre se deduce del preprocessor y un símbolo que se establece en las opciones del compilador. El símbolo es $ {CfgName} y será reemplazado por el nombre de la configuración actual por eclipse automáticamente.
No es necesario configurar, qué archivo se incluye en qué configuración de compilación. Solo excluya todos los archivos $ {CfgName} .cpp en cada compilación e incluya main.cpp en cada compilación.
PD: la respuesta de hovercraft me dio la idea de tener un archivo principal que no contenga código por sí mismo. Si uno incluye código compartido de los diferentes archivos principales efectivos $ {CfgName} .cpp, trabajar en su código puede volverse inviable porque los archivos de encabezado en main.cpp no serán visibles en ellos. Hice esto hasta ayer, pero mantener el código con índices rotos, etc. fue un gran dolor.
PPS: este procedimiento actualmente rompe la reconstrucción automática del archivo principal si solo se cambió el archivo .cpp incluido. Parece que Eclipse no reconoce los cambios en $ {CfgName} .cpp (que está excluido de la compilación). Por lo tanto, se requiere una reconstrucción manual después de cada cambio. Esto me está molestando actualmente;)
Debería considerar hacer una pregunta por separado sobre cómo hacer que su Makefile sea más fácil de mantener, en caso de que este sea un callejón sin salida –
En segundo lugar, el pensamiento expresado por Zac. ¿Por qué tu Makefile no se puede mantener? Muchos, muchos proyectos de software grandes y complicados usan makefiles con bastante éxito en bases de código que cambian rápidamente. –