kicad-developers team mailing list archive

[Brian Sidebotham <brian.sidebotham@xxxxxxxxx>]

On 5 August 2013 06:49, Dick Hollenbeck <dick@xxxxxxxxxxx> wrote:

> I would think you can put such a file into our CMakeModules dir and it
> will be used
> instead of an identically named one installed with CMake.  Yours sound
> like linux related
> edits, so those would have to be merged with any similar constructs that
> are done for windows.
>
> We have done this for other CMake modules, overriding the standard CMake
> ones from time to
> time.  Or you can simply use another name, unique, and rely on it instead
> of the strategy
> used in the CMake package module.
>
> With such a strategy you do not have to sign on to become a life long CMake
> committer/maintainer.  :)
>
>
> Really part of the problem is the mess that python has become wrt to
> locations of
> libraries.  IMO it was a mess on nearly the first day, and made worse by
> the laggard
> transition to newer versions of python.  It is my understanding that
> blender installs
> their own python environment as part of that package, and I don't blame
> them.
>
>
This is how KiCad should go on Windows as far as I'm concerned. We install
Python-a-mingw-us as part of KiCad. The only caveat is that KiCad should
set PYTHONHOME and PYTHONPATH for itself and for the processes it launches
(such as PCBNEW).

It's the easiest way on Windows. FreeCAD and Inkscape both have the same
approach. It's a well walked path these days I think.

Best Regards, Brian.