kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

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 <dick@xxxxxxxxxxx <mailto:dick@xxxxxxxxxxx>>
>>>
>>>     On 01/17/2013 08:56 AM, Miguel Angel Ajo Pelayo wrote:
>>>     >
>>>     >
>>>     >
>>>     > 2013/1/17 Dick Hollenbeck <dick@xxxxxxxxxxx <mailto:dick@xxxxxxxxxxx>
>>>     <mailto:dick@xxxxxxxxxxx <mailto:dick@xxxxxxxxxxx>>>
>>>     >
>>>     >     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.