Re: [Kicad-developers] OSX build fails consistently with same error
On 22/mar/2014, at 07:00, Dick Hollenbeck d...@softplc.com wrote: Here where was a couple of issues. The pcb_plot_params_keywords i think is a multi platform issue that happens only on scratch new checkouts using an high parallelism (like make -j12) Doesn’t happens on not “fresh” rebuilds because we found the previous build .h. I’ve fixed some of those race, but seems that still happening somewhere, i’ll wait the end of deployment of Kiway to see it in a deeper way. The other one was due the CAIRO_FOUND in download_cairo.cmake, there is something missing in bypassing the check_package, i’ve workarounded it for now. — Marco On 03/21/2014 11:01 PM, Jean-Paul Louis wrote: The make in the common directory made a difference, but now I get a failure I never saw before. Looks like an issue with Cairo and GAL, but I have no clue as I never looked at that part of the code. Jean-Paul (AC9GH) The result below is the make after the previous “make in the common directory. I said $ make pcb_plot_params_keywords.o not: $ make ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] OSX build fails consistently with same error
I just completely removed the build directory I used. I will try a fresh build today with all the new info I got from all of you. I used MacPort to install whatever was needed for the build bzr bzrtools swig glew cairo etc.. My build platform is: Hardware is Macbook Pro w Retina Display 2.3GHz 4-core I7 - 16GB RAM - 500GB SSD Software is: OS X 10.9 Latest Maverick Xcode Version 5.1 (5B130a) Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn) Target: x86_64-apple-darwin13.1.0 Thread model: posix cmake version 2.8.12.2 GNU Make 3.81 ... This program built for i386-apple-darwin11.3.0 Bazaar (bzr) 2.6.0 Python interpreter: /opt/local/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python 2.7.6 Python standard library: /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7 Platform: Darwin-13.1.0-x86_64-i386-64bit bzrlib: /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/bzrlib Bazaar configuration: /Users/jean-paullouis/.bazaar Bazaar log file: /Users/jean-paullouis/.bzr.log Copyright 2005-2012 Canonical Ltd. http://bazaar.canonical.com/ SWIG Version 2.0.11 Compiled with /usr/bin/clang++ [x86_64-apple-darwin13.0.0] Configured options: +pcre Thanks, Jean-Paul (AC9GH) On Mar 22, 2014, at 10:33 AM, Marco Serantoni marco.serant...@gmail.com wrote: On 22/mar/2014, at 07:00, Dick Hollenbeck d...@softplc.com wrote: Here where was a couple of issues. The pcb_plot_params_keywords i think is a multi platform issue that happens only on scratch new checkouts using an high parallelism (like make -j12) Doesn’t happens on not “fresh” rebuilds because we found the previous build .h. I’ve fixed some of those race, but seems that still happening somewhere, i’ll wait the end of deployment of Kiway to see it in a deeper way. The other one was due the CAIRO_FOUND in download_cairo.cmake, there is something missing in bypassing the check_package, i’ve workarounded it for now. — Marco On 03/21/2014 11:01 PM, Jean-Paul Louis wrote: The make in the common directory made a difference, but now I get a failure I never saw before. Looks like an issue with Cairo and GAL, but I have no clue as I never looked at that part of the code. Jean-Paul (AC9GH) The result below is the make after the previous “make in the common directory. I said $ make pcb_plot_params_keywords.o not: $ make ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp signature.asc Description: Message signed with OpenPGP using GPGMail ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] KiCad git-based libraries as a way to harvest users' contributions - does it work?
On 21 March 2014 18:41, Fabrizio Tappero fabrizio.tapp...@gmail.com wrote: An other issue is that the current github setup require the hypothetical contributor to have a github account. No, you can just make a patch and send it to this mailing list. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] KiCad git-based libraries as a way to harvest users' contributions - does it work?
Does it work? When Git library repository - I mean symbols, this is my only point of interest - was started few months ago there is one master branch, and four (If I'm wrong, sb corect me) registered contributors. Now we have eight and few people who have their own forks based on master branch. Using Git search engine and searching for kicad, system said: We've found 312 repository results. Even if we filter out current pretty repos we still have got about two hundred. I have look into a couple of it and there is something interesting in it which may enlarge the current libraries resource. Can we acquire these people? Or unique symbols/footprints which they done? I think yes. So, the answer for: Does it work? is It works. Partially it works. But there is one thing that must be done as soon as possible, before users throw on the creation of libraries. Clear and understandable by everyone library creating policy. Actually we don't have it, and symbols have different styles: various pin length (Is there any reason to keep 0.3 as default value?), various text size, sometimes disproportionation symbol body size. Awful (IMHO). From a drawing point of view, footprints looks better because there is no room to any extravagance. The only unclear thing is footprint naming convention. SOT-23 or SOT23, SO8 or SO-8 or SOIC8 or SOIC-8-N. Opinions are divided, and the discussion on library-committers list was stuck in place. ps. Sorry people, but I have to put my 5 cents in this discussion. Kerusey Karyu ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
