This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: cmake update needed
- From: Peter Rosin <peda at lysator dot liu dot se>
- To: cygwin-apps at cygwin dot com
- Date: Fri, 06 Feb 2015 12:41:43 +0100
- Subject: Re: cmake update needed
- Authentication-results: sourceware.org; auth=none
- References: <54D1F25E dot 20701 at gmail dot com> <BAY169-DS1438076617CAC9B60DFC2CA73A0 at phx dot gbl> <1423093749 dot 596 dot 11 dot camel at cygwin dot com> <BAY169-DS20D64B9DEEF05161FF6EEFA73B0 at phx dot gbl> <1423107612 dot 596 dot 24 dot camel at cygwin dot com> <BAY169-DS2928D017F1DAC36EBB51CA73B0 at phx dot gbl> <1423133897 dot 596 dot 29 dot camel at cygwin dot com> <BAY169-DS2660AB4CCF4A4D033C82F7A7380 at phx dot gbl> <20150206093828 dot GC1035 at calimero dot vinschen dot de> <BAY169-DS33D1C1FC1678AB7CA4EF72A7380 at phx dot gbl>
On 2015-02-06 12:04, Tony Kelman wrote:
>> Yes. It's not the task of the application to second-guess the
>> underlying "OS" (Cygwin taking the role in a way).
>
> There are various wrapper scripts in autotools to do the same thing
> (use Cygwin as a build environment for non-Cygwin compilers), they just
> tend to make decisions on what kinds of path translation to do based on
> `uname` rather than compile-time #ifdef's. Though with CMake, users can
For Libtool, the reason is that the heuristic in MSYS can't be trusted
to do path translations in the correct places.
So, there is infrastructure in place to do explicit path translation
for MSYS, and piggy-backing on that to use cygpath for explicit path
translation when using Cygwin to drive Win32 tools (such as MSVC) was
a small detail. On Cygwin, that path translation infrastructure is
completely bypassed, unless you ask for it at configure time. The only
case where it's on-by-default is MSYS (where you'll need it).
Cheers,
Peter