kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

On 2/20/2017 5:48 PM, Bernhard Stegmaier wrote:
> Hi Wayne,
> 
> if you really want to have this commited soon, I’d suggest to completely
> disable KICAD_SCRIPTING_MODULES stuff on macOS.

It is disabled by default so it would be up to our package devs to build
with Python scripting disabled.  Did this ever work?  If so, it would be
nice to provide scripting support on osx.

> 
> I just had a look at the KICAD_SCRIPTING_MODULES stuff as it is now and
> I think it is broken anyway (back then when I changed the bundle stuff I
> just took what was already there).
> That’s just a guess, because I never used or tested it… so, if anybody
> did and it really works now, please tell.
> 
> I will try to have a look in my spare time, but I can’t promise that
> this will happen any time soon.
> I am very busy with non-KiCAD family things right now and there’s not a
> lot of time left.

I completely understand.  I've been busy myself.  I appreciate any help
you can give us no matter how small.

> 
> As I said in my previous mail, I don’t think that this kind of scripting
> is just a matter of copying some lib around.
> There needs to be some concept/idea how to do this nicely (or, at least
> somewhat user friendly) with app bundles.

All we are doing now is build the kiface twice.  Once for pcbnew and
once for the scripting support so there is not much of a difference.
I'm guessing that it's just a matter of making sure the copied kiface
makes it into the correct os bundle location.

> 
> How is this done on Windows?
> You also don’t have a global filesystem with one Python there where you
> just copy it into the right place… where does the Windows installer put
> those files and how do you use them from some installed Python? Are
> there issues with library paths of the library dependencies that come
> with KiCAD when used from an external Python?

I believe on windows, we supply a local python runtime environment.
Otherwise we would have to build our python support against the
installed python which on windows is built with msvc which means we have
to jump through a lot hoops to make that happen with gcc.  This solution
is far less problematic and we can ensure that the correct python
runtime environment is available.

Cheers,

Wayne

> 
> 
> Regards,
> Bernhard
> 
>> On 20 Feb 2017, at 21:50, Simon Wells <swel024@xxxxxxxxx
>> <mailto:swel024@xxxxxxxxx>> wrote:
>>
>> Hi Wayne,
>>
>> I have already sent my concerns and what i am stuck on and have had no
>> response so at this point i am unable to help sorry
>>
>> On 21 February 2017 at 07:28, Wayne Stambaugh <stambaughw@xxxxxxxxx
>> <mailto:stambaughw@xxxxxxxxx>> wrote:
>>> Simon,
>>>
>>> I'm going to commits Dick's original patch as soon as possible.  I want
>>> to know if you (or anyone else who can fix the osx part of this) will be
>>> available to fix the osx part of this before I commit it to minimize the
>>> amount of time we have broken builds for osx.
>>>
>>> Thanks,
>>>
>>> Wayne
>>>
>>> On 2/13/2017 9:24 AM, Simon Wells wrote:
>>>> Error copying file "_pcbnew.kiface" to "_pcbnew.so".
>>>>
>>>> attached is dicks patch with my changes
>>>>
>>>> On 14 February 2017 at 03:15, Wayne Stambaugh <stambaughw@xxxxxxxxx
>>>> <mailto:stambaughw@xxxxxxxxx>> wrote:
>>>>> On 2/12/2017 5:15 PM, Bernhard Stegmaier wrote:
>>>>>>
>>>>>>> On 12 Feb 2017, at 22:18, Wayne Stambaugh <stambaughw@xxxxxxxxx
>>>>>>> <mailto:stambaughw@xxxxxxxxx>> wrote:
>>>>>>>
>>>>>>> On 2/12/2017 5:37 AM, Simon Wells wrote:
>>>>>>>> i am stuck on the below as i do not understand whats trying to be
>>>>>>>> achieved doing this
>>>>>>>>
>>>>>>>> # For phase 1, copy _pcbnew.kiface to the python module. line onward
>>>>>>>> (line 733ish)
>>>>>>>>
>>>>>>>> until the end of the if, and its broken for me.
>>>>>>>
>>>>>>> It should just be a copy of the _pcbnew.kiface to the python library
>>>>>>> with the correct python extension for python to a folder where python
>>>>>>> can find it.  I'm not sure what the file extension is or where the
>>>>>>> python library install path is in osx.  I can check with Dick but I'm
>>>>>>> pretty sure by looking at the patch that is what it does.
>>>>>>
>>>>>> Did this (I guess it is using pcbnew stuff from machines python
>>>>>> installation, not the python form inside pcbnew) ever work on macOS?
>>>>>>
>>>>>> That doesn’t really make sense on macOS with application bundles
>>>>>> (IMHO).
>>>>>> The install step is just an intermediate step to create the
>>>>>> initial bundle on the build machine.
>>>>>> If you install it to some python folder on the build machine, it
>>>>>> won’t get anywhere on a users machine when installing (== copying)
>>>>>> the bundle (the bundle is not more than a folder, so you don’t
>>>>>> really “install” anything).
>>>>>>
>>>>>> One thing would probably be to create an own installer/bundle for
>>>>>> this python stuff, which puts things in the right places on the
>>>>>> destination machine. I don’t know if this is easily possible,
>>>>>> because you could have more than one python installed and I don’t
>>>>>> know about paths in libs.
>>>>>> Or, put it inside the bundle and let user handle it on his own (by
>>>>>> symlinking, whatever…).
>>>>>>
>>>>>> Same fun will come up on Linux with AppImage stuff (and the other
>>>>>> similar approaches)…
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Bernhard
>>>>>>
>>>>>
>>>>> Please send me the build output for the build failure with this patch.
>>>>> Dick offered to try to resolve it but he needs the build log.
>