← Back to team overview

kicad-developers team mailing list archive

Re: Python scripting cmake build macros.

 

On 1/16/2013 11:44 AM, Dick Hollenbeck wrote:
> 
> 
> At this point, my desire to see this through has dropped substantially.
>  In the near term, I'll just use Linux when I need to do scripting.  I
> will continue to chip away at it but don't expect a solution any time
> soon.  If anyone has a better idea, I'm open to suggestion.
> 
>>
>> Yeah, somebody could actually pay for it.
>>
>> Expertise and time like this is not free,  and this is a case where opensource fails to
>> clear this hurdle without funding.
>>
>> Notice I did not volunteer, it cannot be free.
>>
>>
> 
> 
> If someone wanted to help, you could start with this, then get it committed as part of the
> python tree.
> 
> https://github.com/davidsansome/python-cmake-buildsystem
> 
> CMake is so far superior as build system that there needs to be no discussion about it:
> 
> 
> a) CMAKE_TOOLCHAIN_FILE
> 
> b) built in cross platform scripting language, with file downloads, text processing, etc.
> 
> c) built in installer
> 
> d) built in packager

I did some homework last night which may prove to be the least amount of
effort to provide wxPython scripting support on Windows.  I downloaded
and installed the express version of VS2010 (which all current versions
of python are build with except 3.3 which uses 2012) and was surprised
to find how few build issues there were.  I haven't attempted a VS build
in over two years.  I got everything to build except pcb_calculator (due
to acosh, asinh, etc. which should be simple enough to fix) and some of
the test targets which probably should be removed from MSVC builds.  I
still have to test the wxPython scripting to make sure it works but is
builds just fine.  The good about using VS2010 is the only thing you
need to build is KiCad.  Everything else (Python, wxPython,
wxPython-dev) can be downloaded and installed.  The bad thing is that
you have to download and install VS2010.  If it works than this is the
approach I'm willing to spend time on until all the other pieces of the
puzzle can be easily built with MinGW.

> 
> 
> Somebody who cares could find out why the guys in the python project did not take David's
> work.

This sounds a lot like the link I sent to the Python bug report with the
MinGW patches.  I felt a bit sorry for the poor guy who was trying to
get his patches committed.  The Python devs appear to believe that as
long as it compiles with MS tools (free or otherwise) then that's good
enough.  Given the number of major open source projects that compile on
MinGW, you would think the Python folks would consider that a good thing.

> Or even make it current, then try again with a bigger hammer called KiCad project.
> Threaten to switch to Javascript.

As long as SWIG supports Javascript and there is there a wxJava project,
I see no reason that it couldn't be done.



References