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

[Frederik Deweerdt]

On Fri, Mar 30, 2007 at 10:52:30AM +0200, Eric Noulard wrote:
> 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.
Ca marche avec �a effectivement (y'a un extern int inline qu'il faut
renommer), �a serait une solution sympa.
> 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.
Merci du tuyau, j'aurais ajout� du cp sans remords :)
> 
> >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
Je n'ai pas regard� l'arbo en d�tail, y'a un r�pertoire qui fait �a en
particulier?
> 
> 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 :))
C'est s�r. A ce propos (se faciliter la vie), est-ce qu'on pourrait se
mettre d'accord sur des r�gles de codage, en particulier tab/espaces.
Je n'ai pas de pr�f�rence particuli�re, mais je serai assez pour �viter
d'avoir un fichier indent� de X mani�res diff�rentes :)

A+
Fred