Wayne and Layne,
I have created a new KiCad OS X builder. It is posted on launchpad as https://code.launchpad.net/~mnarigon/+junk/kicad-dev.
It works on BZR5142 so hopefully you can continue your nightly builds.
Michael
1 Like
I’ve been using KiCad WinBuilder for some time on a VM, so this is pretty interesting to me. I gave it a quick test, and found one error so far. I’ve got homebrew installed, along with Python2.7 via homebrew. This created some issues with tools failing, but there’s a quick fix:
Once I followed those instructions the tools built successfully. I’m not sure if you want to automatically create a ~/.pydistutils.cfg file, but it might make sense to try and detect what Python is being used, and pop up a warning instructing the user to create the file.
Thanks for the report. I will install Homebrew on a VM and see if I can develop a workaround.
Michael
Michael,
I think creating that ~/.pydistutils.cfg file is probably ok, or possibly forcing the $PATH to use Apple’s builtin Python. I think to start, looking to see what flavor of Python is being used is probably enough, because then you can just warn the user about this issue, or maybe just automatically handle it.
After getting past that I’m now running into a few more problems, but all relatively minor!
lib-gettext failed during build, but when I went into the directory and manually built it things seemed to work fine. Unsure of what the actually problem was, but the build is continuing now. I’m not sure what went wrong, but unless it fails again I probably won’t troubleshoot this.
libpng failed to download, looks like you’ve got a bad path.
In …/kicad-dev/libraries-build/lib-png/stamp/download-lib-png.cmake:
Line 15 should read: “http://sourceforge.net/projects/libpng/files/libpng16/older-releases/1.6.10/libpng-1.6.10.tar.gz”
You were missing the “/older-releases/” part of the path. I suspect that was a recent change, and unless you did a build from scratch recently you probably missed it.
Other than that, things seem to be going well, but I’m still building tools, haven’t made it to KiCad itself yet!
Quick update, other than the three problems already mentioned, everything else seems to have worked!
This might allow me to use my VM less, that’d be really nice!
Thanks for trying it out and the feedback! I will post when I upload an update. Michael
I just tried to follow in your footsteps…
-
Yes, I also needed a ~/.pydistutils.cfg file. Contents are two lines:
[install]
prefix= -
Yes, I also needed to manually cd into gettext after the build failed and run make.
HOWEVER
I couldn’t get this to work. My changes kept getting overwritten. Modifying line 900 of scripts/CMakeLists-libraries.txt.in to contain the updated URL worked for me.
Is there any reason this script is handling dependencies itself instead of invoking Homebrew?
brew install kicad would be amazing!
There is an updated version (0.1.1) now uploaded that fixes the errors iwoloschin reported. Rather than create the .distutils.cfg file I added an empty prefix to the build command lines. It worked for me with a Homebrew python installation.
I am using a shell script/cmake/make since I eventually want to build on OS X, Windows, and Linux.
The .dmg that the build script produces is what you would install. It contains all the dependencies.
You only need to run the script if you want to develop on OS X for KiCad. My hope is the developers will start listening to OS X people and finding/fixing bugs.
I hadn’t seen Homebrew before, looks interesting.
Michael
Wow! That worked perfectly first try. Fired it off, found a dmg waiting for me on return. No need for the ~/.pydistutils.cfg file.
However, none of the apps will launch. Double-clicking in the finder does nothing. Running from the terminal just produces this:
$ open -nW /Applications/KiCad/GerbView.app
Unable to block on application (GetProcessPID() returned 18446744073709551016)
First I’ve seen this type of problem. Any ideas on how to debug it?
I think that is coming from the -nW parameters to the open. Try just using open /Applications/KiCad/GerbView.app.
There is a log file in ~/Library/Logs/org.kicad-pcb.eda that has startup messages, that might identify something.
Awesome, rebuilt everything and it’s working well!
The only big problem I’ve seen is a weird Eeschema canvas bug, in which the top left corner is being drawn different, as if it were a magnifying glass. I’d love to attach a picture, but apparently as a new user I am unable to do so :/. Instead, here’s a couple of links to my Google Drive, though this obviously might not last forever.
https://drive.google.com/file/d/0B9m0baPxbs_vN1B6TXB4UFF5MkU/edit?usp=sharing
https://drive.google.com/file/d/0B9m0baPxbs_veTFHTzl0dDZUN0E/edit?usp=sharing
Somewhat interesting, Eeschema seems to not properly redraw moving items on most of the canvas, littering random junk around until you manually Redraw (Cmd+R) the canvas. The weird magnified section seems to refresh properly though, which makes me think that the weird bit of canvas is the proper part, and the rest is an older construct that wasn’t properly removed?
Anyways, I can mostly work around this issue for now, so I will try to start using this as my default KiCad install (versus a KiCad Winbuilder build in a VM). If I need to file a bug against the main project that’s fine, but I wanted to check here first in case it’s some sort of stupid WxWidgets problem.
Just double checked some older KiCad builds from MDX4 (www.mdx4.org/index.php?/archives/55-Kicad-for-OSX-Scripting-Enabled-2014-02-26.html) and it doesn’t seem to have the same issues regarding Eeschema.
Thanks, I will look into it. The version Marco builds uses old libraries and I suspect something has changed.
Michael
So for a quick test, overnight I set up a fresh 10.9 VM, without installing Homebrew. I had to install the following applications, but it is important to note that there were obvious and clear prompts on what needed to be installed. No guessing required, nice work!
- XCode & Command Line Tools
- Bazaar (had to patch to specifically use python2.6)
- CMake
After that, things seemed to go pretty smoothly, though much slower inside the VM. One interesting thing to note, the weirdness with the Eeschema canvas is still present, but it’s more mild. The origin seems to be slightly further away from the border of the sheet (maybe different paper sizes/margins?) but also the effect itself is subdued, and moves from a major issue to a minor annoyance.
The same build, installed to my “real” 10.9 install, produces the same large canvas glitches that make it at least partially unusable. There’s far too many variables to easily compare/contrast, but I can definitely provide some feedback regarding installed libraries and other information. It seems like there might be a environment issue, perhaps something like KiCad is not using a patched WxWidgets, but instead using one that was downloaded via Homebrew for another application?
Thanks for trying it out. The builder uses the latest wxWidget libraries, and I suspect there is something in the KiCad source that is not setting up the EEschema window correctly with the latest. There also may be some OpenGL interactions. There are a fair number of #ifdefs in the KiCad source regarding the wxWindows version.
Did you actually have to install Bazaar outside of the script? The script should have built Bazaar, since it isn’t installed by default on OS X…
I agree KiCad on OS X isn’t usable, yet.
In the last few weeks, the KiCad devs have been fighting bugs with wxWindows. 2.8 is going to be deprecated any day for KiCad, and I think they’re moving to 3.1, except for some Linuxes where 3.1 has other issues (of course!)
The root cause of these OS X issues is that KiCad recently changed the way the applications work together, in something called Kiway. I am not convinced it is really ready on OS X at this point. It might be more stable to take the last revno from before the Kiway work was merged in.
You are sort of correct regarding Bazaar :). The script does not appear to need Bazaar to run, but the easiest way to grab the script is to just run a bzr branch command, so I installed Bazaar for that. I believe KiCad WinBuilder gets around this problem by posting periodic releases, similar to how you have the tarball posted. I’ll have to try that first next time.
Other than the Eeschema issue I haven’t seen any other major problems. Some weirdness in how windows are handled, but nothing too surprising for a cross platform project. There’s also a lot of WxWidgets debug messages, though I’ve been ignoring those without any obvious ill effects.
Quick additional update.
I had trouble in PCBNew getting footprints to work until I added a variable to launchd.conf:
~ $ cat /etc/launchd.conf
setenv KIGITHUB https://github.com/kicad
This does require a reboot, or at least logging out and logging back in, to ensure the variable is properly set.
Wayne,
What specifically about the KiWay work isn’t ready for OS X? Granted, I’m looking at a very user-oriented view, but it seems like things are working reasonably well, though definitely not as reliably or nicely as on Windows. If you’d like me to test anything out specifically I’m happy to try things out.
Thanks iwoloschin - I have an update that sets the environment variable. I can now download footprints from github.
Thanks bronson - I have seen where I don’t get a KiCad.app packaged in the installer. The way I have it set up the KiCad.app has all of the libraries and data in its resource folder. The installer postinstall script copies all that data out and puts it in /Library/Application Support/org.kicad-pcb.eda. Without the support information the programs don’t run. I think this is the problem you are seeing. I am trying to track it down.
I have the pretty install package working. I want to track down bronson’s bug and also get the ancillary programs starting from the KiCad buttons (they don’t work now.)
I will then post a notice on the KiCad user’s mailing list and get more use/feedback.
Thanks, Michael