On 9/29/2014 4:02 PM, Óscar Fuentes wrote: > Wayne Stambaugh <[email protected]> > writes: > >> I am having issues again with CMake path parsing. Using the CMake >> file() command this does not work: >> >> file( READ /mingw64/include/wx-3.0/wx/version.h _var) >> >> but this does: >> >> file( READ c:/msys64/mingw64/include/wx-3.0/wx/version.h _var) >> >> I'm running CMake with the -G "MSYS Makefiles" so msys style paths >> should work. Msys style paths work fine on MSYS1/MinGW32 using the >> native build of both CMake 3.0.2 and 2.8.12 so something is not quite >> right with the way msys2 is handling paths. Any ideas? > > Native CMake does not understand MSYS{2} pathnames. The `file' command > is executed by CMake and is independent of the selected generator. If > something like > > file( READ /mingw/blah var ) > > ever worked for you, it is because you had mingw installed on c:/mingw > and the current drive was C:.
So this "bug" has allowed me to build KiCad for last 8 years on MSYS1/MinGW without issue? The question is, how did any of this ever work on MSYS2? If I remove the offending code from my custom FindwxWidgets.cmake, I can build KiCad on MSYS2 just fine. A quick look at one of the build statements: cd /C/msys64/home/wstambaugh/build64/kicad/product-release/bitmaps_png && /C/msys64/mingw64/bin/g++.exe -DHAVE_STDINT_H -DHAVE_SVN_VERSION -DKICAD_KEEPCASE -DUSE_OPENMP -DWXUSINGDLL -DWX_COMPATIBILITY -D_FILE_OFFSET_BITS=64 -D_UNICODE -D__WXMSW__ -Wall -fopenmp -Wno-unused-local-typedefs -Wno-strict-aliasing -fpermissive -O2 -DNDEBUG -I/C/msys64/home/wstambaugh/src/kicad/product/include -I/C/msys64/home/wstambaugh/src/kicad/product/bitmaps_png/. -isystem /mingw64/lib/wx/include/msw-unicode-3.0 -isystem /mingw64/include/wx-3.0 -I/C/msys64/home/wstambaugh/src/kicad/product/boost_root/include/boost-1_54 -I/C/msys64/home/wstambaugh/build64/kicad/product-release -o CMakeFiles/bitmaps.dir/cpp_26/add_keepout_area.cpp.obj -c /C/msys64/home/wstambaugh/src/kicad/product/bitmaps_png/cpp_26/add_keepout_area.cpp shows that the wxWidgets include path statements passed to gcc are msys paths. So the mingw64 version of gcc must be fine with msys paths otherwise the wxWidgets headers and link libraries would not be found. If this is indeed the case, then would an MSYS2 version of CMake work properly and is that even possible? FYI, I tried using CMake's file() TO_CMAKE_PATH and TO_NATIVE_PATH but no luck. They both just returned the same path. > > > ------------------------------------------------------------------------------ > Slashdot TV. Videos for Nerds. Stuff that Matters. > http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk > _______________________________________________ > Msys2-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/msys2-users > ------------------------------------------------------------------------------ Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk _______________________________________________ Msys2-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/msys2-users
