2013/1/17 Dick Hollenbeck <[email protected]> > Nice job, I am glad I was able to inspire you to see the light. >
Just did nothing but follow the readme, it's good that you found it. I hope I will be able to port it to the latest 2.7.x python, anyway, I will consider that low priority, it's not a stopper at all. > > This approach puts the task firmly in your comfort zone. > Mine, and everybody's I hope, the python build scripts are a mess :-) > It would not be unreasonable for you to be a maintainer of your very own > Mingw-Python for > Windows binaries, you know, like a rock star, I mean package maintainer. I forked the cmake script so in the case we do some enhancements I will send them back for merge. > > Remember that python has to compile with gcc for linux, so the python > source is always > going to be mostly acceptable for mingw-gcc. > You only have to worry about the boundaries such as system calls and > library functions. > > It does not seem overly difficult to maintain a big ass patch indefinitely > if the python > guys prove too stubborn for your CMake preferences. > Well, the 2.7.x branch must be maintaned only for security and bugs, but no new features, so it should be not a problem. > You could have a separate patch for 3.x python as well, and compete with > them on superior > packaging until they see the light. Use CMake packaging to keep it simple > and fast. > Hehe, 3.x is another war, that we must fight later :-), but we must keep that in mind and write 2.7 - 3.x compatible code. > > The benefits of CMake are so extreme that I would not rule out making a > build environment > in it for wxWidgets or even wxPython. > > Just think of maintaining your trees in whatever version control system > the upstream folks > are using, this way you can always regenerate your patches. But to be > honest, you may not > even have to distribute your patches, depending on license. > Well I have no problem in distributing the patches or build script, I think it's something important to the community, to have the freedom to rebuild them as needed. > > The trees do not necessarily comprise your product, your "product" is the > 6 pre-built > Windows packages, suitable for download and installation by KiCad users as > a minimum. > > Well, I took all that mess (with the benefits too) to KiCad so It's fair to make it my task will keep you updated on the efforts, more during tomorrow night, tomorrow I must deliver some software release for a client. > > On 01/16/2013 02:52 PM, Miguel Angel Ajo Pelayo wrote: > > cmake + python 2.7.1 mingw cross compilation worked here too, for some > reason cmake tried to link > > "dl" and failed, I skipped that manually, and worked :-) > > > > That -ldl failure happened to you too Dick? > > Yes, but I did not mention it because we know how easy it is to edit > CMakeLists.txt > files. Comfortable territory. > Ok, that's good that it wasn't my system only. I'd love to be able to make the 6 stones, (prebuilt packages) and also manage to auto-build kicad for win32, so we can start delivering a testing win32 build for all the users. Anybody has experience in building windows installers with something free? > > > > > > Miguel Angel Ajo > > http://www.nbee.es > > +34911407752 > > skype: ajoajoajo > > > > On 16/01/2013, at 19:50, Miguel Angel Ajo Pelayo <[email protected]> > wrote: > > > >> This project is full of valuable developers, > >> > >> I really like the cmake / cross compiling idea, that could lead to > success and also > >> automated KiCad/Win32 builds at any time … > >> > >> I'm going to try it!! (pausing the swig-gsoc2012-doxygen tests, which > look good) > >> > >> I will also try the cross-path with Wayne instructions when they are > available and see where do we get. > >> > >> Miguel Angel Ajo > >> http://www.nbee.es > >> +34911407752 > >> skype: ajoajoajo > >> > >> On 16/01/2013, at 19:31, Dick Hollenbeck <[email protected]> wrote: > >> > >>> On 01/16/2013 11:16 AM, 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 ? > >>> > >>> > >>> In a half hour last night, I was able to cross compile python for > windows, on linux, using > >>> mingw32. > >>> > >>> Just get source to tag v2.7.1 python using hg, then apply David's > cmake patch. > >>> > >>> Build a simple CMAKE_TOOLCHAIN_FILE for your linux mingw toolset, and > it built just fine. > >>> > >>> CMake, Linux, Mingw, cross-compiling, and money are my answer to any > problems in this topic. > >>> > >>> Since they don't exist in sufficient quantity, I am now dropping out > of this topic. > >>> > >>> The talk about using microsoft tools getting pulled back into the > project are too painful > >>> to even participate in. > >>> > >>> > >>> > >>> > >>> > > > > -- 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
