2013/1/17 Dick Hollenbeck <[email protected]> > On 01/17/2013 08:56 AM, Miguel Angel Ajo Pelayo wrote: > > > > > > > > 2013/1/17 Dick Hollenbeck <[email protected] <mailto:[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. > > ?? > > Was thinking you would maintain a full hg python tree, with the CMake > stuff in there all > the time. > This way you can pull from upstream, and generate a diff which constitutes > the CMake patch > at any time. > > The form of David's work now is actually pretty inconvenient to use, since: > > a) it is not actually a patch but rather an overlay. > b) he makes the mingw stuff optional, and it should not be. > > In your shoes I would maintain a full separate python tree in hg, say > perhaps on google > code if they support hg. > > > Another DVCS system? (waaahhhh)... ';-)
Will give it a try when we have something that can go upstream for 3.x > > > > > > > > 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. > > It will be a larger problem getting the patch accepted here than in 3.x, > according to > python mailing list postings I've read. > > Your 3.x work is important now in my opinion. Feel free to build a team > of helpers. > > > > > > > > > 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. > > > I do not agree. The 3.x patch will be easier for the python developers to > accept, > according to mailing list postings. > > Yes, but 3.x yet feels like bleeding edge for me (wx python with 3.x still not available by default in most linux distros as Wayne investigated). I feel more like we must be prepared for the 3.x switch, but not to do it right now, because that means a some rewriting here and there in our own code (not much really, but some), and also more pain for linux users. > > > > > > > > > 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. > > Think reverse psychology.... tell them they cannot have them first.... :) > > I was thinking more about KiCad users, that python users :-), but you're right in that case :-) > > Use CPack within CMake for your windows pre-built packages, this just keys > off of the > install() commands. > > It is a totally elegant solution using NSI installer on windows. > > Nice!! :) didn't know that, that makes cmake even more awesome. > If your deliverable is superior to anything out there, i.e. the > installation package, then > folks will want to merge your diffs from your python tree. > > :-) > > > > > > > > > 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? > > I have used CPack, it hinges off of CMake install() commands, so you are > half done. > > Feel free to build a team and get maybe Wayne, Brian, and Adam to help in > the various parts. > > > > > > > > > > > > > > > > > > Miguel Angel Ajo > > > http://www.nbee.es > > > +34911407752 <tel:%2B34911407752> > > > skype: ajoajoajo > > > > > > On 16/01/2013, at 19:50, Miguel Angel Ajo Pelayo < > [email protected] > > <mailto:[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 <tel:%2B34911407752> > > >> skype: ajoajoajo > > >> > > >> On 16/01/2013, at 19:31, Dick Hollenbeck <[email protected] > > <mailto:[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 > > -- 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
