kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

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.

With a little work, the cmake scripts in python a-mingw-us could be used to provide a
sensible linux builder for linux python, and as such offer a distro independent (neutral)
strategy for installing python libraries into places fully controlled by that set of CMake
scripts.  But for now, and until someone else drove said effort, it only attempts to
service the needs of windows python a-mingw-us.


Dick



On 08/04/2013 07:04 PM, Adam Wolf wrote:
> Sorry, I was unclear.  The CMake folks haven't had an active maintainer of the Python
> modules for quite some time, and they're not going to make any changes to the Python
> modules until someone steps up to maintain the CMake Python modules on every platform--at
> least that's what they said in May.
> 
> Adam Wolf
> Wayne and Layne, LLC
> 
> 
> On Sun, Aug 4, 2013 at 6:56 PM, Dick Hollenbeck <dick@xxxxxxxxxxx
> <mailto:dick@xxxxxxxxxxx>> wrote:
> 
> 
>     On Aug 4, 2013 6:51 PM, "Adam Wolf" <adamwolf@xxxxxxxxxxxxxxxxxxxx
>     <mailto:adamwolf@xxxxxxxxxxxxxxxxxxxx>> wrote:
>     >
>     > This is a minor aside.  What's all involved in including a custom cmake module in a
>     project?  I fixed FindPythonLibs and another Python module for cmake a few months ago,
>     because right now those two stock modules don't work on Fedora or Ubuntu--which means
>     building Kicad on those platforms is trickier than you'd expect.
>     >
>     > They said my patches look fine, and they'd be glad to accept them--as soon as they
>     get a python maintainer for all of Cmake.
> 
>     "They" are python project devs, or distro folks?  Such a maintainer would maintain
>     what exactly, what project and what package?  Sorry if I am not reading well.
> 
> 
>     >
>     > Adam Wolf
>     > Wayne and Layne, LLC
>     >
>     >
>     > On Sun, Aug 4, 2013 at 6:21 PM, Brian Sidebotham <brian.sidebotham@xxxxxxxxx
>     <mailto:brian.sidebotham@xxxxxxxxx>> wrote:
>     >>
>     >> On 4 August 2013 23:45, Brian Sidebotham <brian.sidebotham@xxxxxxxxx
>     <mailto:brian.sidebotham@xxxxxxxxx>> wrote:
>     >>>
>     >>> On 4 August 2013 22:42, Brian Sidebotham <brian.sidebotham@xxxxxxxxx
>     <mailto:brian.sidebotham@xxxxxxxxx>> wrote:
>     >>>>
>     >>>> On 4 August 2013 22:19, Dick Hollenbeck <dick@xxxxxxxxxxx
>     <mailto:dick@xxxxxxxxxxx>> wrote:
>     >>>>>
>     >>>>>
>     >>>>> Any platform detection tests can cause grief, since we do not claim to be
>     Windows in the
>     >>>>> python runtime.  We claim to be "gcc compiled" with some other attribute that
>     talks about
>     >>>>> OS (cannot remember).  If you were to do a diff across the entire bracket of
>     a-ming-us
>     >>>>> revisions,
>     >>>>>
>     >>>>> bzr diff -r 1..latest  <regression tests>
>     >>>>>
>     >>>>> limited to the regression test directories,
>     >>>>> you will find one of the patches I applied to test for our platform
>     specifically.  It will
>     >>>>> be the one with "gcc" in it.  We cannot report "Windows" as our platform because
>     mingw and
>     >>>>> MSVC actually do a couple weird regression tests differently.
>     >>>>>
>     >>>>> If PyCrust is assuming a limited set of platforms, it may be coming up short and
>     running
>     >>>>> into an unsupported platform code path.
>     >>>>>
>     >>>>>
>     >>>>> Dick
>     >>>>
>     >>>>
>     >>>> Thanks for the great information Dick. I've just done a quick test directly
>     through Python-a-mingw-us:
>     >>>>
>     >>>> Python 2.7.4 (default, Mar 18 2013, 12:04:44) [gcc] on win32
>     >>>> Type "help", "copyright", "credits" or "license" for more information.
>     >>>> >>> import wx
>     >>>> >>> app = wx.App(redirect=True)
>     >>>> >>> top = wx.Frame(None, title="PyCrust Helper",size=(800,300))
>     >>>> >>> import wx.py.crust
>     >>>> >>> cframe = wx.py.crust.CrustFrame(parent = top)
>     >>>> >>> top.Show()
>     >>>> >>> cframe.Show()
>     >>>> >>> app.MainLoop()
>     >>>>
>     >>>> PyCrust crashes as soon as you focus on it. So this can at least be debugged
>     without KiCad sitting ontop.
>     >>>>
>     >>>> PyCrust has worked previously with PyCrust because I've used it. So this problem
>     shouldn't be too bad to solve.
>     >>>>
>     >>>> Thanks again.
>     >>>>
>     >>>> Best Regards, Brian.
>     >>>>
>     >>>
>     >>> The STC sample in the wxPython build (From the wxWidgets library, i.e. the cpp
>     sample) behaves exactly the same, hanging on focus. I need to fix the wxWidgets-cmake
>     project.
>     >>>
>     >>> I'm on the case and a fix should arrive in our inbox shortly! Probably just got
>     some compiler definitions wrong or something.
>     >>>
>     >>> Best Regards, Brian.
>     >>>
>     >>
>     >> Fixed! I'll release updated versions tomorrow (It takes a while to build all the
>     different versions and upload them to Launchpad!)
>     >>
>     >> That means that KiCad build is fully successful as far as I've tested so far.
>     >>
>     >> We just need to sort out the readline module in Python-a-mingw-us.I'd like to add
>     the FindPythonLibs.cmake modules and what-not to that project too, and do a debug
>     version along with a source tarball. Then people can debug their python modules
>     through the python interpreter itself too. That really helps when you're writing a
>     module in C. I'll include an example module in the install too.
>     >>
>     >> Best Regards, Brian.
>     >>
>     >>
>     >>
>     >> _______________________________________________
>     >> Mailing list: https://launchpad.net/~kicad-developers
>     >> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>     >> Unsubscribe : https://launchpad.net/~kicad-developers
>     >> More help   : https://help.launchpad.net/ListHelp
>     >>
>     >
> 
>