kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 1/14/2013 10:15 PM, Dick Hollenbeck wrote:
> 
> On Jan 14, 2013 8:27 PM, "Dick Hollenbeck" <dick@xxxxxxxxxxx
> <mailto: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

wxPython-dev includes wxWidgets-dev so it should work fine for KiCad
builds without scripting as well.  It should just be a matter of
creating the MinGW linker stubs to the MSVC built libraries provided by
the wxPython-dev package.  The only caveat may be if there is any name
mangling issues between the two linkers.  This could handled by Brian's
Windows build script which would prevent the Windows build stuff out of
the KiCad CMake files.  This is the option I haven't tried yet.

The other option is providing MinGW builds of wxPython and wxPython-dev.
 I have attempted this with no success. I can build and install wxPython
with MinGW from source but I get library errors when I attempt to run it
from the Python interpreter.  To be honest I have not spent a lot of
time with this but it is more involved than a trivial build and install
from source with MinGW.

For user builds my preference is the first option since the wxPython
folks already provide the binaries.  For development purposes, I prefer
option 2 this way I can use my own debug builds of wxWidgets for obvious
reasons.  I definitely would like to get this resolved so I can use the
full scripting capabilities build into KiCad on Windows.  It's just a
matter of finding the time to figure it out.

> 
> 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
> <mailto:dick@xxxxxxxxxxx>> wrote:
>>>
>>>
>>> On Jan 14, 2013 7:28 PM, "Wayne Stambaugh" <stambaughw@xxxxxxxxxxx
> <mailto: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>
>>> >> <mailto: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>
> <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 <http://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>>
> <mailto: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>>
>>> >>  > >     <mailto: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>
>>> >> <mailto: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>
>>> >> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx
> <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>>
>>> >>  > Unsubscribe : https://launchpad.net/~kicad-developers
>>> >>  > More help   : https://help.launchpad.net/ListHelp
>>> >>
>>> >
>