30 сент. 2014 г., в 17:24, Wayne Stambaugh <[email protected]> написал(а):
> 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 > > Attached is a minimum CMake project to demonstrate the problem. I left > the FindwxWidgets.cmake file debugging turn on so the output is a bit noisy. > > Running mingw64_shell.bat using the command: > > cmake -G "MSYS Makefiles" -DCMAKE_PREFIX_PATH=/mingw64 > /c/src/wx-version-test/ > > the output is: > > -- wxWidgets_FIND_COMPONENTS : gl;aui;adv;html;core;net;base;xml > -- unix style > -- NOT win32 path > -- unix find style > -- wxWidgets_SELECT_OPTIONS=--debug=no > -- > wxWidgets_CXX_FLAGS=-I/mingw64/lib/wx/include/msw-unicode-3.0;-I/mingw64/include/wx-3.0;-D_FILE_OFFSET_BITS=64;-DWXUSINGDLL;-D__WXMSW__;-fpermissive > -- wxWidgets_DEFINITIONS=_FILE_OFFSET_BITS=64;WXUSINGDLL;__WXMSW__ > -- > wxWidgets_INCLUDE_DIRS=/mingw64/lib/wx/include/msw-unicode-3.0;/mingw64/include/wx-3.0 > -- wxWidgets_CXX_FLAGS=-fpermissive > -- > wxWidgets_LIBRARIES=-L/mingw64/lib;;;-pipe;-L/mingw64/lib;-Wl,--subsystem,windows;-mwindows;-lwx_mswu_gl-3.0;-lwx_mswu_aui-3.0;-lwx_mswu_adv-3.0;-lwx_mswu_html-3.0;-lwx_mswu_core-3.0;-lwx_baseu_net-3.0;-lwx_baseu-3.0;-lwx_baseu_xml-3.0 > -- wxWidgets_LIBRARY_DIRS=/mingw64/lib;/mingw64/lib > -- _filename: _filename-NOTFOUND > CMake Error at CMakeModules/FindwxWidgets.cmake:867 (message): > wxWidgets wx/version.h file not found in > /mingw64/lib/wx/include/msw-unicode-3.0;/mingw64/include/wx-3.0. > Call Stack (most recent call first): > CMakeLists.txt:6 (find_package) > > > -- Configuring incomplete, errors occurred! > See also > "C:/msys64/home/wstambaugh/build64/wx-version-test/CMakeFiles/CMakeOutput.log». Yes, wx-config always return UNIX paths as this is bash script. Maybe after this line https://github.com/KiCad/kicad-source-mirror/blob/master/CMakeModules/FindwxWidgets.cmake#L790 Do something like: #if (MSYS) // Split wxWindgets_INCLUDE_DIRS by space and in loop convert UNIX to WINDOWS paths with // sh: // sh -c «cd $path && pwd -W» // or cygpath: // cygpath -wm $path #endif() > > >>> >>> 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 >> > > > <wx-version-test.zip>------------------------------------------------------------------------------ > 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 ------------------------------------------------------------------------------ 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
