kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #09472
Re: Python scripting cmake build macros.
On 1/25/2013 9:13 AM, Brian Sidebotham wrote:
> More noise! This TDM version of GCC apparently has a solution for the
> CRT problem when building python extensions with standard Windows python
> installs:
>
> http://www.develer.com/oss/GccWinBinaries
Brian,
Great find! The gccmrt script described in this link is a much better
solution assuming it doesn't mangle your GCC spec file and/or your
Python system wide distutils.cfg file. I'm still not 100% sure there
wont be any side effects using a different C run time library than the
MinGW binaries are build against. I would make a back up copy of these
files before running this script just to be safe. If I get some time
this weekend, I will get copy of gccmrt and see if it works with the
current version of MinGW. Thanks for doing the leg work on this.
Wayne
>
> There may be licencing issues to think about, but as python links
> against these CRT's I don't think we should have any problems. I can
> have a look at this solution later on tonight after work.
>
> Best Regards, Brian.
>
>
> On 25 January 2013 12:55, Brian Sidebotham <brian.sidebotham@xxxxxxxxx
> <mailto:brian.sidebotham@xxxxxxxxx>> wrote:
>
> I was having a quick look at the FreeCAD project as it is a CPP
> project with python scripting integrated. Of interest is that they
> do not use anything other than the MSVC pre-build version of python.
>
> Here's a link to the README for building FreeCAD with mingw:
>
> http://free-cad.git.sourceforge.net/git/gitweb.cgi?p=free-cad/free-cad;a=blob_plain;f=README.MinGW;hb=HEAD
>
> And a relevant excerpt from that readme:
>
> o Python
> It seems to be nearly impossible to build the Python sources directly with the MinGW
> compiler. This is because some Python modules require some features which are not
> implemented on the MinGW platform. Fortunately, the Python sources are plain C code
> and instead of trying to build it with MinGW you can get a ready binary package built
> with the MSVC compiler. You can install the Python stuff whereever you want. Afterwards
> copy the include folder to C:\MSYS\1.0\local, the DLL can go to C:\MSYS\1.0\local\bin.
>
> Now we also need the so called import library. There we cannot use the .lib file which
> comes together with the installer. But it's easy to create one with the pexports/dlltool
> utilities. Assuming the Python version is 2.6 do these two steps:
>
> pexports python26.dll > python26.def
> dlltool -D python26.dll -d python26.def -l libpython26.dll.a
>
> The file libpython26.dll.a can now be moved to C:\MSYS\1.0\local\lib.
>
>
> Best Regards, Brian.
>
>
> On 24 January 2013 22:42, Brian Sidebotham
> <brian.sidebotham@xxxxxxxxx <mailto:brian.sidebotham@xxxxxxxxx>> wrote:
>
> A quick test to build wxPython with a freshly compiled
> python-mingw with binascii package results in the next problem.
> One that looks a bit more fundamental to sort out:
>
> This is what I get compiling the most basic of extension with
> this python-mingw, the error is the same when trying to build
> wxPython too:
>
> KiCad-WinbuilderC:\kicad-winbuilder-dev\kicad-winbuilder\src\wx\testmodule>python
> setup.py build -c mingw32
> running build
> running build_ext
> Warning: Can't read registry to find the necessary compiler setting
> Make sure that Python modules _winreg, win32api or win32con are
> installed.
> building 'hello' extension
> C:\kicad-winbuilder-dev\kicad-winbuilder\env\mingw\bin\gcc.exe
> -mno-cygwin -mdll
> -O -Wall
> -IC:\kicad-winbuilder-dev\kicad-winbuilder\env\python\include
> -IC:\kic
> ad-winbuilder-dev\kicad-winbuilder\env\python\PC -c testmodule.c
> -o build\temp.w
> in32-2.7\Release\testmodule.o
> Traceback (most recent call last):
> File "setup.py", line 8, in <module>
> ext_modules = [module1])
> File
> "C:\kicad-winbuilder-dev\kicad-winbuilder\env\python\lib\python2.7\distut
> ils\core.py", line 152, in setup
> dist.run_commands()
> File
> "C:\kicad-winbuilder-dev\kicad-winbuilder\env\python\lib\python2.7\distut
> ils\dist.py", line 953, in run_commands
> self.run_command(cmd)
> File
> "C:\kicad-winbuilder-dev\kicad-winbuilder\env\python\lib\python2.7\distut
> ils\dist.py", line 972, in run_command
> cmd_obj.run()
> File
> "C:\kicad-winbuilder-dev\kicad-winbuilder\env\python\lib\python2.7\distut
> ils\command\build.py", line 127, in run
> self.run_command(cmd_name)
> File
> "C:\kicad-winbuilder-dev\kicad-winbuilder\env\python\lib\python2.7\distut
> ils\cmd.py", line 326, in run_command
> self.distribution.run_command(command)
> File
> "C:\kicad-winbuilder-dev\kicad-winbuilder\env\python\lib\python2.7\distut
> ils\dist.py", line 972, in run_command
> cmd_obj.run()
> File
> "C:\kicad-winbuilder-dev\kicad-winbuilder\env\python\lib\python2.7\distut
> ils\command\build_ext.py", line 340, in run
> self.build_extensions()
> File
> "C:\kicad-winbuilder-dev\kicad-winbuilder\env\python\lib\python2.7\distut
> ils\command\build_ext.py", line 449, in build_extensions
> self.build_extension(ext)
> File
> "C:\kicad-winbuilder-dev\kicad-winbuilder\env\python\lib\python2.7\distut
> ils\command\build_ext.py", line 499, in build_extension
> depends=ext.depends)
> File
> "C:\kicad-winbuilder-dev\kicad-winbuilder\env\python\lib\python2.7\distut
> ils\ccompiler.py", line 624, in compile
> self._compile(obj, src, ext, cc_args, extra_postargs, pp_opts)
> File
> "C:\kicad-winbuilder-dev\kicad-winbuilder\env\python\lib\python2.7\distut
> ils\cygwinccompiler.py", line 164, in _compile
> extra_postargs)
> File
> "C:\kicad-winbuilder-dev\kicad-winbuilder\env\python\lib\python2.7\distut
> ils\ccompiler.py", line 925, in spawn
> spawn(cmd, dry_run=self.dry_run)
> File
> "C:\kicad-winbuilder-dev\kicad-winbuilder\env\python\lib\python2.7\distut
> ils\spawn.py", line 36, in spawn
> _spawn_nt(cmd, search_path, dry_run=dry_run)
> File
> "C:\kicad-winbuilder-dev\kicad-winbuilder\env\python\lib\python2.7\distut
> ils\spawn.py", line 69, in _spawn_nt
> rc = os.spawnv(os.P_WAIT, executable, cmd)
> AttributeError: 'module' object has no attribute 'spawnv'
>
> Basically it's down to not having pywin32 installed or any other
> win32api module. The trouble is they all seem to require
> compiling with msvc.
>
> I've run out of time again.
>
> Best Regards, Brian.
>
>
> On 24 January 2013 08:41, Brian Sidebotham
> <brian.sidebotham@xxxxxxxxx <mailto:brian.sidebotham@xxxxxxxxx>>
> wrote:
>
> I compiled python-mingw last night on a linux box with zlib
> and expat so binascii and a few other modules get built-in,
> but I ran out of time to test. I'll try and test building
> wxPython with it tonight. I had to manually point cmake to
> the libraries though, the find_package... functions do not
> appear to work even though zilb and expat are available in
> the built-in search paths.
>
> I had to patch ./Modules/socketmodule.h to change the header
> <MSTcpIP.h> to <wincrypt.h> as MinGW on my linux box didn't
> have MSTcpIP.h
>
> It appeared to build fine after that though.
>
> Best Regards, Brian.
>
>
> On 21 January 2013 21:27, Miguel Angel Ajo Pelayo
> <miguelangel@xxxxxxx <mailto:miguelangel@xxxxxxx>> wrote:
>
> Hi Brian!!,
>
> On 21/01/2013, at 20:28, Brian Sidebotham
> <brian.sidebotham@xxxxxxxxx
> <mailto:brian.sidebotham@xxxxxxxxx>> wrote:
>
>> Hi Guys,
>>
>> Sorry I'm late to the party, I've been doing wedding
>> stuff for a while. It'll continue for the next few months.
>>
>
> Hehehe, are you sure of what you're doing? (just joking,
> congratulations if I didn't already) ;)
>
>> I tried the MinGW python to build wxPython, but it
>> falls over instantly because there's no binascii
>> package. I fear that the base packages all need to be
>> built with this python first before the wxPython can
>> be built with it. It is probably worth noting to
>> anyone desperate that the multiple crt problem is only
>> apparent for Python V2.6 and greater. Python 2.5 does
>> not suffer this problem apparently.
>>
>
> Whoops, ok, binascii needed, yes I suppose that we will
> need packages here and there but eventually it must work.
>
>> Another problem is that GLCANVAS is not currently
>> supported by wxPython. But I expect that just means
>> that scripting will not have access to a 3D canvas?
>>
>
> Yes, that only means that the python side won't have
> access to the 3D canvas, but wx must be compiled with it
> enabled.
> GLCANVAS is used at the moment or in the GAL?, I've used
> 3D + wxpython in linux, for sure.
>
>> On another note, whilst building with a standard
>> python install I get the following error:
>>
>> Traceback (most recent call last):
>> File
>> "C:/kicad-winbuilder-dev/kicad-winbuilder/src/kicad/pcbnew/../scripting/fixswigimports.py",
>> line 26, in <module>
>> f = open(filename,"rb")
>> IOError: [Errno 2] No such file or directory:
>> 'C:/kicad-winbuilder-dev/kicad-winbuilder/build/release/pcbnew/pcbnew.py'
>> mingw32-make[2]: ***
>> [pcbnew/CMakeFiles/FixSwigImportsScripting] Error 1
>> mingw32-make[1]: ***
>> [pcbnew/CMakeFiles/FixSwigImportsScripting.dir/all]
>> Error 2
>> mingw32-make[1]: *** Waiting for unfinished jobs....
>> mingw32-make: *** [all] Error 2
>>
>
> Hmm, that .py is looking for the swig generated
> pcbnew.py file, to fix the way it imports. There is no
> "pcbnew.py" generated?
> is swig executed before that? (the result must be the
> .cxx/.cpp wrapper and the pcbnew.py
>
>
>> Best Regards, Brian.
>>
>> On 20 January 2013 20:55, Wayne Stambaugh
>> <stambaughw@xxxxxxxxxxx
>> <mailto:stambaughw@xxxxxxxxxxx>> wrote:
>>
>> On 1/20/2013 2:08 PM, Miguel Angel Ajo Pelayo wrote:
>> > Argh, no need to apologize Wayne, I hope they
>> can recover your system
>> > and provide you with something that works in an
>> stable way.
>> >
>> > I really hate when those things happen, 4-5
>> years ago I had a problem like
>> > this with a couple of laptops, after some time
>> we suspected of power surges
>> > in the electrical line, because some more little
>> things died around, and
>> > I was
>> > astonished with the fact that the power adapter
>> (2 different models)
>> > didn't kill those surges properly, which
>> surprisingly only killed the
>> > hard-disks ...
>> >
>> > I wish you good luck with the repair.
>> >
>> > for the time being, I've been able to build a
>> couple of packages:
>> >
>> >
>> http://dev.kicad-pcb.org/pkgs/Python-2.7.1-mingw32.tar.gz
>> >
>> http://dev.kicad-pcb.org/pkgs/Python-2.7.1-mingw32-builder.tar.gz
>> <--
>> > those are my cross build scripts at the moment
>> that expect some files in
>> > "archive" directory.
>>
>> I'll download them and take a look at them. I'm
>> using my laptop right
>> now which is way to slow to be building really big
>> projects like Python.
>> By the time I get them built, my desktop will be
>> back from HP's repair
>> department.
>>
>> >
>> > The python-2.7.1 we've built runs for win32, and
>> I'm installing it to
>> > C:\Python, but could go other places
>>
>> The binary archive is a good start but most
>> Window's users will expect
>> an installer. I didn't see any CPack stuff in the
>> CMake files used to
>> build Python so there will be a lot of work to do
>> in that regard.
>>
>> >
>> > It's important to set those vars before execution:
>> >
>> > set PYTHONHOME=C:\Python
>> > set PYTHONPATH=C:\Python\lib\python2.7;C:\Python\pyd
>> >
>> >
>> > And it also provides include files and .a libs
>>
>> These are key to building other extensions.
>>
>> >
>> > It took me ages to figure that I had missaplied
>> one of the patches (the
>> > 05 one, that needed patch -p1 instead of -p0)
>> and didn't let me build
>> > the .dll version for win32.
>> >
>> > Also "CRYPT" and "PYEXPAT" packages are disabled
>> now for a lack of
>> > libraries.
>>
>> I'm pretty sure libexpat builds on MinGW. There
>> is an expat package
>> available for MinGW. I'm not sure about the crypt
>> library.
>>
>> >
>> > This killed all my spare time from the last
>> email on the topic, which
>> > it's been a lot more than expected.
>>
>> I'm not surprised, these things always end up
>> taking more time than I
>> think they will. Thank you for all of you efforts.
>>
>> Wayne
>>
>> >
>> > I'm afraid that I'll need to ask for a lot of
>> help if we really want to
>> > build a set of shiny packages.
>> >
>> > My next step is trying to compile the wxpython +
>> kicad with this python
>> > binary package, but I will wait until you can
>> recover your data, may be
>> > others are happy trying our shiny mingw-win32
>> python package :-)
>> >
>> > Greetings, Mike
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > 2013/1/20 Wayne Stambaugh
>> <stambaughw@xxxxxxxxxxx
>> <mailto:stambaughw@xxxxxxxxxxx>
>> > <mailto:stambaughw@xxxxxxxxxxx
>> <mailto:stambaughw@xxxxxxxxxxx>>>
>> >
>> > On 1/16/2013 12:56 PM, Wayne Stambaugh wrote:
>> > > On 1/16/2013 12:16 PM, Miguel Angel Ajo
>> Pelayo wrote:
>> > >> Other option we could have right now is
>> compile out the wxpython
>> > support and provide
>> > >> only embedded python scripting + python
>> pcbnew module for windows
>> > users.
>> > >>
>> > >> In that case, next functionalities are lost:
>> > >>
>> > >> 1) PyCrust shell inside pcbnew
>> > >> 2) Ability to create and run own wx-uis
>> in the embedded python
>> > scripting.
>> > >>
>> > >> And we keep:
>> > >>
>> > >> 3) pcbnew module for commandline python
>> scripting
>> > >> 4) embedded pcbnew wizards & plugins
>> > >>
>> > >> Wayne, could you document the steps you
>> followed until now so I
>> > can try to reproduce it and fight a little
>> bit in this war ?
>> > >
>> > > Please see my response to Adam. I'll add
>> the Pthon command line
>> > > scripting build instructions for Windows
>> using MinGW to
>> > > Documentation/compiling/COMPILING.txt in
>> my next commit.
>> >
>> > Bad news Miguel. I was almost ready to
>> commit this when my home system,
>> > which I just got back from HP's warranty
>> repair service the week before
>> > Christmas, died again. I've already
>> contacted HP service but it will
>> > likely be at least a week before I get my
>> system back. Needless to say
>> > I am not happy. This will be the third time
>> (one disk drive and one
>> > motherboard) the system has had problems
>> since I bought it. I apologize
>> > for the delay. As soon as I get my system
>> back, I'll get this
>> > committed.
>> >
>> > Wayne
>> >
>> > >
>> > >>
>> > >>
>> > >> Miguel Angel Ajo
>> > >> http://www.nbee.es <http://www.nbee.es/>
>> > >> +34911407752 <tel:%2B34911407752>
>> <tel:%2B34911407752>
>> > >> skype: ajoajoajo
>> > >>
>> >
>> > <<<snipped>>>
>> >
>> >
>> >
>> >
>> > --
>> >
>> > Miguel Angel Ajo Pelayo
>> > http://www.nbee.es <http://www.nbee.es/>
>> > +34 636 52 25 69 <tel:%2B34%20636%2052%2025%2069>
>> > 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
>>
>>
>
>
>
>
>
References
-
Python scripting cmake build macros.
From: Wayne Stambaugh, 2013-01-12
-
Re: Python scripting cmake build macros.
From: Dick Hollenbeck, 2013-01-15
-
Re: Python scripting cmake build macros.
From: Dick Hollenbeck, 2013-01-15
-
Re: Python scripting cmake build macros.
From: Wayne Stambaugh, 2013-01-15
-
Re: Python scripting cmake build macros.
From: Dick Hollenbeck, 2013-01-15
-
Re: Python scripting cmake build macros.
From: Wayne Stambaugh, 2013-01-15
-
Re: Python scripting cmake build macros.
From: Wayne Stambaugh, 2013-01-15
-
Re: Python scripting cmake build macros.
From: Dick Hollenbeck, 2013-01-15
-
Re: Python scripting cmake build macros.
From: Wayne Stambaugh, 2013-01-16
-
Re: Python scripting cmake build macros.
From: Miguel Angel Ajo Pelayo, 2013-01-16
-
Re: Python scripting cmake build macros.
From: Wayne Stambaugh, 2013-01-16
-
Re: Python scripting cmake build macros.
From: Wayne Stambaugh, 2013-01-20
-
Re: Python scripting cmake build macros.
From: Miguel Angel Ajo Pelayo, 2013-01-20
-
Re: Python scripting cmake build macros.
From: Wayne Stambaugh, 2013-01-20
-
Re: Python scripting cmake build macros.
From: Brian Sidebotham, 2013-01-21
-
Re: Python scripting cmake build macros.
From: Miguel Angel Ajo Pelayo, 2013-01-21
-
Re: Python scripting cmake build macros.
From: Brian Sidebotham, 2013-01-24
-
Re: Python scripting cmake build macros.
From: Brian Sidebotham, 2013-01-24
-
Re: Python scripting cmake build macros.
From: Brian Sidebotham, 2013-01-25
-
Re: Python scripting cmake build macros.
From: Brian Sidebotham, 2013-01-25
