30 сент. 2014 г., в 16:28, Wayne Stambaugh <[email protected]> написал(а):
> On 9/29/2014 11:06 PM, Alexey Pavlov wrote:
>>
>> 30 сент. 2014 г., в 6:13, 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
>>>
>>> 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.
>>
>> Why not use last FindwxWidgets.cmake module from CMAKE itself rather using
>> KiCAD module?
>> Or maybe update module in KiCAD sources.
>
> Unfortunately the stock version of FindwxWidgets.cmake doesn't perform
> version testing so calling:
>
> find_package( wxWidgets 3.0.0 COMPONENTS gl aui adv html core net base
> xml REQUIRED )
>
> will still find wxWidgets even if the version is 2.8.12. There are some
> other problems with cross building that we fixed as well. I've recently
> added the version checks so that I could force the version of wxWidgets
> to 3 or greater for building KiCad.
Why then not check version via «wx-config —version» instead headers
>
>>
>> Regards,
>> Alexey.
>>>
>>> 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
>>
>>
>
>
>
> ------------------------------------------------------------------------------
> 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
