kicad-developers team mailing list archive

[Adam Wolf <adamwolf@xxxxxxxxxxxxxxxxxxxx>]

I haven't been following this too closely, so this may not be possible
right now, but if someone can write a series of instructions for compiling
Kicad on Windows with Python scripting support, even if they're relatively
manual, I can spend some time automating it to make nightly builds, the
same way I am with OSX builds.

This may be a case where having me do this without doing it the best
possible way in CMake is still worth doing.  It may not.

Adam Wolf
Wayne and Layne, LLC


On Wed, Jan 16, 2013 at 11:09 AM, Wayne Stambaugh <stambaughw@xxxxxxxxxxx>wrote:

> On 1/15/2013 1:38 PM, Dick Hollenbeck wrote:
> > On 01/15/2013 12:28 PM, Wayne Stambaugh wrote:
> >> On 1/15/2013 10:16 AM, Wayne Stambaugh wrote:
> >>> On 1/15/2013 9:33 AM, Dick Hollenbeck wrote:
> >>>> On 01/15/2013 08:10 AM, Wayne Stambaugh wrote:
> >>>>> 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.
> >>>>
> >>>> We were reminded recently that stub libraries can use ordinals
> instead of names.
> >>>>
> >>>> As long as the DLL entry points follow the Windows DLL ABI  for
> argument passing and stack
> >>>> cleanup, then it is in theory possible.
> >>>>
> >>>> With so many competing ABIs on Windows, it is also in possible that
> somebody screwed up
> >>>> when building the pre-built DLLs, and you won't notice it until you
> bring in the second
> >>>> compiler technology, i.e. Mingw.
> >>>>
> >>>> In that case it might mean building the DLLs yourself, instead of
> repackaging standard
> >>>> ones.  And at that point you'd want to kick some ass, just to make
> somebody pay for their
> >>>> disregard for the rest of the [non-Microsoft] world.
> >>> Trust me, it's way past that already.  This has been a complete
> exercise
> >>> in frustration.  It really shouldn't be this difficult.
> >> The problem I am having with the MinGW build of wxPython is described at
> >> the end of the the following thread:
> >>
> >>
> https://groups.google.com/forum/?fromgroups=#!topic/wxpython-users/brmQH4FSCo4
> >>
> >> I confirmed that both msvcrt and msvcr90 are being linked to all of the
> >> wxPython extension files.
> >>
> >> Below is an explanation of the differences between the MS runtime
> libraries.
> >>
> >> http://msdn.microsoft.com/en-us/library/abx4dbyh(v=vs.80).aspx
> >>
> >> There are several solutions but none of them are attractive.
> >>
> >> 1) Rebuild Python with one of the express versions MSVC and link against
> >> msvcrt instead of the MSVC specific version.
> >>
> >> 2) Rebuild mingw10.dll and link against the same msvcr??.dll as the
> >> installed Python is build against.
> >>
> >> 3) Do as the thread above discussed and modify Python distutils to
> >> ignore the version of msvcr??.dll that Python is linked against.
> >>
> >> 4) Figure out how to build Python with MinGW.  See the following link to
> >> get an idea of how much of a task that will be.
> >>
> >> http://bugs.python.org/issue10504
> >>
> >> 5) Fix KiCad to build with the correct version of the free (as in beer)
> >> express version of MSVC used to build Python.
> >>
> >> 6) Run around the room screaming and pulling out what is left of your
> hair.
> >>
> >> At this point, my desire to see this through has dropped substantially.
> >>  In the near term, I'll just use Linux when I need to do scripting.  I
> >> will continue to chip away at it but don't expect a solution any time
> >> soon.  If anyone has a better idea, I'm open to suggestion.
> >
> >
> > Yeah, somebody could actually pay for it.
>
> I'm more than OK with that:)  It's just disappointing that we cannot
> provide our Window's users with scripting support without such a huge
> effort.
>
> >
> > Expertise and time like this is not free,  and this is a case where
> opensource fails to
> > clear this hurdle without funding.
> >
> > Notice I did not volunteer, it cannot be free.
> >
> >
> >
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>