Re: [Tsp-devel] Debut protage support compilation croisee PPC et ARM

[Eric Noulard]

Le 30/03/07, Frederik Deweerdt<address@hidden> a écrit :
> On Fri, Mar 30, 2007 at 09:53:26AM +0200, Eric Noulard wrote:
> > Tu mergeras aussi les modifs de Fred BM ?
> Oui, il faut aussi que j'intègre tes modifs sur les fichiers généres:
> uclibc n'a pas de rpcgen intégré et le rpcgen de nfs-utils ne marche pas
> pour des raisons qui m'échappent.

Cette histoire de rpcgen qui marche/qui marche pas est tout à fait
pénible. D'ailleurs pour le portage VxWorks Cesare avait
ajouté aux external un RpcGen pour des raisons similaires:

http://cvs.savannah.nongnu.org/viewcvs/tsp/external/RpcGen/?root=tsp

On pourrait voir si il ne serait pas possible de faire que
cette version de rpcgen soit utilisée en cas de rpcgen
manquant ou deffectueux.
Je dis ça mais je n'ai pas le temps de le faire...donc

> Donc je voulais faire
> IF(rpcgen)
>   genere
> ELSE IF(windows)
>  cp  tsp_rpc.h.win tsp_rpc.h
>  ...
> ELSE IF(linux)
>  cp  tsp_rpc.h.linux tsp_rpc.h
>  ...
> ENDIF(rpcgen)

Ca ira bien.
Penses à utiliser le mode commande de cmake
pour les copies. (Tu as un résumé des commandes supportées
en appelant "cmake -E" sans argument)

Donc pour la copie de fichier
soit "$(CMAKE_COMMAND) -E copy_if_different" ou
"$(CMAKE_COMMAND) -E copy" au lieu de "cp" ce sera plus portable
(en particulier pour Windows) et peut-être plus rapide
dans le cas de copy_if_different.

> Comme ça, ça devrait donner une compile clean sur arm et PPC. Il y a
> deux questions que je voudrais résoudre avant de merger, peut-être que
> Fred BM peut y répondre? :
> - FINDPackage(XML2) est commenté dans le patch, est-ce que c'est dû à un
>   cmake < 2.4.6 ? Si oui, je serai tenté par intégrer le patch que
>   j'avais envoyé là (workaround pour cmake 2.4.3):
>   http://lists.gnu.org/archive/html/tsp-devel/2007-03/msg00007.html



> - Est-ce qu'on pourrait grouper MINIMAL_BUILD et WIN32 ? Le premier
>   m'a l'air d'être un sous-ensemble de WIN32, ça permettrait de
>   n'avoir à maintenir qu'une option de compile (c'est à dire si WIN32
>   alors MINIMAL_BUILD).

Pour cette deuxième question j'aurai une petite recommandation
pour nous faciliter la vie à l'avenir.
Je pense que l'on devrait pouvoir concentrer les

IF(WIN32)
ELSE IF (PPC) etc....

dans tsp/CMakeLists.txt

et utiliser des variables définies "génériques" dans le reste
des CMakeLists.txt..

Un exemple de ça est la définition de PTHREAD_LIBRARY_NAME.
Du coup les targets qui utilise les pthreads font
TARGET_LINK_LIBRARIES(target ${PTHREAD_LIBRARY_NAME})
au lieu de recommencer une série de
IF (WIN32)
TARGET_LINK_LIBRARIES(target gnagnaLibWin32)
ELSE
TARGET_LINK_LIBRARIES(target gnagnaLibUnix)
ENDIF

Il y a évidemment une exception qui est quand on ne veut
pas du tout compiler telle ou telle partie car elle n'est pas
supportée pour la conf en cours (i.e. pas de compil' ascii_writer sous WIN32).

Les modifs liées au portage WiN32 n'ont pas forcément été faîtes
comme ça dès le départ mais j'ai tenté de faire
des modifs (uniquement des CMakeLists.txt) pour arriver à ça.
(Je pense qu'il reste encore des IF(WIN32) de trop car
ce n'est pas fini)

Je ne tiens pas à rajouter de contraintes aux bonnes volontés
que vous êtes mais juste suggérer quelques règles qui
pourraient nous faciliter la vie pour maintenir tout ça :))


--
Erk