taskTransport Sample Protocol - Tasks: task #5615, Build system change: GNU Autoxxx...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

task #5615: Build system change: GNU Autoxxx --> CMake

Submitter:  Eric NOULARD <erk>
Submitted:  Mon 29 May 2006 07:06:45 PM UTC
   
 
Category:  None Should Start On:  Sun 28 May 2006 10:00:00 PM UTC
Should be Finished on:  Sun 28 May 2006 10:00:00 PM UTC Priority:  7 - High
Status:  Ready For Test Privacy:  Public
Assigned to:  erk Percent Complete:  100%
Open/Closed:  Closed Effort:  0.00

Jump to the original submission

Wed 18 Oct 2006 10:10:40 AM UTC, comment #34: 

Ok the TSP Win32 port merge brings us
an operational CMake build system for TSP.
Makefiles are no longer part of the source since
they will be generated by CMake.
AutoXXX files will disappear soon too.

However TSP now REQUIRES a separate BUILD tree vs SOURCE tree.
That is imagine the TSP source root directory is

/home/me/tsp

one should create a build dir:

mkdir /home/me/tsp_build
then
cd /home/me/tsp_build
and finally
cmake /home/me/tsp
then
make

 Eric NOULARD <erk>
Group administrator
Wed 04 Oct 2006 09:05:05 AM UTC, comment #33: 

We should definitely use CMake 2.4.x since
2.2 lacks some really interesting features like

- WORKING_DIRECTORY on
  ADD_CUSTOM_COMMAND.

- CPack

and probably more I did not identified yet.


Eric NOULARD <erk>
Group administrator
Thu 24 Aug 2006 02:04:10 PM UTC, comment #32: 

More CMake Macros:

http://www.mip.informatik.uni-kiel.de/~jw/cmake/CMakeModules/

Some like Doxygen usable on the Windows Platform may help a lot
for build API documentation in HTMLHelp format

http://public.kitware.com/pipermail/cmake/2006-August/010786.html

 Eric NOULARD <erk>
Group administrator
Tue 22 Aug 2006 07:21:53 AM UTC, comment #31: 

Faire ça:
http://lists.gnu.org/archive/html/tsp-devel/2006-07/msg00030.html
SUite à OK
http://lists.gnu.org/archive/html/tsp-devel/2006-08/msg00000.html

 Eric NOULARD <erk>
Group administrator
Fri 28 Jul 2006 09:12:55 AM UTC, comment #30: 

Je pense que pour l'aspect Packaging il serait intéressant
d'utliiser CPack:

http://www.cmake.org/Wiki/CMake:Packaging_With_CPack
Ca nous permettrait notamment de générer (AVérifier)
des installeurs pour TSP sous Windows
http://www.cmake.org/Wiki/CPack:Generator_Information
ce qu'il faudra de toute façon faire avec ou sans CPack.

L'inconvénient est que CPack vient avec CMake 2.4.x
(voir 2.5.x / CVS) donc on devrait "abandonner" la compatibilité
CMake 2.2.x.

Idéalement on devrait pouvoir utiliser CMake 2.2.x pour un build
simple et CMake 2.4.x pour un build "avancé" avec CPack etc...

Si c'est trop galère je suggère un CMake 2.4.x rulez....


Eric NOULARD <erk>
Group administrator
Wed 19 Jul 2006 01:01:19 AM UTC, comment #29: 

L'activation du canal XMLRPC est implémenté dans cmake, et se fait par :

cmake -DBUILD_XMLRPC=ON  .

(ce qui pour l'instant désactive le canal ONC-RPC)


Stephane GALLES <sgalles>
Group Member
Tue 18 Jul 2006 08:33:12 PM UTC, comment #28: 

Un autre endroit pour trouver/contribuer des
modules CMake est le Wiki:

http://www.cmake.org/Wiki/CMake_User_Contributed_Macros

sur recommandation:

>>>>>>>>>

Moreland, Kenneth <kmorel@sandia.gov>

I also recommend posting your FindXXX files to the CMake Wiki:

    http://www.cmake.org/Wiki/CMake_User_Contributed_Macros

In the best case scenerio, it will take several months for a CMake contribution to be available in a general release, whereas a Wiki contribution is available right now.  The Wiki is also a good place to put find modules that may not be appropriate for contribution back to the CMake distribution, perhaps because the CMake code is still a moving target or because the module is not applicable to a large enough audiance.

-Ken

>>>>>>>>

 Eric NOULARD <erk>
Group administrator
Tue 18 Jul 2006 07:28:23 AM UTC, comment #27: 

Memo:
Il reste à ajouter les règles
INSTALL_FILES
INSTALL_PROGRAMS
INSTALL_TARGET

de façon à ce que
make install fasse son travail.

Peut-être est-ce possible de le faire
"automatiquement" en changeant les macros
TSP_XSCRIPTS et TSP_XINCLUDE...
reste les programs et les libs.

Eric NOULARD <erk>
Group administrator
Fri 14 Jul 2006 08:30:30 PM UTC, comment #26: 

Un echange de mail sur la ML CMake.

De : Brad King <brad.king@kitware.com> Envoyé par : kitware.com
À: Erk <eric.noulard@gmail.com>
Cc: CMake ML <cmake@cmake.org>
Date : 14 juil. 2006 22:14
Objet : Re: [CMake] How to contribute FindXXX cmake module?
Erk wrote:

> Hi all,
>
> We are currently switching from Autotools to cmake
> for our project:
>
> I wonder if you (CMake developpers/Maintainer) would
> be interested in updated or new
>
> FindXXX cmake modules, that could be putted back
> in new cmake release?
>
> Updated would be the case where module
> where obviously used only on Win32 or MacOS paltform.
>
> New is for thing I dit not find either cmake 2.4.2.
>
> If the answer is YES could you tell me how to do this.
> Is there "rules" you want to be applied for those modules.
>
> If the answer is NO, may be you can tell me why?
>
> My switch to CMake is new (10 days) but it is really
> a simple and efficient tool.


Yes, we accept contributions.  When writing them please read this file:

http://www.cmake.org/cgi-bin/viewcvs.cgi/Modules/readme.txt?root=CMake&view=markup

Then create a feature request in the bug tracker for each module and
attach the module to the report:

http://www.cmake.org/Bug

Thanks,
-Brad

 Eric NOULARD <erk>
Group administrator
Fri 14 Jul 2006 08:27:07 PM UTC, comment #25: 

Suite à la (très bonne) remarque de Stéphane
j'ai 'modulifié'
Doxygen
FUSE
GTK
Lex/Yacc
XML2

c'est plus joli.

Sinon j'ai fini ce à quoi je voulais arriver avec CMake
on est dans un "état" équivalent à ce qu'on avait avec les
autotools.

Je fais un petit message à tous pour "inciter" aux tests
avant de décréter le switch et de dégager les anciens Makefiles
et autres makerules.

Eric NOULARD <erk>
Group administrator
Wed 12 Jul 2006 05:42:35 PM UTC, comment #24: 

OK, c'est noté, je met tout dans make.

En fait j'ai déjà un FindXMLRPC qui marche, et je pense que je vais faire un FindWWW qui est une dépendance de xmlrpc-c
J'ai décidé de passer directement à un module custom, car j'avais trop de code à écrire (entre xmlrpc-c et la libwww il y a beaucoup de lib à trouver et à linker dès le départ cela faisait trop de choses à mettre dans le CMakeLists.txt principal)

 Stephane GALLES <sgalles>
Group Member
Wed 12 Jul 2006 02:58:21 PM UTC, comment #23: 

Une petite precision,
on essaie de garder la compatibilite CMake 2.2.x
merci de developper/tester tes modules avec un cmake 2.2.x
plutot qu'en 2.4.x.

Si c'est trop penible on pourrait abandonner la compat' 2.2.x
mais a ce moment la j'aimerais en rediscuter avec vous.

 Eric NOULARD <erk>
Group administrator
Wed 12 Jul 2006 02:55:52 PM UTC, comment #22: 

Je ne vois pas d'inconvenient a ajouter nos modules CMake
par contre je prefereais que tu mettes les fichiers
dans

tsp/make

et ne pas creer de repertoire tsp/cmake/module
ceci dans le but d'eviter de creer de nouveau repertoire
en effet a la fin de la migration

autotools --> cmake
le repertoire actuel tsp/make sera quasi vide...et
impossible a supprimer a cause de cvs :(((

donc OUI pour les modules CMake custom mais dans tsp/make
(sans meme creer de sous repertoire)

N'hesite pas a regarder dans le svn de KDE car eux aussi
ecrivent des modules custom:

D'ailleurs je l'avais indique dans le TODO:
http://cvs.savannah.nongnu.org/viewcvs/tsp/TODO?root=tsp&view=markup

>>>

- see if we can share/develop our
  FindXXX.cmake / UseXXX.cmake with KDE
  http://websvn.kde.org/trunk/KDE/kdelibs/cmake/modules/
  http://websvn.kde.org/trunk/KDE/*/cmake/modules

>>>>


Eric NOULARD <erk>
Group administrator
Wed 12 Jul 2006 02:26:40 PM UTC, comment #21: 

Est ce que vous voyez un inconvénient à ce que j'ajoute à la racine de tsp un répertoire tsp/cmake/modules pour placer les modules cmake custom (on avait déjà le répertoire make dans le même esprit) ?

 Stephane GALLES <sgalles>
Group Member
Tue 11 Jul 2006 06:39:51 AM UTC, comment #20: 

OK ca me va bien
Vas-y commite donc ça.
Et nous aussi on debute dans CMake :))

 Eric NOULARD <erk>
Group administrator
Tue 11 Jul 2006 02:36:47 AM UTC, comment #19: 

Je te confirme que
ldd /usr/lib/libGL.so | grep pthread
ne renvoie rien chez moi.
Donc je ne vois pas d'objection à ce que l'on ajoute le pthread dans Visu3D (en fait cela m'arrangerait beaucoup !)

Maintenant tout autre chose : concernant la detection des libs externes.
Est ce que je me trompe en disant que suite à la detection d'un lib TOTO par le CMakeLists.txt principale, les variable TOTO_INCLUDE et TOTO_LIBRARY doivent maintenant être ajoutées aux CMakeLists.txt qui utilisent la lib ?

En effet, par exemple, j'ai installé fuse dans un endroit non standard, j'ai donc ajusté les variables CMAKE_INCLUDE_PATH et CMAKE_LIBRARY_PATH, et le CMakeLists.txt principale a bien détecté mon install de fuse...mais la compilation de tspfs a quand même échoué car les variables FUSE_INCLUDE et FUSE_LIBRARY ne sont jamais utilisées.

Que diriez vous de ce patch ?

===================================================================
RCS file: /sources/tsp/tsp/src/consumers/tspfs/CMakeLists.txt,v
retrieving revision 1.1
diff -u -r1.1 CMakeLists.txt
--- CMakeLists.txt      26 Jun 2006 20:27:23 -0000      1.1
+++ CMakeLists.txt      11 Jul 2006 02:06:24 -0000
@@ -1,4 +1,5 @@
 ADD_DEFINITIONS(-D_FILE_OFFSET_BITS=64 -DFUSE_USE_VERSION=25 -Wall -Werror)

+INCLUDE_DIRECTORIES( ${FUSE_INCLUDE} )
 ADD_EXECUTABLE(tspfs tspfs.c)
-TARGET_LINK_LIBRARIES(tspfs fuse tsp_consumer tsp_common tsp_services)
+TARGET_LINK_LIBRARIES(tspfs ${FUSE_LIBRARY} tsp_consumer tsp_common tsp_services)

(en fait je me suis inspiré de cela :
http://www.cmake.org/Wiki/CMake_HowToFindInstalledSoftware
mais je débute encore en cmake, donc je suis peu être à coté de la plaque...)

 Stephane GALLES <sgalles>
Group Member
Mon 10 Jul 2006 12:13:10 PM UTC, comment #18: 


> Je ne comprend pas comment cela fonctionne chez vous sans cette modif...c'est
> d'autant plus étrange que quand vous vous appliquez cette modif, et si cela
> marchait avant, vour devriez avoir une redéfinition des symboles de
> pthread...vraiment étrange.

Je pense que je tiens le coupable. Au link de Visu3D on passe: -lm -lGL -lGLU -lglut -lX11 et il se trouve que sur ma machine lorsque je fais un 'gcc -lGL test.c' (test.c contenant des fonctions pthread), la compilation réussit.
On avait donc de la chance, je suppose, que la compile marche sans passer le -lpthread, si vous n'y voyez pas d'objection, je le rajoute au Makefile et au CMakeLists.txt.
A+
Fred

 Frederik Deweerdt <deweerdt>
Group administrator
Mon 10 Jul 2006 10:10:17 AM UTC, comment #17: 

Sans tester, je te confirme que cela fonctionne en ajoutant pthread, puisque c'est exactement cette modif que j'ai été obligé de faire sur mon système depuis le début de mon utilisation de cmake, pour que Visu3D compile.

Je ne comprend pas comment cela fonctionne chez vous sans cette modif...c'est d'autant plus étrange que quand vous vous appliquez cette modif, et si cela marchait avant, vour devriez avoir une redéfinition des symboles de pthread...vraiment étrange.

Steph

 Stephane GALLES <sgalles>
Group Member
Mon 10 Jul 2006 10:00:15 AM UTC, comment #16: 

`TSP_consumer_request_sample_destroy':/home/steph/tmp/test2/tsp/src/core/driver/tsp_consumer.c:1194:

> undefined reference to `pthread_join'
> collect2: ld returned 1 exit status
> make[2]: * [exec/Linux/Debug/bin/Visu3D] Error 1
>
> Effectivement j'ai bien :
> nm -a libtsp_consumer.a | grep pthread
> U pthread_create
> U pthread_join
> Comment est ce que cela peut être résolu chez vous ? je ne comprends pas...


C'est curieux, effectivement, d'autant plus que les anciens Makefile ne donnent pas de trace de pthread non plus...
Est-ce que tu peux essayer voir si la modif suivante résoud le problème:
Index: src/consumers/Visu3D/CMakeLists.txt
===================================================================
RCS file: /sources/tsp/tsp/src/consumers/Visu3D/CMakeLists.txt,v
retrieving revision 1.2
diff -u -r1.2 CMakeLists.txt
--- src/consumers/Visu3D/CMakeLists.txt 9 Jul 2006 14:33:10 -0000       1.2
+++ src/consumers/Visu3D/CMakeLists.txt 10 Jul 2006 09:59:42 -0000
@@ -7,4 +7,4 @@

 TARGET_LINK_LIBRARIES(Visu3D m GL GLU glut X11 Xmu tsp_consumer tsp_common tsp_services)

-ADD_DEPENDENCIES(Visu3D libtsp_common libtsp_consumer libtsp_services)
+ADD_DEPENDENCIES(Visu3D libtsp_common libtsp_consumer libtsp_services pthread)

A+
Fred

 Frederik Deweerdt <deweerdt>
Group administrator
Mon 10 Jul 2006 02:44:38 AM UTC, comment #15: 

Génial vos modifs ! La detection des libs marche super ( et en plus le fait de passer par les FIND permet maintenant d'utiliser CMAKE_INCLUDE_PATH et CMAKE_LIBRARY_PATH ce dont j'avais besoin pour aller chercher mon install non standard de FUSE )

Mis à part cela, j'ai quand même mon petit problème de symboles pthread manquants...je ne comprend pas comment cela peut compiler chez vous puisque la lib pthread n'est pas linké...?

Je ne pense pas que ce soit GLUT le problème :

-- Looking for OpenGL - found : /usr/lib/libGL.so
-- Looking for GLU
-- Looking for GLU - found : /usr/lib/libGLU.so
-- Looking for GLUT
-- Looking for GLUT - found : /usr/lib/libglut.so

Mais en arrivant sur Visu3D le linker cherche logiquement les symboles pthread manquant dans libtsp_consumer :

Linking C executable ../../../exec/Linux/Debug/bin/Visu3D
/usr/bin/cmake -E remove -f ../../../exec/Linux/Debug/bin/Visu3D
cd /home/steph/tmp/test2/tsp/src/consumers/Visu3D && gcc   -g  -fPIC "CMakeFiles/Visu3D.dir/Loader3ds.o" "CMakeFiles/Visu3D.dir/glScene.o" "CMakeFiles/Visu3D.dir/testTSP.o"   -o ../../../exec/Linux/Debug/bin/Visu3D -rdynamic -L/home/steph/tmp/test2/tsp/exec/Linux/Debug/lib -lm -lGL -lGLU -lglut -lX11 -lXmu -ltsp_consumer -ltsp_common -ltsp_services -Wl,-rpath,/home/steph/tmp/test2/tsp/exec/Linux/Debug/lib
/home/steph/tmp/test2/tsp/exec/Linux/Debug/lib/libtsp_consumer.a(tsp_consumer.o): In function `TSP_consumer_request_sample_init':/home/steph/tmp/test2/tsp/src/core/driver/tsp_consumer.c:1123: undefined reference to `pthread_create'
/home/steph/tmp/test2/tsp/exec/Linux/Debug/lib/libtsp_consumer.a(tsp_consumer.o): In function `TSP_consumer_request_sample_destroy':/home/steph/tmp/test2/tsp/src/core/driver/tsp_consumer.c:1194: undefined reference to `pthread_join'
collect2: ld returned 1 exit status
make[2]: * [exec/Linux/Debug/bin/Visu3D] Error 1

Effectivement j'ai bien :
nm -a libtsp_consumer.a | grep pthread
 U pthread_create
 U pthread_join
Comment est ce que cela peut être résolu chez vous ? je ne comprends pas...

 Stephane GALLES <sgalles>
Group Member
Sun 09 Jul 2006 10:14:33 PM UTC, comment #14: 

J'ai un peu avancé.
Les anciens XINC et autre XSCRIPTS
sont maintenant des macros CMake

TSP_XINCLUDE(<list of exported include>)
TSP_XSCRIPTS(<list of exported scripts>)

voir par exemple:
src/consumer/generic/CMakeList.txt

sinon pour les fichiers générés, incluant ou pas
des remplacements de variables "a la configure"
mieux vaut utiliser CONFIGURE_FILE qu'un
'sed' dans CUSTOM_COMMAND.
voir par exemple:
src/core/CMakeList.txt pour le fichier src/core/include/tsp_prjcfg.h[.in]

Je oense qu'on est pas loin d'un truc fonctionnel
pour tous.
Merci de votre aide.

Eric NOULARD <erk>
Group administrator
Sun 09 Jul 2006 02:36:28 PM UTC, comment #13: 

J'ai sensiblement amélioré les CMakeLists.txt
et j'ai commité.

Je pense que le pb de build de Visu3D devrait etre résolu.
Il me reste encore à detecter proprement
FUSE / xattr afin de compiler optionnellement
tspfs.

Stephane peux-tu vérifier ton histoire de pthread / Visu3D
je n'ai pas le pb chez moi et je pense que ton pb
était plutôt du à une libGL/GLU/GLUT manquante.

Si elle manque désormais on ne devrait plus essayer de
compiler Visu3D.

 Eric NOULARD <erk>
Group administrator
Sat 08 Jul 2006 02:58:05 PM UTC, comment #12: 

C'est OK. Grace aux modifs de Fred cela marche chez moi aussi avec CMake 2.2.3. (la seule chose qui ne passe pas encore c'est le pthread pour le Visu3D, je vous laisse regarder)

 Stephane GALLES <sgalles>
Group Member
Fri 07 Jul 2006 11:05:53 AM UTC, comment #11: 

A la demande de Fred, voici l'erreur de link que j'obtiens avec cmake 2.2-patch 3 qui est livré par défaut avec ubuntu dapper :

Scanning dependencies of target tsp_check_host_and_ip
Building C object src/util/libutil/CMakeFiles/tsp_check_host_and_ip.dir/tsp_check_host_and_ip.o
Linking C executable ../../../exec/Linux/bin/tsp_check_host_and_ip
Scanning dependencies of target tsp_hash_dump
Building C object src/util/libutil/CMakeFiles/tsp_hash_dump.dir/tsp_hash.o
Linking C executable ../../../exec/Linux/bin/tsp_hash_dump
/usr/lib/gcc/i486-linux-gnu/4.0.3/../../../../lib/crt1.o: In function `_start':../sysdeps/i386/elf/start.S:115: undefined reference to `main'
collect2: ld returned 1 exit status
make[2]: * [exec/Linux/bin/tsp_hash_dump] Error 1
make[1]: * [src/util/libutil/CMakeFiles/tsp_hash_dump.dir/all] Error 2
make: * [all] Error 2

Je n'ai pas investigué, parceque je pensais que la dernière version de cmake (2.4.2) était le prérequis, mais si on veut que 2.2-patch 3 fonctionne, je peux investiguer si vous voulez pourquoi ce problème ne semble se produire que chez moi.

 Stephane GALLES <sgalles>
Group Member
Fri 07 Jul 2006 04:29:21 AM UTC, comment #10: 

Bon, après une (assez longue) bataille j'ai moi aussi une compilation complète avec CMake (effectivement c'est très bien cet outil !)
Eric, je te confirme que
CMAKE_XML_CONFIG-NOTFOUND: command not found
était du à l'absence de libxml2-dev sur mon système. Merci pour l'info.
Dans ce que j'ai constaté d'autre :
- Eric, si tu veux le corriger, je pense que pour le module Visu3D il manque la lib pthread dans le fichier ./src/consumers/Visu3D/CMakeLists.txt
(em tous cas chez moi cela n'a pas compilé sans modif de ce fichier )
- la compilation nécessite absolument CMake 2.4.2 et pas 2.2.3 (j'ai une erreur étrange de link avec 2.2.3)
- Pour memoire voici les libs que j'ai installé pour la compil à partir d'une install standard ubuntu dapper :

libxml2-dev 2.6.24
freeglut3-dev 2.4.0-4
libxmu-dev
flex
bison
libattr1-dev
fuse-2.5.3 au lieu de 2.4.2 livré par défaut

Au fait, est ce qu'il y a une raison pour laquelle le tsp_stub_server n'a pas de CMakeLists.txt ? (à part le fait que cela n'a peut être pas encore été fait ?)

 Stephane GALLES <sgalles>
Group Member
Thu 06 Jul 2006 07:54:15 AM UTC, comment #9: 

A vu de nez je dirais qu'il n'a pas trouve xml-config.
Essaies d'installer libxml2-devel.

Pour eviter d'autre souci installes-toi aussi
gtk+1.2-devel

Je pense que ta Drapper est encore un peu denudee :))

Quoiqu'il en soit si c'est bien le probleme
le message d'erreur est tout pourri...
Je vais voir comment ameliorer ca.

Sinon je reprends la take CMake a mon compte
pour continuer le travail de Fred.

Je pense que je pourrais y travailler a partir
de Samedi, avant ca merci d'utiliser les
anciens Makefile si ca marche pas :))


Eric NOULARD <erk>
Group administrator
Thu 06 Jul 2006 04:40:44 AM UTC, comment #8: 


Ma première tentative d'utilisation de cmake a tourné court.
Aussi bien avec cmake 2.2.3 que 2.4.2, et après avoir executé :
cvs -z3 -d:pserver:anonymous@cvs.savannah.nongnu.org:/sources/tsp co tsp
cd tsp/
find . -name Makefile -exec rm {} \;
cmake -DBUILD_PROVIDER:BOOL=ON -DBUILD_CONSUMER:BOOL=ON .
make

Ma compile se termine avec un paquet d'erreurs qui commencent par :

Scanning dependencies of target tsp_page_config
Building C object src/util/libpages/CMakeFiles/tsp_page_config.dir/page_config.o
/bin/sh: CMAKE_XML_CONFIG-NOTFOUND: command not found
/home/steph/tmp/tsp/src/util/libpages/page_config.c:3:27: error: libxml/parser.h: No such file or directory
/home/steph/tmp/tsp/src/util/libpages/page_config.c:12: error: syntax error before ‘*’ token
/home/steph/tmp/tsp/src/util/libpages/page_config.c:12: warning: initialization from incompatible pointer type

Vu que je débute avec cmake+tsp, pouvez vous me dire si j'ai manqué une étape ? Merci.

 Stephane GALLES <sgalles>
Group Member
Sat 24 Jun 2006 02:59:08 PM UTC, comment #7: 

Après un test sommaire, voir ci-après mes résultats.
Je vais poursuivre mes tests et solutionner ce pb.

avec cmake 2.2.3 j'ai l'erreur.
CMake Error: can not find file /home/noularde/TSP/Contrib/FredD/CMake/tsp/src/core/rpc/tsp_rpc_clnt.c

Tried .c .C .c++ .cc .cpp .cxx .m .M .mm .h .h++ .hm .hpp .hxx .in .txx
etc...

avec cmake 2.4.2 je ne l'ai plus :))

$ cmake -DBUILD_PROVIDER:BOOL=ON -DBUILD_CONSUMER:BOOL=ON .
-- Configuring done
Warning: Source file "tsp_rpc_svc.c" is listed multiple times for target "tsp_provider".
Warning: Source file "tsp_rpc_xdr.c" is listed multiple times for target "tsp_provider".
-- Generating done
-- Build files have been written to: /home/noularde/TSP/Contrib/FredD/CMake/tsp

>>>>>>>>

Si vous voulez sauvegarder vos "anciens" Makefile TSP pour vos tests je vous conseille:
(avant essai cmake)
cd tsp
find . -name Makefile | xargs  tar zcvf ../tsp-makefiles-orig.tgz

>>>>>>>>

Pour ceux qui aiment jouer avec plusieurs version de softs
je conseille également l'utilisation de 'update-alternatives'
http://doc.domainepublic.net/linux/faq_debian-user/debfr-faq014.html

Par exemple pour s'installer 2 alternatives cmake à partir d'un cmake 2.4.2 dans /opt/cmake/2.4.2/cmake-2.4.2-Linux-i386
et cmake 2.2.3 dans /opt/cmake/2.2.3/ on peut faire:

update-alternatives --install /usr/bin/cmake cmake /opt/cmake/2.4.2/cmake-2.4.2-Linux-i386/bin/cmake 20 --slave /usr/bin/ccmake ccmake /opt/cmake/2.4.2/cmake-2.4.2-Linux-i386/bin/ccmake --slave /usr/bin/ctest ctest /opt/cmake/2.4.2/cmake-2.4.2-Linux-i386/bin/ctest --slave /usr/bin/cpack cpack /opt/cmake/2.4.2/cmake-2.4.2-Linux-i386/bin/cpack --slave /usr/share/CMake share_CMake /opt/cmake/2.4.2/cmake-2.4.2-Linux-i386/share/CMake --slave /usr/share/doc/CMake doc_CMake /opt/cmake/2.4.2/cmake-2.4.2-Linux-i386/doc/CMake --slave /usr/share/man/man1/cmake.1 cmake.1 /opt/cmake/2.4.2/cmake-2.4.2-Linux-i386/man/man1/cmake.1 --slave /usr/share/man/man1/ctest.1 ctest.1 /opt/cmake/2.4.2/cmake-2.4.2-Linux-i386/man/man1/ctest.1 --slave /usr/share/man/man1/ccmake.1 ccmake.1 /opt/cmake/2.4.2/cmake-2.4.2-Linux-i386/man/man1/ccmake.1

puis

update-alternatives --install /usr/bin/cmake cmake /opt/cmake/2.2.3//bin/cmake 10 --slave /usr/bin/ccmake ccmake /opt/cmake/2.2.3/bin/ccmake --slave /usr/bin/ctest ctest /opt/cmake/2.2.3/bin/ctest --slave /usr/share/CMake share_CMake /opt/cmake/2.2.3/share/CMake --slave /usr/share/doc/CMake doc_CMake /opt/cmake/2.2.3/doc/CMake --slave /usr/share/man/man1/cmake.1 cmake.1 /opt/cmake/2.2.3/man/man1/cmake.1 --slave /usr/share/man/man1/ctest.1 ctest.1 /opt/cmake/2.2.3/man/man1/ctest.1 --slave /usr/share/man/man1/ccmake.1 ccmake.1 /opt/cmake/2.2.3/man/man1/ccmake.1

ensuite

update-alternatives --config cmake

et c'est beau :))

Eric NOULARD <erk>
Group administrator
Wed 14 Jun 2006 08:21:31 PM UTC, comment #6: 

Après vérification c'est bien ça le pb.
Si avant de détarer le cm-xx.tar je fais
./configure
alors mon cmake passe.

Donc pour reproduire mon pb.

cd tsp
find  . -name Makefile -exec rm {} \;
cvs update -A -d
./configure
make distclean
tar xvf <pathto>/cm-01.tar
cmake -DBUILD_PROVIDER:BOOL=ON -DBUILD_CONSUMER:BOOL=ON .

Je n'ai pas encore trouvé la solution :))
Probablement que la regle
ADD_CUSTOM_COMMAND(
OUTPUT
${CMAKE_CURRENT_BINARY_DIR}/rpc/tsp_rpc_svc.c
${CMAKE_CURRENT_BINARY_DIR}/rpc/tsp_rpc_clnt.c
....
DEVRAIT plutot envoyer les fichiers générés
dans les sources (?MAKE_CURRENT_SOURCE_DIR?) ?

J'arrête la pour ce soir :((
A très bientôt :))



Eric NOULARD <erk>
Group administrator
Wed 14 Jun 2006 07:35:59 PM UTC, comment #5: 

Je suis en train de tester et j'ai un petit souci.
(Voir sortie cmake ci-après)
J'ai l'impression que le fichier:

tsp/src/core/CMakeLists.txt
présuppose que les fichiers issus de rpcgen
sont générés AVANT que rpcgen ne soit exécuté...

Je cherche mais je patauge un peu avec les
ADD_CUSTOM_COMMAND(

>>>>>>>

$ cmake -DBUILD_PROVIDER:BOOL=ON -DBUILD_CONSUMER:BOOL=ON .
CMake Error: can not find file /home/noularde/TSP/Contrib/FredD/CMake/tsp/src/core/rpc/tsp_rpc_clnt

Tried .c .C .c++ .cc .cpp .cxx .m .M .mm .h .h++ .hm .hpp .hxx .in .txx
CMake Error: can not find file /home/noularde/TSP/Contrib/FredD/CMake/tsp/src/core/rpc/tsp_rpc_xdr

Tried .c .C .c++ .cc .cpp .cxx .m .M .mm .h .h++ .hm .hpp .hxx .in .txx
CMake Error: can not find file /home/noularde/TSP/Contrib/FredD/CMake/tsp/src/core/rpc/tsp_rpc_svc.c

Tried .c .C .c++ .cc .cpp .cxx .m .M .mm .h .h++ .hm .hpp .hxx .in .txx
CMake Error: can not find file /home/noularde/TSP/Contrib/FredD/CMake/tsp/src/core/rpc/tsp_rpc_xdr.c

Tried .c .C .c++ .cc .cpp .cxx .m .M .mm .h .h++ .hm .hpp .hxx .in .txx
CMake Error: can not find file /home/noularde/TSP/Contrib/FredD/CMake/tsp/src/core/rpc/tsp_rpc_svc.c

Tried .c .C .c++ .cc .cpp .cxx .m .M .mm .h .h++ .hm .hpp .hxx .in .txx
CMake Error: can not find file /home/noularde/TSP/Contrib/FredD/CMake/tsp/src/core/rpc/tsp_rpc_xdr.c

Tried .c .C .c++ .cc .cpp .cxx .m .M .mm .h .h++ .hm .hpp .hxx .in .txx
-- Configuring done
$

>>>>>>>>>>>>

 Eric NOULARD <erk>
Group administrator
Wed 07 Jun 2006 10:13:18 AM UTC, comment #4: 

Thanks Fred,
Ok I will test this.
I add some pointer for reading about build systems:

Article initially on AutoXXX vs Cons / SCons
but with interesting references to other build related tools.
http://freshmeat.net/articles/view/889/

Some INRIA slides
http://www-sop.inria.fr/dream/seminaires/buildtools-16-11-05.pdf

Simple article from a CMake developer
http://www.linuxjournal.com/article/6700

 Eric NOULARD <erk>
Group administrator
Tue 06 Jun 2006 08:45:48 PM UTC, comment #3: 

Doh, I forgot to mention two things:
- untar in tsp root
- Launch with 'cmake -DBUILD_PROVIDER:BOOL=ON -DBUILD_CONSUMER:BOOL=ON .' (this one is less obvious ;)

Frederik Deweerdt <deweerdt>
Group administrator
Tue 06 Jun 2006 05:21:04 PM UTC, comment #2: 

Attached (cm-01.tar) is a preliminary version of a CMake build system for TSP. Tested with cmake 2.4.2 and 2.5-cvs05062006 with Linux only.
TODO:
- Add a proper detection system for external tools (rpcgen, sed, fuse). This is done sometimes, but should be generalized
- Test on other targets (particularly VxWorks, as this is the system with the most particularities)
- I think that CMAKE_SYSTEM_NAME is not enough for the build directory name, I'd like to add debug/optimized, i386, etc... Find a solution (uname may be OK)
- Have a look at ctest and what we could do with it

Frederik Deweerdt <deweerdt>
Group administrator
Tue 30 May 2006 07:32:55 AM UTC, comment #1: 

See other ML thread on this topic:
http://lists.nongnu.org/archive/html/tsp-devel/2006-05/msg00031.html

http://lists.nongnu.org/archive/html/tsp-devel/2006-05/msg00032.html

http://lists.nongnu.org/archive/html/tsp-devel/2006-05/msg00033.html

 Eric NOULARD <erk>
Group administrator
Mon 29 May 2006 07:06:45 PM UTC, original submission:  

Current TSP (as of 0.8.0) are using GNU Autotools
toolchain for build tools.
We want to evaluate a change to other more
easy to use buidl system which is:

  - portable
  - usable on Windows platform
  - handle shared library easily
  - work fro what we have done until now with autotools

Discussion began on the list
http://lists.nongnu.org/archive/html/tsp-devel/2006-05/msg00018.html

and Fred D. has began the work so
let's start the task and give it to Fred. :))

 Eric NOULARD <erk>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #10131:  cm-01.tar added by deweerdt (40KiB - application/x-tar - Preliminary CMake build system)

 

Depends on the following items: None found

Items that depend on this one
taskWindows port of TSP Core (task #5738, Ready For Test)

Digest:
   task dependencies.

 

CC list is empty

 

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

 

Follow 15 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2006-10-20 erk Open/ClosedOpen Closed
2006-10-18 erk StatusIn Progress Ready For Test
    Percent Complete90% 100%
2006-07-28 erk SummaryBuild system change: GNU Autoxxx, SCons, CMake Build system change: GNU Autoxxx --> CMake
    Carbon-Copy- Added pratal
2006-07-25 erk Dependencies- task #5738 is dependent
2006-07-24 erk Priority5 - Normal 7 - High
2006-07-14 erk Percent Complete80% 90%
2006-07-09 erk Percent Complete50% 80%
2006-07-06 erk Assigned todeweerdt erk
    Percent Complete30% 50%
2006-07-06 sgalles Carbon-Copy- Added sgalles
2006-06-06 deweerdt Attached File- Added cm-01.tar, #10131
    Carbon-Copy- Added deweerdt
2006-05-30 erk Carbon-Copy- Added erk

Back to the top

Copyright © 2024 Free Software Foundation, Inc.
Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team.
Page source code

Powered by Savane 3.14-f13d.
Corresponding source code