[Jderobot] Compilación por componentes
Roberto Calvo
rocapal en gsyc.urjc.es
Mie Sep 25 16:37:03 CEST 2013
Hola!
Lo he estado probando y me parece una buena solución. Veo que tienes
permisos para hacer commits asi que si te parece súbelo pero con ligero
cambio.
En vez de usar: -Dbuild_jderobot_XXXX=ON
por simplificar cambialo para usar: -Dbuild_XXXX=ON
Cuando hagas el commit asocialo a este bug [1]. Simplemente empieza el
comentario del commit con un #20 y pones una pequeña descripción.
Esta solución permite que si falla un componente al compilar no rompa
toda la compilación (como pasaba antes), pero por favor si os encontráis
con problemas de compilación notificarlos cuanto antes a la lista.
También tenemos que añadir la documentación correspondiente al final de
esta sección. Si no tienes permisos en el wiki, dímelo.
Gracias por tus críticas constructivas y encima acompañadas de
soluciones. Así da gusto :-)
Un saludo!
[1] http://sarastro.gsyc.es/issues/20
[2] http://jderobot.org/Manual-5#Compile_and_Install_JDErobot_5.X_with_CMake
El mié, 25-09-2013 a las 01:25 +0200, Luis Roberto Morales escribió:
> Hola,
> si, se generaría una variable por componente de forma automática.
> Librerías e interfaces responden a la cadena actual, ya que la
> modificación se realizaría sobre el CMakeLists de components y, para
> cuando cmake llega ahí, ya se han procesado los otros dos cmake como
> hasta ahora.
>
>
> Para cmake estándar y los componentes basic_component, cameraserver,
> cameraview y recorder los pasos serían (suponiendo el caso de que se
> quiera compilar desde el raíz del repositorio y el usuario ya se
> encuentre ahí localizado):
>
>
> $ cmake -Dbuild_jderobot-default=OFF
> -Dbuild_jderobot_basic_component=ON -Dbuild_jderobot_cameraserver=ON
> -Dbuild_jderobot_cameraview=ON -Dbuild_jderobot_recorder=ON .
>
> $ make
>
> Donde:
>
> * -Dbuild_jderobot-default=OFF desactiva la compilación por
> defecto de todos los componentes; por defecto está activa para
> que sea transparente para el que quiera compilar todo con
> cmake . && make
> * -Dbuild_jderobot_XXXX=ON activa la compilación para el
> componente XXXX.
> * Independientemente de lo que se indique interfaces y librerías
> siempre compilan, ya que son procesadas por CMakeLists
> distintos al modificado.
> * Las normas de los CMakeLists internas a cada componente (por
> ejemplo: la no compilación si falta alguna librería definida
> dentro del CMakeList del componente) siguen aplicando.
> Si en lugar de cmake se utilizara ccmake, sólo habría que especificar
> la primera variable (si se desea) y rellenar el resto desde dentro de
> la GUI:
>
> $ ccmake -Dbuild_jderobot-default=OFF .
>
>
> [c]onfigure
>
>
> [e]xit help
>
>
>
> [Selección de variables varias]
>
>
> [c]onfigure
>
> [e]xit help
>
>
> [g]enerate and exit
>
>
>
> $ make
>
>
>
>
> Un saludo,
>
> Roberto
>
>
>
>
>
> El 24 de septiembre de 2013 18:51, Roberto Calvo
> <rocapal en gsyc.urjc.es> escribió:
> El lun, 23-09-2013 a las 17:25 +0200, Luis Roberto Morales
> escribió:
> > 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"
>
>
> ¿Eso implica generar tantas variables de esas como componentes
> quiera
> compilar verdad? Si quiero compilar cameraviewer y
> cameraserver tendrías
> que generar:
> build_jderobot_cameraviewer
> build_jderobot_cameraserver
>
> >
> >
> > 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.
>
>
> En teoría el "cmake ." se lanza siempre sobre el root del
> proyecto.
> Qué pasa con libs e interfaces ¿Cómo lo compilas?
>
> Para verlo más claro, imaginate que bajamos el repo completo
> de JDEROBOT
> y está incluido el cambio que has puesto más arriba. Escríbeme
> todos los
> comandos shell que hay que realizar para compilar (ponle 4
> componentes,
> los que quieras).
>
> >
> >
> >
> >
> >
> > 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
> >
> >
> >
> > _______________________________________________
> > 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
>
>
>
>
> _______________________________________________
> 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
More information about the Jde-developers
mailing list