[Jderobot] Propuestas sobre cmakes y relacionados.

[Luis Roberto Morales]

Hola,
todas las ideas propuestas parten de la base que para un usuario estandar
que haga un cmake . && make (o en definitiva, que siga el manual) acabe con
una compilación tal y como está hasta ahora.

He creado una tarea sobre los cmake en general (#122), orientada a cambios
que o bien no están directamente relacionados con un componente
(refactorización en el resto de la cadena) o bien afectan a cmake no
asociados a componentes. Para 1 y 2 no creo que merezca la pena hacer una
subtarea propia (prácticamente es borrar ficheros o mover líneas); para los
casos 3 y 4 si, porque sería más complejo el tema.

En cuanto al tema del VisualHFSM, dos cosas:

   1. CMake permite pasarle parámetros al compilador
medianteadd_definitions[1],
   por ejemplo:

   add_definitions(-DWORKPATH=${CMAKE_INSTALL_PREFIX})

   insertaría un parámetro WORKPATH con valor el directorio elegido para la
   instalación la hora de compilar todo lo que hay definido en ese CMakeLists.
   A parte de esto hay distintas variantes; desde la más rápida que es
   hacer la definición con una guarda para permitir su modificación durante
   compilación (basado en lo de arriba) hasta una que tiene buena pinta [2]
   que sería aprovechar la orden configure_file de cmake. Un ejemplo de
   esto último sería:

   test.cpp.in:
   #include <iostream>
   using namespace std;
   int main () {
      cout << "@CMAKE_INSTALL_PREFIX@" << endl;
      return 0;
   }
   CMakeLists.txt:
   cmake_minimum_required(VERSION 2.8)
   configure_file( test.cpp.in test.cpp)
   add_executable(test test.cpp)

   Al realizar un 'cmake .' generaría desde test.cpp.in un test.cpp con el
   contenido:
   #include <iostream>
   using namespace std;
   int main () {
      cout << "/usr/local" << endl;
      return 0;
   }
   y compilaría un binario test cuya salida al ejecutar sería '/usr/local'.

   2. En el generador he visto que tienes un "SET( CMAKE_CXX_FLAGS
   \"-lpthread -lIce\" )" de los que en la propuesta 2 se habla de intentar
   evitarlos. En el caso de pthread, cmake ya tiene una forma de buscarlo y
   una variable asociada; en el de ice si no quieres/puedes buscarlo, puedes
   probar a aplicar lo que he comentado en ese punto para ver si te funciona y
   se puede eliminar dicha línea.


Un saludo,
Roberto

[1]
http://www.cmake.org/cmake/help/cmake2.6docs.html#command:add_definitions
[2]
http://stackoverflow.com/questions/7900661/how-to-read-a-cmake-variable-in-c-source-code
[3]
http://www.cmake.org/cmake/help/v2.8.8/cmake.html#command%3aconfigure_file


El 28 de noviembre de 2013 18:52, Borja Mon Serrano <
borjamonserrano en gmail.com> escribió:

> Hola,
>
> 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.
>>
>
> Yo sobre esto tengo ahora mismo una duda. Actualmente en VisualHFSM existe
> un script que te genera un fichero de texto con los interfaces que hay en
> jderobot de manera dinámica, esto es, que cuando abres VisualHFSM los carga
> para que el usuario pueda elegir qué interfaces añadir a su autómata. A
> este script hay que pasarle un directorio de trabajo como parámetro, que es
> /usr/local/include/jderobot/slice, directorio donde están las definiciones
> de los interfaces. Si se cambia el directorio de instalación, entonces
> habría que tener algún modo de pasarle a VisualHFSM dicha información,
> ¿esto se puede hacer mediante directivas de compilación o algo parecido?
>
> Un saludo,
>
> Borja.
>
> _______________________________________________
> Jde-developers mailing list
> Jde-developers en gsyc.es
> http://gsyc.escet.urjc.es/cgi-bin/mailman/listinfo/jde-developers
>
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://gsyc.escet.urjc.es/pipermail/jde-developers/attachments/20131129/8a8c4dfa/attachment.htm