On 01/17/2013 11:10 AM, Wayne Stambaugh wrote: > On 1/17/2013 10:58 AM, Dick Hollenbeck wrote: >> On 01/17/2013 09:25 AM, Miguel Angel Ajo Pelayo wrote: >>> >>> >>> 2013/1/17 Dick Hollenbeck <[email protected] <mailto:[email protected]>> >>> >>> On 01/17/2013 08:56 AM, Miguel Angel Ajo Pelayo wrote: >>> > >>> > >>> > >>> > 2013/1/17 Dick Hollenbeck <[email protected] <mailto:[email protected]> >>> <mailto:[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 will help out where I can. Once Miguel has a source repo up and > running, I will check out the code and give it spin.
Awesome Wayne, thanks. This is a big job. > If we can cross > compile on Linux, we should be able to get it to build on MinGW on > Windows as well. We know we can get wxWidgets to build on MinGW so that > only leaves wxPython. Thank you Miguel for your efforts. > >> >> Good point. But when you hand somebody a cross platform build >> infrastructure on a silver >> platter, it sort of removes a lot of excuses for not offering it in the next >> distro. > I find it difficult to understand why the Python folks would not want a > larger target audience. The CMake stuff could be merged in parallel > without interfering with any of their current build system. I just > don't see any downside to this solution. > >> python 3.x is not bleeding edge. wxpython project needs a kick in the ass, >> and needs to >> get off its ass. > Them along with the wxWidgets folks. The release announcement on the > wxWidgets site states that 2.9.4 is stable enough for production use. > If that is the case, why not bump the revision to 3.0 and call it > stable? Maybe they are trying to beat Emacs record of 7 years between > stable version releases. With a CMake build infrastructure for the whole stack, and CMake install() support, CPack lets you spin out *.deb and *.rpm files also. We can decide to lead, not follow. The work done toward plugging the Windows hole, 6 packages, results in freedom on other platforms as well, all due to CMake of course. _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
