[Jderobot] Propuestas sobre cmakes y relacionados.

[Roberto Calvo]

Hola!

Gracias por tus comentarios, me parece bien lo que propones.

1,2,3 me parece perfecto.

4: Me parece bien añadir esta funcionalidad pero dejando la posibilidad
que compile como está ahora. Por ejemplo, en openniServer necesita que
el binario esté en la misma carpeta que el .so de la librería.

Sobre 5, ya estoy trabajando en ello para usar jenkis. Y el tema de los
test es algo más complicado por la topología de los componentes, aunque
siempre se pueden hacer a las librerías.

Si te parece, añade las tareas sobre 1,2,3 y 4 al redmine. Yo añado la 5
y así estamos todos al tanto.

Y sobre todo como siempre, seamos muy rigurosos en los commits para no
romper la compilación jderobot.

Un saludo!

El mié, 27-11-2013 a las 16:04 +0100, Luis Roberto Morales escribió:
> Hola,
> pensando un poco sobre el tema cmakes y asuntos relacionados había
> pensado unas ideas que se podrían ir incluyendo progresivamente si las
> vemos bien:
> 
> 
>      1. Eliminación de las carpetas "build" en los componentes del
>         repositorio.
>         Si no se me ha pasado algo, en principio la idea de estas
>         carpetas - hablo de las build a secas, las de
>         build-indepentent tenían otra motivación - era facilitar un
>         cmake para compilar solo el componente al que hacen referencia
>         y, por tanto, permitir una compilación por componentes.
>         La compilación por componentes creo que estaría resuelta ya
>         con el tema de las variables build_componente de la cadena de
>         compilación principal; si esto es así, las carpetas "build"
>         dejan de tener sentido y, al no estar correctamente mantenidas
>         en algunos casos, pueden dar lugar a confusiones.
>         
>         
>      2. Cambiar la inserción de librerías en los cmake desde
>         CMAKE_CXX_FLAGS a su posición correcta.
>         Todavía hay componentes sueltos que añaden librerías como Ice
>         y otras vía flags que se le pasan directamente a al compilador
>         de c++. Esto en algunos sistemas y casos puede provocar un
>         problema posterior de enlazado ya que las librerías insertadas
>         de esta forma se pasan siempre primero en la cadena de
>         enlazado.
>         A parte de que para algunas de ellas ya hay variables en
>         cmake, insertar estas librerías directamente en la lista de
>         TARGET_LINK_LIBRARIES  tiene un efecto similar y permite la
>         inserción en el orden adecuado.
>         
>         
>      3. Permitir la instalación de jderobot en otras carpetas
>         distintas a /usr/local.
>         Por lo que he estado viendo en los cmake la instalación se
>         realiza sobre carpetas dentro de /usr/local, sin posibilidad
>         de cambio. CMake dispone de un equivalente al --prefix de
>         autotools que permitiría al usuario que así lo quisiera
>         instalar todo jderobot en una carpeta de su elección.
>         No se hasta que punto los componentes esperan que jderobot
>         esté siempre en /usr/local, pero de cara a que por defecto el
>         cmake se siga comportando como hasta ahora a pesar de cambios
>         de este tipo, CMAKE_INSTALL_PREFIX por defecto suele
>         inicializar a /usr/local, por lo que si no se le dice nada y
>         se sustituye correctamente, debería seguir instalando como
>         hasta ahora.
>         
>         
>      4. Permitir compilación out-source de jderobot.
>         Actualmente, al compilar jderobot, los ficheros intermedios y
>         los binarios finales se quedan junto a los fuente cuando se da
>         una orden de compilación. Redefiniendo los destinos de
>         compilación con las variables de CMake adecuadas, se puede
>         obligar a que los resultados de dicha compilación cuelguen de
>         la carpeta desde la que se llamo al CMakeList principal, es
>         decir, si inicio la compilación desde ./build, todos los
>         ficheros intermedios y resultados de la compilación colgarán
>         de esta carpeta.
>         Las ventajas de este sistema serían, entre otras, que no hay
>         que limpiar el repositorio cada vez que se realiza una
>         compilación y que permite tener varias configuraciones de
>         cmake para los mismos fuentes a la vez.
>         
>         
>      5. Pruebas automatizadas.
>         La idea general sería poner unos equipos,máquinas virtuales o
>         similares con los sistemas operativos soportados por jderobot
>         y la instalación mínima que se supone necesaria para que este
>         compile con el objetivo de que lancen pruebas - en principio
>         de configuración y compilación - y aseguren el funcionamiento
>         en estos sin tener que esperar a que aparezca el problema en
>         la lista.
>         
>         Para realizar esta operación se puede utilizar por ejemplo las
>         herramientas ctest (software para programar pruebas diversas,
>         integrable con cmake y capaz de emitir resultados a otra
>         aplicación) y cdash (un panel web que recoge estas pruebas y
>         las organiza). Con estos dos, se puede configurar a las
>         máquinas para que o bien lancen pruebas automáticas (por
>         ejemplo los famosos nightly builds) o bien actuen como
>         esclavos de cdash y este les ordene hacer pruebas. También se
>         podría elegir si permitir o no subir pruebas manuales
>         realizadas desde otros equipos.
> 
> Un saludo,
> 
> Roberto
> 
> 
> 
> _______________________________________________
> Jde-developers mailing list
> Jde-developers en gsyc.es
> http://gsyc.escet.urjc.es/cgi-bin/mailman/listinfo/jde-developers

-- 
Roberto Calvo Palomino        | Robotics Lab (GSyC) 
R&D Android Mobile Engineer   | Universidad Rey Juan Carlos

Twitter: @rocapal 
Linkedin: http://www.linkedin.com/in/rocapal