automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Dependencies: non-standard path to system headers


From: ineiev
Subject: Re: Dependencies: non-standard path to system headers
Date: Wed, 2 Jul 2008 13:03:38 +0400

On 7/1/08, Brian Dessent <address@hidden> wrote:
>The essential point is that using native Win32 tools with Cygwin causes
>problems.  This is because Cygwin is designed to closely emulate a POSIX
>environment, and the tools aren't equipped to deal with Win32 paths with
>drive letters.  This is not specific to 'make', it is a general fact of
>life with Cygwin.

Some strictly positive amount of interoperability exists.
When I gcc c:/cygwin/home/15-6-1/tmp/m/sample.c, it
produced a.exe (gcc 'c:\cygwin\home\15-6-1\tmp\m\sample.c', too).

sample.c contained
#include<stdio.h>
int
main(void)
{FILE*f=fopen("c:\\sample.txt","w");
 if(f){fprintf(f,"no camel\n");fclose (f);}
 else printf("fail\n");return 0;
}
, and when I ./a.exe, the named c:\sample.txt appeared
(I tried also "c:/sample.txt" with the same result).

>Since the codepaths of Cygwin ports of these tools
>are the same as the *nix codepaths, there is no guarantee that drive
>letters will work.

There is no guarantee that anything will work;^)
Actually the only thing that does not (in this case) is make.

>Now, in the specific case of GNU make there is a patch in upstream make
>to enable the handling of Win32 style paths even when built in unix
>mode.  So you should just use a more recent 'make' from CVS and it
>should just work.

Interesting. I'll try. This is possibly the most simple way to fix this.

>But again I must emphasize that the core philosophy of Cygwin is to be
>able to build *nix tools for Windows without source modification, or
>with very minimal modification.  You shouldn't be surprised then that
>these tools don't cope with Win32 paths because they wouldn't cope with
>drive letters when built under linux either, and it's the same
>codepath.  In other words, Cygwin exists specfically so that things like
>dealing with Win32 paths need NOT be added to the code -- the tools
>don't need to be "ported to Win32" they just need to be recompiled.

In my real life I need an access to RS-232 UARTs. I use W5s API,
because termios won't do it on Cygwin.

>This is far from the only example where you will encounter this clash if
>you continue to mix native apps with Cygwin tools.

The life is hard.

Best regards,
            Ineiev




reply via email to

[Prev in Thread] Current Thread [Next in Thread]