On 15 October 2014 22:44, Brian Sidebotham <brian.sidebot...@gmail.com> wrote: > On 15 October 2014 21:44, Wayne Stambaugh <stambau...@verizon.net> wrote: >> On 10/15/2014 4:27 PM, Brian Sidebotham wrote: >>> On 5 October 2014 00:12, Brian Sidebotham <brian.sidebot...@gmail.com> >>> wrote: >>>> Hi Wayne, I can't check right now, but I'm sure it is to find >>>> python-a-mingw-us for kicad-winbuilder. I expect the answer is to remove >>>> the >>>> custom findpython cmake module and replace it with a findpythonamingwus >>>> module instead. >>>> >>>> Please let me introduce the latter before we remove the former; Sorry it >>>> caused you grief. >>>> >>> >>> Unfortunately we've done it the other way around in rev 5174: >>> http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/revision/5174 >>> >>> This breaks KiCad-Winbuilder, but only for new downloads because it >>> can't configure due to not being able to find the python libs. >>> Old installs still work because pythonlibs were already found by the >>> modified findpythonlibs module. >>> >>> I think the main problem is that Python-a-mingw-us which is used by >>> KiCad-Winbuilder uses a different name for the python dll. >>> >>> Best Regards, >>> >>> Brian. >>> >> >> It was worth a try. The problem with the stock FindPythonLibs.cmake is >> that it doesn't have a default variable (either environment or CMake >> definition) that allows you to add to the PATH statement in the >> find_library() command. This way you could just define the path during >> the build config because in your case you already know the path. I >> guess I'll have to put the custom version back and fix it so it works on >> MSYS2. Before I do that, what is the python-a-mingw-us link library >> path and file name? Maybe I can figure out a way to use the stock one >> with kicad-winbuilder without breaking the msys2 builds. >> >> Wayne > > I think the better way is for me to generate a new > findpythonamingwus.cmake module which can exclusively find a > python-a-mingw-us install. > > This can go in our custom cmakemodules directory and then we can either: > > if( PYTHON_NOFOUND ) > FindPythonAMinGWUs() > > or > > if( MINGW AND NOT MSYS ) > FindPythonAMinGWUs() > > to use findpythonamingwus instead of the stock findpython module. I > agree using the standard install versions where we can is the best > way. > > The reason you see if( MINGW ) clauses in the custom findpython module > is because it was at the time the only sane option for building python > modules with MinGW because otherwise you'd end up with multiple c > runtimes linked which would cause havoc. > > Now that there is a pure MinGW version of python available under msys2 > the if( MINGW ) clauses are not correct because you don't want to > search for python-a-mingw-us when you're using msys2. > > Returning to the custom one until I introduce the new one would be the > best solution for me. Our baby is currently cutting teeth so time is > scarce for KiCad development at the moment, but I promise to get it > sorted as soon as possible. It should just be a case of stripping down > the custom version to stop it detecting a standard python install and > to just look for the python-a-mingw-us install. > > Best Regards, > > Brian.
Also, SelectLibraryConfigurations.cmake is there purely for our old FindPythonLibs.cmake, so if that's gone, then SelectLibraryConfigurations.cmake can go too. 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
