On 10/25/2014 4:59 PM, Brian Sidebotham wrote: > On 24 October 2014 16:31, Wayne Stambaugh <stambau...@verizon.net> 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. > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp