kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On Jan 14, 2013 8:27 PM, "Dick Hollenbeck" <dick@xxxxxxxxxxx> wrote:
>
> I want to simplify the conversation and refer to these needed items as
windows "packages".
>
> Python
> Python-dev
> WxPython
> WxPython-dev
WxWidgets
WxWidgets-dev

6 packages, not 4.

>
> No source, nothing for our windows kicad builders to build.
>
> The 4 Packages are dowloaded from our website, and installed in known
places on every supported windows os.
>
> 4 packages  can have been built by any compiler in advance, or simply
repackaged by us in advance, but for new mingw kicad code coming in to sit
on top or to inter-operate thru the windows dll abi.
>
> I'm wanting the goal to be ageeded upon before the work begins.  I think
I've stated it here clearly.
>
> Windows ABI says the compiler used to build the 4 packages should not
matter.  Information hiding says only API headers should be necessary.
>
> On Jan 14, 2013 8:03 PM, "Dick Hollenbeck" <dick@xxxxxxxxxxx> wrote:
>>
>>
>> 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
>> >>
>> >