kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On Jan 14, 2013 7:28 PM, "Wayne Stambaugh" <stambaughw@xxxxxxxxxxx> wrote:
>
> On 1/14/2013 5:05 PM, Dick Hollenbeck wrote:
>>
>>
>> On Jan 14, 2013 3:59 PM, "Wayne Stambaugh" <stambaughw@xxxxxxxxxxx
>> <mailto:stambaughw@xxxxxxxxxxx>> wrote:
>>  >
>>  > On 1/14/2013 3:12 AM, Miguel Angel Ajo Pelayo wrote:
>>  > > It's two different problems,
>>  > >
>>  > > 1) the fixswigimports.py fix the way swig (inside pcbnew.py) loads
>>  > > pcbnew.so/pyd <http://pcbnew.so/pyd> <http://pcbnew.so/pyd>
>>
>> internally, the swig generated .py
>>  > > has problems to support "internal" (inside your own program) object
>>  > > bindings. It's documented, but not widespread used. We fix it to
>> make it
>>  > > work in both cases, when doing "import pcbnew" from inside an
>>  > > scripting-pcbnew  and when doing import pcbnew from
>>  > > standalone/commandline python.
>>  > >
>>  > > 2) At the time we started with scripting, I raised some discussion
>> about
>>  > > this topic, and thought that python2.x has more widespread library
>>  > > support (compared to python 3 advantages).
>>  >
>>  > I'll take a look at it and see if I can make the KiCad scripting work
on
>>  > Python 2 & 3.  I may have to write some creative CMake code to get it
to
>>  > work but it should be possible.
>>  >
>>  > I have a quick question regarding the KICAD_SCRIPTIN_WXPYTHON option.
>>  > When this option is enabled, is wxPython.h included in any of the SWIG
>>  > generated code.  I did quick grep of the scripting folders and didn't
>>  > see wxPython.h included anywhere so the only other place I can think
>>  > that it would end up is in the SWIG generated code.  If it's not, that
>>  > will make life a whole lot easier.  If it is, building wxPython on
>>  > Windows to install the development files is proving to be painful.
>>
>> We talked about providing prebuilt [wx] python binaries.
>
>
> I still plan on attacking the problem that way.  Unfortunately and not
unexpectedly, Windows is the problem child.  You can install the prebuilt
wxPython binaries from wxpython.org but the development files come in a
separate installer and are not compatible with the MinGW binaries most
developers already have built and installed on their Windows machines.
 This means forcing FindwxWidgets to ignore the MinGW build of the
wxWidgets libraries and headers and use the prebuilt libraries and headers
installed by the development installer.  The other problem with the
prebuilt libraries is they are built with MSVC so you have to create the
library link files for MinGW to be able to link with KiCad.  It's doable
but it's not a trivial task and it's ugly.

If its ugly, then the procedure should not be part of our cmake scripts but
rather can be a separate project.

We just need binaries, headers, and stub libraries.  Not contamination of
kicad with Windows' difficulties.

>
>>
>>  >
>>  > >
>>  > >
>>  > > It's also true, that, if we made the move now, and having phoenix in
>>  > > place, it could be less disruptive if we find ourselves forced to
move
>>  > > into python3 at some moment in time.
>>  > >
>>  > > Anyway, that most probably would force us to move our wrappers into
SIP
>>  > > and get the both "wrappings" (internal wrapping, external wrapping).
>>  > >
>>  > > I'm not really opposed to do it, or do some testing, but I'm really
>>  > > concerned about:
>>  > >
>>  > > 1) SIP support (no so widespread support at swig, that will let us
work
>>  > > with other languages too)
>>  > > 2) SIP internal/external wrapping
>>  > > 3) Phoenix real support. (is it only a test branch or will it be
>>  > > supported in time?, it could also become the main branch at some
>> time..)
>>  >
>>  > Even if Phoenix becomes the default way to build wxPython, I see no
>>  > reason to switch from SWIG to SIP.  SWIG gives use the opportunity to
>>  > support other scripting languages.  SIP appears to be a Python only
code
>>  > generator.
>>  >
>>  > > 4) My time has become a little scarce: I have challenging big
projects
>>  > > for this year, and also a new (first) daughter, which I love, but
>> it's a
>>  > > time black hole 8]
>>  >
>>  > There is no better way to spend your time than with your family.
>>  >
>>  > >
>>  > >
>>  > > I think I dropped all my thoughts about the topic. :-)
>>  > >
>>  > >
>>  > >
>>  > >
>>  > > 2013/1/14 Dick Hollenbeck <dick@xxxxxxxxxxx
>> <mailto:dick@xxxxxxxxxxx> <mailto:dick@xxxxxxxxxxx
>>
>> <mailto:dick@xxxxxxxxxxx>>>
>>  > >
>>  > >     On 01/13/2013 06:57 PM, Wayne Stambaugh wrote:
>>  > >     > On 1/13/2013 4:58 PM, Miguel Angel Ajo Pelayo wrote:
>>  > >     >>> The CMake module you were looking for is FindPythonInterp
which
>>  > >     finds the Python interpreter and sets the PYTHON_EXECUTABLE
>>  > >     variable.  You can define a specific Python version by setting
>>  > >     PythonInterp_FIND_VERSION. I still have some validation to do on
>>  > >     Linux when both Python3 and Python2 are installed just to make
sure
>>  > >     everything works as expected.
>>  > >     >>>
>>  > >     >>> Also found that using "#!/usr/bin/env python2" in
>>  > >     fixswigimports.py breaks the windows build so I am currently
>> working
>>  > >     on a solution to this problem.  I changed python2 to python and
it
>>  > >     fixes the build on windows but may cause problems for Linux.
 I'm
>>  > >     thinking since the python interpreter is being called to run
this
>>  > >     script that the "#!/usr/bin/env python2" line is even necessary.
>>  > >     >>> Is there any reason to run this script outside of the KiCad
>>  > >     scripting build?
>>  > >     >> It's only needed when we make a scripting build and the
>> pcbnew.py
>>  > >     is regenerated. It will fix the way it looks for _pcbnew.so /
.pyd
>>  > >     so when running from a pcbnew with embedded python, it won't
>>  > >     >> reload the DLL and use the internal swigs to pcbnew objects.
>>  > >     >>
>>  > >     >>> If not, then I should be able to safely remove this from
>>  > >     fixswigimports.py.  If it cannot be removed, I may have to use
>> CMake
>>  > >     to generate this file on the fly to add the correct Python
>>  > >     environment string to the beginning of the file.
>>  > >     >> May be we can just call $PYTHON_EXECUTABLE fixswigimports.py,
>>  > >     most probably this little script will run within python3, but
>> not sure.
>>  > >     > The last I recall is that code generated by SWIG is not yet
>> compatible
>>  > >     > with Python 3.  That's why Python 2 is still required to build
>>  > >     wxPython.
>>  > >     >   It's been a while since I've used SWIG so maybe that has
>> changed.
>>  > >     > Until I see a wxPython release built against Python 3, I'll
>> stick with
>>  > >     > Python 2.
>>  > >
>>  > >     Swig is there now:
>>  > >
>>  > > http://www.swig.org/Doc1.3/Python.html#Python_python3support
>>  > >
>>  > >     wxpython for python 3.x is known as Phoenix, and it is also
>> probably
>>  > >     build-able at this time.
>>  > >
>>  > >
>>  > >     But they did not do the interface to C++ in Phoenix using SWIG.
>>  > >
>>  > >
>>  > >
>>
https://groups.google.com/forum/?fromgroups=#!topic/wxpython-users/p69PjUnMN-c
>>  > >
>>  > >     Used SIP instead:
>>  > >
>>  > > http://riverbankcomputing.co.uk/software/sip/intro
>>  > >
>>  > >     In any case it looks like python 3.x is an option, as it should
be,
>>  > >     since its about 5
>>  > >     years old or more.
>>  > >
>>  > >
>>  > >
>>  > >
>>  > >
>>  > >
>>  > >     _______________________________________________
>>  > >     Mailing list: https://launchpad.net/~kicad-developers
>>  > >     Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>  > >     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx
>>
>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>>
>>  > >     Unsubscribe : https://launchpad.net/~kicad-developers
>>  > >     More help   : https://help.launchpad.net/ListHelp
>>  > >
>>  > >
>>  > >
>>  > >
>>  > > --
>>  > >
>>  > > Miguel Angel Ajo Pelayo
>>  > > http://www.nbee.es
>>  > > +34 636 52 25 69
>>  > > skype: ajoajoajo
>>  > >
>>  > >
>>  > > _______________________________________________
>>  > > Mailing list: https://launchpad.net/~kicad-developers
>>  > > Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>  > > Unsubscribe : https://launchpad.net/~kicad-developers
>>  > > More help   : https://help.launchpad.net/ListHelp
>>  > >
>>  >
>>  >
>>  > _______________________________________________
>>  > Mailing list: https://launchpad.net/~kicad-developers
>>  > Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>>  > Unsubscribe : https://launchpad.net/~kicad-developers
>>  > More help   : https://help.launchpad.net/ListHelp
>>
>