[Playerstage-developers] Re: Cygwin and 1.6

[Alex R. M. <ale...@mo...>]

Brian Gerkey wrote:
> On Tue, 16 Nov 2004, Brian Gerkey wrote:
> 
>> On Tue, 16 Nov 2004, Alex R. Mosteo wrote:
>>
>>> playerclient.h contains some specs for functions returning int which 
>>> later in the implementation are declared as returning int32_t. The 
>>> gcc3.3 in cygwin chokes on it, while my 3.4 in linux doesn't say 
>>> anything. I've changed the int to int32_t. Should it be the other way 
>>> around?
>>>
>>> camera.h redefines int32_t to a different type (unsigned int instead 
>>> of long unsigned int). I've matched this redefinition. Would it be 
>>> simply better to remove it completely?
>>
>>
>> Yep, those should be fixed.  One of the problems with developing 
>> primarily
>> in Linux is that it's so forgiving.
> 
> 
> I've fixed both of these.  In the C++ client, rather than change the
> method declarations to return int32_t as Alex's patch did, I've changed
> the implementations to return int.  In general, the user shouldn't have
> to use specifically sized types, unless it's strictly necessary.
> 
> In cmucam2's camera.h, I took out the redefines of the standard types, and
> #included "playerconfig.h" instead, which defines them in a portable way.
> 
>>> cannonvcc4.cc contains a call to cfmakeraw function in termios.h 
>>> which simply doesn't exist in the termios.h supplied with cygwin. 
>>> I've commented this line. Anyone knows of some workaround? I guess 
>>> disabling this device would suffice too if you don't need it.
> 
> 
> I've added glibc's implementation of cfmakeraw(3).  It will be compiled
> into replace/libreplace.a if it's not found during configure.  I've
> changed all the drivers that call cfmakeraw(3) to #include "replace.h".
> Then they can call cfmakeraw() unconditionally, without checking
> HAVE_CFMAKERAW.

Thanks, Brian, you're really quick. I'm trying to obliterate cygwin from 
my HD to restart from scratch. I'll post any relevant news.

Kind regards,

Alex.