Improving build system: aliases and component

[varhub]

Hoy estoy vago así que lo escribiré en español, que para eso es el segundo idioma más hablado (detrás del chino).

Hablando con @fqez, creo que tengo una idea decente para plantear un sistema de compilación cómodo.

Ya nos estamos moviendo hacia compilación por componentes. Pero en lugar de para separar el código de las dependencias (que para eso ya está JdeRobot/ThirdParty#4 y no le habés hecho ni puto caso), ir hacia algo más pragmático, dando como ejemplo:

      install(TARGETS ${LibName}
        ARCHIVE DESTINATION ${LIBRARY_DIR} COMPONENT dev
        RUNTIME DESTINATION bin COMPONENT lib
        LIBRARY DESTINATION ${LIBRARY_DIR} COMPONENT lib
        INCLUDES DESTINATION include)

from https://github.com/Eyescale/CMake/blob/master/CommonLibrary.cmake#L179-L183

Esto es algo que @fqez ya tenía en mente, pero para poder usarlo require resolver el problema actual con build y cpack de otra manera. Por tanto, la propuesta es:

• Usar COMPONENT lib,dev,cfg para poder tener inslatar las cabeceras en paquete aislado
• Añadir alias o grupos al sistema de build_X
• Usar include() para simplificar el mantenimiento y evaluar los cambios introducidos
• retocar el nombre del proyecto para que la CPack genere múltiples sabores

Resumen planteado. Ahora consideraciones:
Añadir alias a grupos al sistema de build_X
La idea es simple, así que la expongo a través de ejemplos:
build_all: build-default=ON
build_msgs: compila solo las interfaces
build_core: build_msgs + src/stable/libs
build_drivers: == build_core, + src/stable/drivers Para probar el cuadricóptero:build_core build_quadcomper2 build_introrob_py(==test_quadrotor) Para probar el pioneer:build_core build_pioneer build_introrob_qt` (==test_pionner)

En este sentido, sería muy cómodo (y lógico), saltar a un nivel más de preconfiguración, por ejemplo usando la palabra test_X (¿test_X, run_X, use_X?)
donde run_kinect=ON activa todos los flags build_X requeridos para probar kinect, o flyingKinect o ambos.

Usar include()
Como todo lo anterior implica muchas lineas, lo normal será añadir en el CMakeLists.txt raiz solo dos lineas:

include(prebuilds.cmake)
include(prebuilds_userdefined.cmake)

donde el segundo fichero sería un cmake vacío e ignorado qe permita a los desarrolladores crear todas las configuraciones de prueba como quiera sin tener que preocuparse si ese archivo se sube o no.

CPack y múltiples sabores
Esto es simplemente un truco sucio para tener un retrocompatibilidad con CPack.

Al activar build_msgs, el nombre del projecto pasa de ser jderobot a jderobot-msgs. De este modo CPack creará un paquete con ese nombre.
Si hacemos eso con todos los build_X, tendremos distintos sabores de jderobot.
¿Por qué sabores?, porque no son fragmentos que se unen y se necesitan para componer un todo. Si instalas jderobot-drivers, jderobot-core ya está incluido en el mismo.

Obviamente, la forma de implementar esto es a través de una sola línea: project(${PROJECT_NAME}-X)

Conclusión
Si todo lo anterior se usa, podremos llegar a tener:

  jderobot-msgs-<version>.deb
  jderobot-msgs-dev-<version>.deb
  jderobot-drivers-<version>.deb
  jderobot-drivers-dev-<version>.deb

Y poder probar componentes (o casos de uso completos) con una sola variable de cmake.

[varhub]

Begin develop of this idea here:
https://github.com/jderobot-varribas/JdeRobot/commits/enhance/build_aliases

Success jderobot-core. jderobot-msgs do not make sense since libs can not be turned off. Can it?