kicad-developers team mailing list archive

[Brian Sidebotham <brian.sidebotham@xxxxxxxxx>]

On 15 October 2014 22:44, Brian Sidebotham <brian.sidebotham@xxxxxxxxx> wrote:
> 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.

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.