kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

Nice job, I am glad I was able to inspire you to see the light.

This approach puts the task firmly in your comfort zone.

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.

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. 
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.

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.

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.



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.


>
> Miguel Angel Ajo
> http://www.nbee.es
> +34911407752
> skype: ajoajoajo
>
> On 16/01/2013, at 19:50, Miguel Angel Ajo Pelayo <miguelangel@xxxxxxx> 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 <dick@xxxxxxxxxxx> 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.
>>>
>>>
>>>
>>>
>>>
>