kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

I want to simplify the conversation and refer to these needed items as
windows "packages".

Python
Python-dev
WxPython
WxPython-dev

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