Ok, I know I haven’t released any of my KiCad builds in a while. Well, I’ve been working on a better solution than doing custom builds of KiCad.
Now you can do brew install kicad and build the latest revision at will. This is the initial ‘release’ and there are likely some issues, and definite improvements I will be making when I get time to cut down the build time (we really only should build the custom version of wx once, not every time, for example).
And please, if you have problems, create an issue on github, and if you’re willing, also in this thread, for maximum visibility. Don’t be discouraged if things don’t work, because if you create an issue about your problem, I will do my best to fix it in a day or two, time permitting.
I hope it works. I’m excited to hear if it does, and if it doesn’t, I’ll do my best to figure out the problem. Preemptive apologies just in case, considering how long it takes to build.
Also, I forgot to mention, its vital you update any package dependencies to the latest version, especially boost. Make sure you have boost 1.57 installed via homebrew.
The one thing missing is the documentation, but as soon as I figure out the full URLs for launchpad repos, I will add a formula for the documentation as well.
Have you updated Xcode to the latest version? If not, please do that and make sure your command line tools are up to date as well. You should have Xcode 6.1, and if you do, double check the command line tools with the command xcode-select -printpath
It should be pointing to somewhere in /Applications/Xcode.app. If not, sudo xcode-select -switch /Applications/Xcode.app will ensure your command line tools are up to date.
If all that checks out, I hate to ask this, but if you could rerun the install but with --verbose set as well, and gist the output, that will be extremely helpful.
Squeegy, ignore my precious reply. I just saw your other thread. It appears you have an old framework release of Cairo on your system installed to /Libray/Frameworks. This is a bad idea and will interfere with any homebrew formulae that use Cairo as a dependency. Please uninstall or otherwise remove /Library/Frameworks/Cairo.framework and this should resolve both your manual build and homebrew issue at once.
I had removed that framework temporarily, and it didn’t help my manual build. It just complained Cairo wasn’t there. I’ve moved it out again and I’m trying that again with your brew script now. Fingers crossed!
After a mv /Library/Frameworks/Cairo.framework ~/Cairo.framework, your brew installed cairo dependency and it compiled and 45 minutes later, full success. CvPcb now even has footprints listed in it for the first time I’ve seen.
I’m a big KiCad newb, but plan on spending more time with it this weekend, and I’ll let you know if anything weird pops up.
Great! By the way, Cairo does not provide a framework for OS X anymore, and the supported usage is by building .dylibs instead. In fact, the website recommends using a package manager (like mac ports, fink, or homebrew) to install cairo, as it will be built as a dylib and installed where programs can find it. I am not sure where it came from, but if you need to use it in framework form, I would recommend seeing if you can find (or build) the most recent version, and make sure to make it universal so it includes 64-bit code in the framework. The one you have is 32-bit only, but building under Yosemite requires linking to 64-bit AND 32-bit, or 64-bit only, anything 32-bit only cannot be used. That is what the missing symbols error was saying - that needed 64-bit code in Cairo weren’t there.
However, if you don’t need it as a framework, the version installed by homebrew is fine and tools like autotools or cmake will find and link to it without issue. You can link to it manually too, all the binaries are located under /usr/local/lib/libcairo*.
Anyway, good luck. Also, homebrew doesn’t know to update --HEAD formula, so if you want to move up to a newer revision, you will want to run brew reinstall kicad --HEAD --without-kicad-library . This will upgrade it without wasting time on the library, which is updated every time you access it in KiCad (which is awesome! And why its on github!).
Unfortunately, it will still be a lengthy build every time, for now. I am working on making it reuse the patched wx files, but it will be a bit until that’s finished.
The OpenGL renderer is the only one actively being worked on for OS X I believe. Cairo does not use hardware acceleration and renders entirely in software, which is a limitation of the Cairo project and not an issue with KiCad. Ths Cairo render is intended for Linux systems, only the OpenGL render should be used on OS X. But, it has been improving rapidly and the artifacts are probably simply a bug. I’ll double check, but I don’t think it’s causes by anything in the formula.
@Squeegy: I am unable to reproduce those artifacts on my machine. It’s possible it was a bug specific to the revision that the repo was at when you built it, and and has since been fixed.
Otherwise, it would seem to be a bug specific to certain versions of OS X or GPU hardware, which is probably something we need to track down. I certainly understand if you would prefer not to share this information, but if you don’t care, it would be helpful to know which model of mac you are on. Also, from the build logs you posted, I see you’re on OS X 10.10. I am running 10.10.1 and 10.10.2 (pre-release, for development reasons), and I can’t see artifacts in either of those. 10.10.1 fixes a lot of bugs and doesn’t break anything, so I am wondering if that is the issue?
I have no idea. I’ll link your post and screenshots to the develeoper mailing list soon, if you’re willing to share the information I requested, it would be helpful. And I 100% understand if you would rather not, too. Just thought I’d ask :).
Some more wierdness in pcbNew. I have to switch between OpenGL and default view modes quite a bit since different things work in different modes. I realized they aren’t just rendering modes, things behave differently.
In OpenGL it when routing a trace it will go around things and find a winding path to my cursor, which it won’t do in “default” mode. However, when it does there is a good chance it will crash (log here). Short traces that don’t have to go around anything work fine. No crash happens in the default mode, but the trace don’t automatically dodge other components either.
In OpenGL there are now arrows pointing to the spots that have DRC errors like there are in default mode. Nor is there the same info on the bottom of the window (“Unconnected pins: 3”, etc.)
And those minor OpenGL artifacts seem to go away once I work with the board for a bit.
Again, no idea if these are issues with my machine only, issues with the built mac version, or issues with KiCad in it’s current state of development. So let me know if this is a poor venue for these reports, I’m new here
OK, I think there is a good chance the near-instant crash that the “route around” option is caused by how my homebrew formula handles the boost dependency. I am waiting on a local build that should either confirm or falsify this hunch for sure.
As for the click down menus, that is a bug in KiCad itself. Uh, I’ve gotten so used to using the arrow keys and return to do pulldown selections in KiCad I straight up forgot about this. That is because been a bug for well over a year, and you know how CAD goes…after a while it’s half muscle memory.
Here is the bug report, it’s known and unfixed. I’ll see if it can get more attention. ‘Getting used’ to a workaround doesn’t make it not a workaround for something that should be fixed. In the meantime though… arrow keys and enter ;). When they fix it, I probably will unintentionally keep using the keyboard for pulldown menus out of habit hehe.
Oh - ok I see. The more disturbing issue is for sure the crash problem as my KiCAD tends to reset itself to the “route around” option - no matter what I do.
As I had no Mac KiCAD earlier and am used to work with a Windows compiled one, I guess I need to get used to the pulldown bug because it does no seem to have big importance. After one year it still did not receive an importance ranking. ):
black-rainbows:Downloads morphogencc$ c++ --version
Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin12.5.0
Thread model: posix
By the way, Cairo does not provide a framework for OS X anymore, and the supported usage is by building .dylibs instead. In fact, the website recommends using a package manager (like mac ports, fink, or homebrew) to install cairo, as it will be built as a dylib and installed where programs can find it. I am not sure where it came from, but if you need to use it in framework form, I would recommend seeing if you can find (or build) the most recent version, and make sure to make it universal so it includes 64-bit code in the framework. The one you have is 32-bit only, but building under Yosemite requires linking to 64-bit AND 32-bit, or 64-bit only, anything 32-bit only cannot be used. That is what the missing symbols error was saying - that needed 64-bit code in Cairo weren’t there.
