kicad-developers team mailing list archive

[Brian Sidebotham <brian.sidebotham@xxxxxxxxx>]

On 15 October 2014 21:44, Wayne Stambaugh <stambaughw@xxxxxxxxxxx> wrote:
> 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

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.