30 сент. 2014 г., в 0:26, Wayne Stambaugh <[email protected]> написал(а):
> 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.
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
>
> 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
------------------------------------------------------------------------------
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
