Hello! > This is what I'd expect.
Good then. > > 2. PATH_SEPARATOR on Cygwin is ':' and on pure DOS/Windows is ';'. > > This is true, but how is this relevant to the issue at hand? > 'abspath' does not deal with PATH-style directory lists, it accepts a > single file name as its argument. What am I missing here? To the issue - no, this really doesn't relate. But this is still involved in the change, because path list is one more thing which depends on native path style of underlying environment. > It probably would, if you do a clean job, but frankly I'm not sure it's > worth your while. It is so easy to glean this information by just > looking at the appropriate preprocessor macro, like WINDOWS32 etc. that > a configure-time test sounds like overkill. Yes, but there can be one thing, considering MinGW. If you don't know, MinGW actually consists of two environments: MinGW by itself and MSYS. MinGW by itself is a pure Windows environment. MSYS is enlightened version of Cygwin whose purpose is "to provide enough compatibility to run UNIX shell scripts like configure". MinGW land uses DOS-style paths and MSYS land uses UNIX-style ones. Consequently, they actually build two versions of make. One version is called 'mingw-make' and is a pure Windows program. Another version is called 'make' and operates in MSYS land, dealing with UNIX-style paths and path lists. They do this because majority of build systems use POSIX semantics. Both versions are built from the same source. Consequently, there should be a possibility to override "native path format" test, similar to what Cygwin currently does to disable DOS paths. This can be needed for building MSYS version. Ok, good, currently i already have an implementation which works fine on Cygwin and passes all test suite. Now i want to try to build pure Windows version and make sure that it at least doesn't become worse. I need some time to test it and to approve the patch for submission here at Samsung. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
