kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #09468
Re: Python scripting cmake build macros.
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
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>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>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>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>wrote:
>>>
>>>> Hi Brian!!,
>>>>
>>>> On 21/01/2013, at 20:28, Brian Sidebotham <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>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>>
>>>>> >
>>>>> > 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
>>>>> > >> +34911407752 <tel:%2B34911407752>
>>>>> > >> skype: ajoajoajo
>>>>> > >>
>>>>> >
>>>>> > <<<snipped>>>
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> > --
>>>>> >
>>>>> > 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
>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>> More help : https://help.launchpad.net/ListHelp
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>
Follow ups
References
-
Python scripting cmake build macros.
From: Wayne Stambaugh, 2013-01-12
-
Re: Python scripting cmake build macros.
From: Wayne Stambaugh, 2013-01-13
-
Re: Python scripting cmake build macros.
From: Miguel Angel Ajo Pelayo, 2013-01-13
-
Re: Python scripting cmake build macros.
From: Wayne Stambaugh, 2013-01-14
-
Re: Python scripting cmake build macros.
From: Dick Hollenbeck, 2013-01-14
-
Re: Python scripting cmake build macros.
From: Miguel Angel Ajo Pelayo, 2013-01-14
-
Re: Python scripting cmake build macros.
From: Wayne Stambaugh, 2013-01-14
-
Re: Python scripting cmake build macros.
From: Dick Hollenbeck, 2013-01-14
-
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: 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