View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0005939CMakeCMakepublic2007-10-23 20:592016-06-10 14:30
ReporterBrandon Van Every 
Assigned ToBill Hoffman 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0005939: TO_NATIVE_PATH incorrect on MinGW
DescriptionA CMakeLists.txt containing:


produces the following output for a "Visual Studio 8 2005" generator:

(Press Cancel to suppress further error messages.)

which is the correct native path we'd expect. However a "MinGW Makefiles" generator produces:

(Press Cancel to suppress further error messages.)

This is wrong. The "MinGW Makefiles" generator is intended to be used by mingw32-make.exe under a Windows Command Prompt. This can only imply that "native" paths are backslashed Windows paths, not forward slashed CMake / Unix paths.
TagsNo tags attached.
Attached Files

- Relationships Relation Graph ] Dependency Graph ]
related to 0015509closedKitware Robot CMake needs a generator expression equivalent to TO_NATIVE_PATH. 

-  Notes
jorgenys (reporter)
2010-07-13 03:14

Is this really not resolved, yet?

I'm currently trying to use this to convert a path during a MinGW configuration and the resulting path is not with appropriate backslashes.

What is worse, TO_NATIVE_PATH does not seem to alter any slashes at all when using MinGW generator (when containing a mix of both, the resulting path retains the different slashes).
EricG (reporter)
2010-09-29 15:38

I'm also seeing this issue.
Thomas Thorsen (reporter)
2011-09-14 07:11

I have run into this issue as well on the MSYS Makefile generator. It is almost 4 years since this was reported, can we get some kind of indication when this will be looked at?

This facility is essential to support add_custom_commands that invoke native tools that do not understand forward slashes but also to avoid the POSIX path translation applied by MSYS when arguments are passed to a non-MSYS executable (such as cmake -E).

Here's an example invoking coverity in a custom command:

file(TO_NATIVE_PATH "${CMAKE_CURRENT_BINARY_DIR}/myfile.covout" _out_native)
file(TO_NATIVE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/myfile" _in_native)
file(TO_NATIVE_PATH "${PROJECT_BINARY_DIR}/coverity" _dir_native)

--verbose 0 --force
--dir ${_dir_native}
--redirect "stdout,${_out_native}"
DEPENDS myfile
COMMENT "Coverity translate ${_in_native}"

The problem here is that the absolute paths are converted to the format "C:/bla/bla" instead of "C:\bla\bla". This is first evident in the printout of the comment:

[ 0%] Coverity translate s;C:\MinGW\msys\1.0\sourcedirectory\myfile

While this is not fatal, the other arguments to coverity causes the MSYS POSIX path translation to mangle the path so the tool execution fails.

Experimenting with "cmake -E echo" reveals what is going on (as cmake is considered external to MSYS the parameters passed to it are subject to POSIX Path conversion, just like the custom commands in the generated build system):

> cmake -E echo "s:/sourcedirectory/myfile"

Not touched by conversion!

> cmake -E echo "Coverity translate s:/sourcedirectory/myfile"
Coverity translate s;C:\MinGW\msys\1.0\sourcedirectory\myfile

Adding the extra comment text and the conversion destroys the path! Same is happening for the --redirect argument:

> cmake -E echo "stdout,s:/sourcedirectory/myfile.covout"

Making sure the path is really native (i.e. using backslash instead of forward slash), the conversion does not destroy the path:

> cmake -E echo "Coverity translate s:\\sourcedirectory\\myfile"
Coverity translate s:\sourcedirectory\myfile

> cmake -E echo "stdout,s:\\sourcedirectory\\myfile.covout"

Consequently, the TO_NATIVE_PATH on MSYS (and possible MinGW, haven't played around with that, as it only runs in a cmd.exe which is useless for real work), should always emit paths of the form "C:\bla\bla", as that is understood by all MSYS and non-MSYS tools.

Let me know if we can do anything to help this along.
Daniel Franke (reporter)
2012-04-13 18:56

Another fun problem on MinGW (cmake-2.8.6): if one has a file to be included by the NSIS installer, one needs to pass its location along. A straightforward approach ...

set (CPACK_NSIS_DEFINES "!include ${CMAKE_CURRENT_LIST_DIR}/FileAssociation.nsh")

... fails with an NSIS error that the file was not found. If one passes the same location with '\' instead of '/', it works. So NSIS expects native names. But unfortunately


does not work do to the "native path" coming with '/' as well. Meh!
Johannes S. Mueller-Roemer (reporter)
2014-07-09 08:45

Now, almost 7 years later, I encountered this bug in the LLVM project, where type (equivalent to cat) is used which does not support forward slashes in paths.

Is this bug of such low priority that it will never be fixed? Is the assignee dead? 7 years is a long time.
Bill Hoffman (manager)
2014-07-22 11:14

I am not quite dead yet... :)

The trouble comes in here:

  this->FindMakeProgramFile = "CMakeMinGWFindMake.cmake";
  this->ForceUnixPaths = true;
  this->ToolSupportsColor = true;
  this->UseLinkScript = true;

Can someone try taking out this->ForceUnixPaths = true and see if it breaks anything else with the MinGW Makefiles?
Brad King (manager)
2014-07-22 13:34
edited on: 2014-07-22 13:34

Re 0005939:0036427: That breaks the generator because Makefile syntax wants \-escaped spaces instead of quoting.

file(TO_NATIVE_PATH) has a few problems. It uses ConvertToOutputPath which is meant to create an escaped/quoted path for writing to Makefile rules, not shells. On Windows file(TO_NATIVE_PATH) removes the double-quotes returned by ConvertToOutputPath, but on UNIX it leaves escaped spaces. This means there is no well-defined way to use the resulting value on a command-line.

file(TO_NATIVE_PATH) also outputs path lists with ;-separation even on UNIX where environment paths expect :-separation.

The behavior of the command should be redesigned and fixed with a policy.

Brad King (manager)
2014-07-22 13:37

Re 0005939:0036428: It may be tricky to define file(TO_NATIVE_PATH) correctly because the meaning of "native" depends on context even within one platform. On MSYS, for example, CMake is still a Windows application, and forward-slash paths are only "native" to the MSYS shell.

Perhaps it would be better to disallow the command completely through a policy. Project code can use string(REPLACE) to fix paths the way it needs
Johannes S. Mueller-Roemer (reporter)
2014-07-23 02:48

Re 0005939:0036428: I don't know if the list separator is really an issue, as a path list isn't really a path itself.

Re 0005939:0036429: MSYS-Makefiles and MinGW-Makefiles are two different generators though. I am talking about the second, not the first.
Brad King (manager)
2014-07-23 10:09

Re 0005939:0036433: I understand the difference between MSYS Makefiles and MinGW Makefiles, but I'm saying that the whole notion of a "native" path is not well-defined in general because we do not know whether the path is to be used in the environment, on the command line, or elsewhere. The MSYS case is one example of ambiguity.

IIRC the file(TO_CMAKE_PATH) command was created as a way to evaluate environment variables like PATH safely. Then file(TO_NATIVE_PATH) was created as the inverse of that for symmetry, but was not done correctly. Perhaps we should create a new pair of commands meant specifically for dealing with paths in environment variables, e.g. list(FROM_NATIVE_ENV) and list(TO_NATIVE_ENV). Then we can deprecate the broken file(TO_NATIVE_PATH).

In your use case I suggest using string(REPLACE) always and dropping use of file(TO_NATIVE_PATH).
Johannes S. Mueller-Roemer (reporter)
2014-07-23 11:07

IMO, "ConvertToOutputPath" is the wrong approach, as Mingw-Makefiles work just fine with backslashes inside a path, as long as they are escaped properly. Therefore wouldn't the right solution (on the CMake side of things) be to split TO_NATIVE_PATH and Makefile escaping into two separate functions?
Brad King (manager)
2014-07-23 13:13

Re 0005939:0036439: Yes, but I'm also arguing that TO_NATIVE_PATH is impossible to implement correctly. Also we can't change its behavior now without a policy, so we might as well deprecate it and define new interfaces that are better.

On the MinGW Makefiles generation side, ConvertToOutputPath is a bit of a mess left from very early days when we did not distinguish between paths meant for a Makefile rule and paths meant for a shell command within such a rule. It is not trivial to remove though because there are many distinct call paths that go through ConvertToOutputPath and they each need to be refactored properly. I've made some incremental progress on that over the years but have not had time to make a full sweep.
Kitware Robot (administrator)
2016-06-10 14:27

Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

- Issue History
Date Modified Username Field Change
2007-10-23 20:59 Brandon Van Every New Issue
2007-12-17 17:06 Bill Hoffman Status new => assigned
2007-12-17 17:06 Bill Hoffman Assigned To => Bill Hoffman
2010-07-13 03:14 jorgenys Note Added: 0021372
2010-09-29 15:38 EricG Note Added: 0022385
2011-09-14 07:11 Thomas Thorsen Note Added: 0027415
2012-04-13 18:56 Daniel Franke Note Added: 0029155
2014-07-09 08:45 Johannes S. Mueller-Roemer Note Added: 0036330
2014-07-22 11:14 Bill Hoffman Note Added: 0036427
2014-07-22 13:34 Brad King Note Added: 0036428
2014-07-22 13:34 Brad King Note Edited: 0036428 View Revisions
2014-07-22 13:37 Brad King Note Added: 0036429
2014-07-23 02:48 Johannes S. Mueller-Roemer Note Added: 0036433
2014-07-23 10:09 Brad King Note Added: 0036437
2014-07-23 11:07 Johannes S. Mueller-Roemer Note Added: 0036439
2014-07-23 13:13 Brad King Note Added: 0036440
2015-04-10 16:24 Brad King Relationship added related to 0015509
2016-06-10 14:27 Kitware Robot Note Added: 0041396
2016-06-10 14:27 Kitware Robot Status assigned => resolved
2016-06-10 14:27 Kitware Robot Resolution open => moved
2016-06-10 14:30 Kitware Robot Status resolved => closed

Copyright © 2000 - 2017 MantisBT Team
Powered by Mantis Bugtracker