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.
_______________________________________________
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
