From: Toby C. <tob...@in...> - 2007-02-13 23:11:49
|
Hi, someone missed the update for the c++ client lib and c client lib tests for the latest player client lib change to the laser proxy...at the moment CVS wont build... Toby -- This email is intended for the addressee only and may contain privileged and/or confidential information |
From: Geoffrey B. <g....@au...> - 2007-02-14 03:50:59
|
I'm trying to use a couple of functions from interface_utils (part of libplayercore currently) in libplayerc. I've tried various different methods to get the libplayerc makefile to link in the necessary compiled objects with no success. Every time the build gets to compiling the libplayerc/teststuff it chokes, with the functions I need coming up as undefined in the link step. Methods I've tried include: - linking the interface_utils.o file directly in. - linking to the entire libplayercore library. - making interface_utils a seperate library rather than a part of libplayercore (with this one, everything else happily linked with the new library correctly, including libplayercore, except libplayerc). I've made matching modifications where appropriate in the libplayerc/test makefile.am with no change. Does anyone with more autotools experience than me know what's going on here? Geoff -- Robotics research group, University of Auckland http://www.ece.auckland.ac.nz/~gbig005/ |
From: Brian G. <br...@ge...> - 2007-02-14 23:03:44
|
On Feb 13, 2007, at 7:41 PM, Geoffrey Biggs wrote: > I'm trying to use a couple of functions from interface_utils (part of > libplayercore currently) in libplayerc. Your trouble was probably resulting from the functions having their names mangled by g++. The interface_util.cc code is really just C, so I've renamed it to interface_util.c and put extern "C" protection into interface_util.h. Note that after updating, you should delete libplayercore/.deps and then re-configure to get rid of stale dependencies on interface_util.cc. Now you have two options: (1) Include the interface_utils code into libplayerc. To do this, add $(top_builddir)/libplayercore/interface_util.lo to the _LDFLAGS and _DEPENDENCIES variables in the libplayerc Makefile.am. (2) Create a separate lib in libplayercore from interface_util.[c,h], and change pkg-config descriptions (of libplayercore, libplayerc, maybe others) to depend on the new package. If you think users of libplayerc will want to directly call functions in interface_util.c, then (2) is cleaner. If you only want to use them internally in libplayerc, then (1) is easier. brian. |
From: Geoffrey B. <g....@au...> - 2007-02-15 04:27:54
|
A perfect example of why C++ libraries are such a pain to use, as was mentioned on this list recently... Geoff Brian Gerkey wrote: > On Feb 13, 2007, at 7:41 PM, Geoffrey Biggs wrote: > >> I'm trying to use a couple of functions from interface_utils (part of >> libplayercore currently) in libplayerc. > > Your trouble was probably resulting from the functions having their > names mangled by g++. The interface_util.cc code is really just C, > so I've renamed it to interface_util.c and put extern "C" protection > into interface_util.h. Note that after updating, you should delete > libplayercore/.deps and then re-configure to get rid of stale > dependencies on interface_util.cc. -- Robotics research group, University of Auckland http://www.ece.auckland.ac.nz/~gbig005/ |
From: Geoffrey B. <g....@au...> - 2007-02-15 04:40:27
|
I added suitable string tables to Player so that names can be printed instead of numbers in messages in order to improve their readability. Having to looking up interface numbers in player.h takes too long. Brian advised me that there was some of this functionality already present in interface_util.* and so that would be the best place to put string tables relevant to the interface stuff. So I re-purposed the existing table in there to be suitable for a string table that can be rapidly looked up via direct index when a message needs to print out. I left the existing functionality in interface_util intact as it's slightly different than a string table. (Surprisingly, I found existing functionality similar to a string table also in the C client library, similarly underutilised - I decided to supersede that with this, so we don't have to maintain separate but identical string tables.) I also added a string table for message types. Error messages can now be more readable. For example: warning : skipping subscription to unknown device position2d:0 warning : unsubscription failed for device audio:0 So that this functionality is also available in the client libraries, and also client programs that may want to use it as Brian suggested, I made interface_util a separate library, "libplayerutils". I think in the near future we may want to move some other generic functionality that is independant of the transport layer and both the server and clients want into this library as well, but that's a separate matter. When/if this patch gets committed, I would encourage anyone who needs to print a message type or interface name in a message to use the lookup functions interf_to_str() and msgtype_to_str() in their message to increase readability. The patch that implements this change is now in the patch tracker. http://sourceforge.net/tracker/index.php?func=detail&aid=1660260&group_id=42445&atid=433166 Geoff -- Robotics research group, University of Auckland http://www.ece.auckland.ac.nz/~gbig005/ |
From: Radu B. R. <ru...@cs...> - 2007-02-14 23:34:20
|
Thanks, that was me. I had tests disabled in my copy (via configure) and that is why everything was running fine. Cheers, Radu. Toby Collett wrote: > Hi, > someone missed the update for the c++ client lib and c client lib tests for > the latest player client lib change to the laser proxy...at the moment CVS > wont build... > > Toby > -- | Radu Bogdan Rusu | http://rbrusu.com/ | http://www9.cs.tum.edu/people/rusu/ | Intelligent Autonomous Systems | Technische Universitaet Muenchen |