I'm really amazed to see what you got here. I'm a little off the project lately (just reading your efforts and changes weekly while doing non-stop-work, in the hope to be back soon).
I felt that I had to write and say THANKS. You're awesome developers and a great team. Soon I will be having some vacation, and I expect to put a few days in the scripting api documentation project, I had a plan that I wanted to test. Again, thanks for all the hard work, and *congratulations*. Brian: I didn't understand, but what was the problem with pycrust exactly? 2013/8/5 Dick Hollenbeck <[email protected]> > I would think you can put such a file into our CMakeModules dir and it > will be used > instead of an identically named one installed with CMake. Yours sound > like linux related > edits, so those would have to be merged with any similar constructs that > are done for windows. > > We have done this for other CMake modules, overriding the standard CMake > ones from time to > time. Or you can simply use another name, unique, and rely on it instead > of the strategy > used in the CMake package module. > > With such a strategy you do not have to sign on to become a life long CMake > committer/maintainer. :) > > > Really part of the problem is the mess that python has become wrt to > locations of > libraries. IMO it was a mess on nearly the first day, and made worse by > the laggard > transition to newer versions of python. It is my understanding that > blender installs > their own python environment as part of that package, and I don't blame > them. > > With a little work, the cmake scripts in python a-mingw-us could be used > to provide a > sensible linux builder for linux python, and as such offer a distro > independent (neutral) > strategy for installing python libraries into places fully controlled by > that set of CMake > scripts. But for now, and until someone else drove said effort, it only > attempts to > service the needs of windows python a-mingw-us. > > > Dick > > > > On 08/04/2013 07:04 PM, Adam Wolf wrote: > > Sorry, I was unclear. The CMake folks haven't had an active maintainer > of the Python > > modules for quite some time, and they're not going to make any changes > to the Python > > modules until someone steps up to maintain the CMake Python modules on > every platform--at > > least that's what they said in May. > > > > Adam Wolf > > Wayne and Layne, LLC > > > > > > On Sun, Aug 4, 2013 at 6:56 PM, Dick Hollenbeck <[email protected] > > <mailto:[email protected]>> wrote: > > > > > > On Aug 4, 2013 6:51 PM, "Adam Wolf" <[email protected] > > <mailto:[email protected]>> wrote: > > > > > > This is a minor aside. What's all involved in including a custom > cmake module in a > > project? I fixed FindPythonLibs and another Python module for cmake > a few months ago, > > because right now those two stock modules don't work on Fedora or > Ubuntu--which means > > building Kicad on those platforms is trickier than you'd expect. > > > > > > They said my patches look fine, and they'd be glad to accept > them--as soon as they > > get a python maintainer for all of Cmake. > > > > "They" are python project devs, or distro folks? Such a maintainer > would maintain > > what exactly, what project and what package? Sorry if I am not > reading well. > > > > > > > > > > Adam Wolf > > > Wayne and Layne, LLC > > > > > > > > > On Sun, Aug 4, 2013 at 6:21 PM, Brian Sidebotham < > [email protected] > > <mailto:[email protected]>> wrote: > > >> > > >> On 4 August 2013 23:45, Brian Sidebotham < > [email protected] > > <mailto:[email protected]>> wrote: > > >>> > > >>> On 4 August 2013 22:42, Brian Sidebotham < > [email protected] > > <mailto:[email protected]>> wrote: > > >>>> > > >>>> On 4 August 2013 22:19, Dick Hollenbeck <[email protected] > > <mailto:[email protected]>> wrote: > > >>>>> > > >>>>> > > >>>>> Any platform detection tests can cause grief, since we do not > claim to be > > Windows in the > > >>>>> python runtime. We claim to be "gcc compiled" with some other > attribute that > > talks about > > >>>>> OS (cannot remember). If you were to do a diff across the > entire bracket of > > a-ming-us > > >>>>> revisions, > > >>>>> > > >>>>> bzr diff -r 1..latest <regression tests> > > >>>>> > > >>>>> limited to the regression test directories, > > >>>>> you will find one of the patches I applied to test for our > platform > > specifically. It will > > >>>>> be the one with "gcc" in it. We cannot report "Windows" as > our platform because > > mingw and > > >>>>> MSVC actually do a couple weird regression tests differently. > > >>>>> > > >>>>> If PyCrust is assuming a limited set of platforms, it may be > coming up short and > > running > > >>>>> into an unsupported platform code path. > > >>>>> > > >>>>> > > >>>>> Dick > > >>>> > > >>>> > > >>>> Thanks for the great information Dick. I've just done a quick > test directly > > through Python-a-mingw-us: > > >>>> > > >>>> Python 2.7.4 (default, Mar 18 2013, 12:04:44) [gcc] on win32 > > >>>> Type "help", "copyright", "credits" or "license" for more > information. > > >>>> >>> import wx > > >>>> >>> app = wx.App(redirect=True) > > >>>> >>> top = wx.Frame(None, title="PyCrust Helper",size=(800,300)) > > >>>> >>> import wx.py.crust > > >>>> >>> cframe = wx.py.crust.CrustFrame(parent = top) > > >>>> >>> top.Show() > > >>>> >>> cframe.Show() > > >>>> >>> app.MainLoop() > > >>>> > > >>>> PyCrust crashes as soon as you focus on it. So this can at > least be debugged > > without KiCad sitting ontop. > > >>>> > > >>>> PyCrust has worked previously with PyCrust because I've used > it. So this problem > > shouldn't be too bad to solve. > > >>>> > > >>>> Thanks again. > > >>>> > > >>>> Best Regards, Brian. > > >>>> > > >>> > > >>> The STC sample in the wxPython build (From the wxWidgets > library, i.e. the cpp > > sample) behaves exactly the same, hanging on focus. I need to fix > the wxWidgets-cmake > > project. > > >>> > > >>> I'm on the case and a fix should arrive in our inbox shortly! > Probably just got > > some compiler definitions wrong or something. > > >>> > > >>> Best Regards, Brian. > > >>> > > >> > > >> Fixed! I'll release updated versions tomorrow (It takes a while > to build all the > > different versions and upload them to Launchpad!) > > >> > > >> That means that KiCad build is fully successful as far as I've > tested so far. > > >> > > >> We just need to sort out the readline module in > Python-a-mingw-us.I'd like to add > > the FindPythonLibs.cmake modules and what-not to that project too, > and do a debug > > version along with a source tarball. Then people can debug their > python modules > > through the python interpreter itself too. That really helps when > you're writing a > > module in C. I'll include an example module in the install too. > > >> > > >> Best Regards, Brian. > > >> > > >> > > >> > > >> _______________________________________________ > > >> Mailing list: https://launchpad.net/~kicad-developers > > >> Post to : [email protected] > > <mailto:[email protected]> > > >> Unsubscribe : https://launchpad.net/~kicad-developers > > >> More help : https://help.launchpad.net/ListHelp > > >> > > > > > > > > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : [email protected] > 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 : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
