[Jderobot] Compilación por componentes

Lun Sep 23 17:25:04 CEST 2013

Hola,

Ya lo he probado con cameraserver y viewer y parecen funcionar
correctamente.
El CMakeLists de components sería algo de este estilo

list_subdirectories( LIST_COMPONENTS ${CMAKE_CURRENT_SOURCE_DIR} 1)

IF(NOT DEFINED build_jderobot-default)
        SET(build_jderobot-default ON)
ENDIF(NOT DEFINED build_jderobot-default)

FOREACH (component ${LIST_COMPONENTS})
        SET(build_jderobot_${component} ${build_jderobot-default} CACHE
BOOL "Build component ${component}")
        IF(build_jderobot_${component})
                ADD_SUBDIRECTORY (${component})
        ENDIF(build_jderobot_${component})
ENDFOREACH()

donde la primera parte lo único que hace es permitir decidir si se quieren
compilar o no por defecto todos los componentes; y la segunda es la que
genera de forma automática y comprueba cada una de las variables, siendo
estas del formato "build_jderobot_DirectorioDelComponente"

Para alguien que quiera compilar todo es prácticamente transparente, ya que
se establecería todo a verdadero y funcionaría como a hasta ahora.

Efectívamente sería el equivalente de ir manualmente por todos los
directorios de interés haciendo make; sin embargo esto se lanza desde donde
hayas comenzado la cadena de cmake para todos los componentes que quieras
activar y mantiene en la caché de cmake estas elecciones.

Un saludo,
Roberto

El jue, 19-09-2013 a las 19:09 +0200, Luis Roberto Morales escribió:
> >
> > Buenas tardes,
>
> Hola!
>
> >         últimamente he visto en la lista que hay gente que, como yo,
> >         prefiere compilar sólo algunos componentes de jderobot por
> >         unos u otros motivos.
>
> Tener en cuenta que a día de hoy se puede compilar por componentes, sólo
> requiere lanzar el cmake principal desde el root y listo. Además el
> cmake . principal no pide obligatoriamente todas las dependencias, si no
> tienes openni, o player o gazebo, no te va a compilar esos componentes.
>
> >         Entiendo que mantener un cmake por componente no solo es
> >         duplicar esfuerzo sino tambien repetir código de cmake y por
> >         tanto una fuente más de fallo.
>
> Además añadele que luego nadie lo mantiene, la gente va y viene y es muy
> difícil mantener algo estable. Por eso casi todas las decisiones tienen
> muy en cuenta el mantenimiento, no sólo el desarrollo. Para que os
> hagáis una idea, la mayoría de lo que está en testing ni compila ni
> funciona.
>
> >
> >         Por ello propongo algo que puede resultar interesante
> >         estudiarlo:
> >
> >
> >         CMake permite declarar variables cuyo resultado se almacena en
> >         caché, lo que permite modificar mediante parámetros o entornos
> >         como ccmake; esto es lo que utilizan librerías como OpenCV
> >         para permitir compilar partes de la misma.
>
> Si, lo que tiene mucho sentido porque openCV puede tardar entre 30-50min
> depende del PC. Jderobot tarda alrededor de 2-3min.
>
> El tiempo de compilación, duplicidad de cmakes y esfuerzos en mantenerlo
> son las razones de peso que tenemos siempre en cuenta para tomar ciertas
> decisiones de infraestructura.
>
> >
> >         He estado haciendo alguna prueba y estas "variables" se pueden
> >         crear de forma dinámica, con un valor predeterminado por
> >         defecto, lo que permitiría definir variables del estilo
> >         "build_componente" y pornerlas a ON por defecto, dejando a
> >         quien quiera establecer dichas variables a OFF si lo cree
> >         conveniente, permitiendo así una compilación "a la carta".
>
> Algo parecido había antes, donde en el CMakeList principal se definia
> qué componentes compilar, y había que estar modificandolo por si
> fallaban dependencias o había algún error. Antes si se añadía un
> componente había que especificarlo en el CMakeList, ahora es automático.
>
> Nos estamos moviendo a otro entorno diferente, donde el cmake detecta
> que si no hay ciertas dependencias instaladas desactiva auomáticamente
> ciertos componentes. Y además si quieres compilar un sólo componente,
> puedes, solo tienes que ir a su directorio y hacer el make después del
> cmake .
> >
> >
> >         La prueba en concreto la he estado haciendo en el bucle que
> >         resuelve los componentes, pero me quedaría comprobar que no
> >         supone ningún problema añadido. De ser así, sería añadir 3
> >         líneas de código al cmake que hace dicho bucle.
> >
> >         ¿qué os parece?
>
> Cuando lo tengas (con un par de componentes es suficiente) mándame el
> parche y lo probamos, que me gustaría echarle un ojo y lo vemos.
>
> Además, me gustaría que compilases un componente de la siguiente manera
> y me cuentes que partes se diferencia de lo que estás haciendo tú, o qué
> cosas no te gustan. Incluso la parte de compilación de interfaces y libs
> se podría meter en una regla de cmake para ser más simple si cabe.
>
> $ cmake .
>
> $ cd src/stable/interfaces
> $ make
> $ cd src/stable/libs
> $ make
>
> Y luego puedes compilar únicamente tu componente
> $ cd src/stable/components/kinectViewer
> $ cd make
>
> Gracias por tus aportes!
>
> Un saludo
> >
> >
> >  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
>
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://gsyc.escet.urjc.es/pipermail/jde-developers/attachments/20130923/d007e8fd/attachment.htm 