kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 10/25/2014 4:59 PM, Brian Sidebotham wrote:
> On 24 October 2014 16:31, Wayne Stambaugh <stambaughw@xxxxxxxxxxx> wrote:
>> Brian,
>>
>> I restored the custom FindPythonLibs.cmake file.  I found an issue with
>> the stock version when configuring on MSYS2.  I made some minor changes
>> to it which should make it more robust when looking for mingw python
>> builds.  Please test it out when you get a chance and let me know if you
>> find any problems.
>>
>> Thanks,
>>
>> Wayne
>>
> 
> Hi Wayne,
> 
> Thanks for doing that. I found just one issue in the find_path() used
> to find the include file Python.h.

I'm glad that resolved the problem.  I really want to have as many
useful build alternatives as possible until we have daily binaries built
for all platforms.

> 
> I've committed a change for it as it's trivial and this fixes
> KiCad-Winbuilder again. Thanks for restoring the custom find, I'm glad
> it now works on MSYS2.

I thought that find_path() appended /include to all of the search paths
unless I'm reading the documentation incorrectly which is a distinct
possibility.  If adding include to the PATH_SUFFIXES fixes the problem
than apparently find_path() doesn't append /include.

> 
> I expect the other two PATH_SUFFIXES supplied to that find_path() are
> wrong by the way, I've not removed them in case they are actually
> correct, but generally the only suffixes searched should be the
> include directories that contain the headers files.

If you are using the native install of python with a mingw link library
(it can be done but is a major headache) then the the paths python2.7
and python27 could be the path to find the proper python.h path.  I
didn't test this so my assumption may be incorrect.

> 
> Best Regards,
> 
> Brian.
>