kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 10/15/2014 4:27 PM, Brian Sidebotham wrote:
> On 5 October 2014 00:12, Brian Sidebotham <brian.sidebotham@xxxxxxxxx> 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