kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

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


Looks like hg is like git in its ability to handle multiple branches in one repo.

So I wonder if you cannot have two branches for each of the two python series (2.7.x +
3.x) in your repo.

For example let's talk about 2.7.x branch:


1) python's 2.7.x branch untouched by you.
2) your 2.7.x branch with CMake support

Running a diff against these two branches gives you the patch at any time.

I suppose a keen observer would say you can do a diff against that branch named 1)
regardless of where it exists.

There are a number ways it can be done.  Pick something you are comfortable with and lets
you track the pulls from upstream easily.

Your time is valuable, so finding smart solutions will optimally leverage your time.  Once
the python guys accept the patch, maybe the job starts to wind down.

Again, I say the best way to get them to accept it, is to compete with them on the
installer.  Go through a period where your installer/uninstaller is simply better.  And
you clearly delineate a development package, with well chosen headers and libs.