On 9/29/2014 4:36 PM, Alexpux wrote: > > 30 сент. 2014 г., в 0:26, Wayne Stambaugh <[email protected] > <mailto:[email protected]>> написал(а): > >> On 9/29/2014 4:02 PM, Óscar Fuentes wrote: >>> Wayne Stambaugh <[email protected] <mailto:[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. > > Mingw-w64 GCC fine with UNIX paths only if gcc spawned by MSYS process. > In this case paths are translated to Windows form. >> >> If this is indeed the case, then would an MSYS2 version of CMake work >> properly and is that even possible? > > Show me you cmake code of KiCAD that use wx-config
I'll try to create a minimal cmake project that just performs the find_package() that recreates the problem in the next day or two. I don't think you really want to check out the full KiCad source to test this. Thanks again for providing MSYS2. It really is a much better development environment than the old MSYS/MinGW. Wayne >> >> 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] >>> <mailto:[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] >> <mailto:[email protected]> >> https://lists.sourceforge.net/lists/listinfo/msys2-users > ------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk _______________________________________________ Msys2-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/msys2-users
