Ok, that works now.
I see it was sent off list, that was not intended, hence I will
forward it for others to find. Thank you.
2015-02-15 15:39 GMT+01:00 Wayne Stambaugh stambau...@gmail.com:
I had the same problem and had to run `make rebuild_cache` to get CMake
to properly configure the
Miguel,
I got fedora 21 building Kicad at last without any hacking for the first
time following the ideas that John Beard suggested to me I have built
with wxWidgets-3.0.2.
Application: kicad
Version: (2015-02-11 BZR 5414)-product Release build
wxWidgets: Version 3.0.2
I'm confused. How else should this work? If configure your kicad build
to include wxPython, then one would expect the configuration to fail if
wxPython is not installed or the correct version. Irregardless of where
wxPython is installed on your system, python still needs to know where
it is
Well, yes, you’ve sort of explained the problem. Unless wxPython is on the
library path or using PYTHONPATH it isn’t going to work, and I don’t have
wxPython installed on my system for any other purpose. So, invoking the system
python as is done in the version check isn’t going to work
On 2/15/2015 3:25 PM, Mark Roszko wrote:
Just some notes
1. Coverity isn't perfect, there will be false positives and also some
interesting cases where it flags issues due toassumptions made in
code
Just like compiler warnings, make sure you understand the code before
you fix something.
On 2/15/2015 7:06 PM, Garth Corral wrote:
Well, yes, you’ve sort of explained the problem. Unless wxPython is on the
library path or using PYTHONPATH it isn’t going to work, and I don’t have
wxPython installed on my system for any other purpose. So, invoking the
system python as is done
I think perhaps we’re having a miscommunication. I don’t think it’s thin ice
at all to build a version of a dependency and then pointing my kicad build at
it. I think it’s more of an issue to assume that whatever is installed on your
system is the right thing. What if I needed different
I’m pretty sure you do not understand what I’m saying.
On Feb 15, 2015, at 4:41 PM, Wayne Stambaugh stambau...@gmail.com wrote:
On 2/15/2015 7:27 PM, Garth Corral wrote:
I think perhaps we’re having a miscommunication. I don’t think it’s
thin ice at all to build a version of a dependency
On 2/15/2015 7:27 PM, Garth Corral wrote:
I think perhaps we’re having a miscommunication. I don’t think it’s
thin ice at all to build a version of a dependency and then pointing my
kicad build at it. I think it’s more of an issue to assume that
whatever is installed on your system is the
On 2/15/2015 7:42 PM, Garth Corral wrote:
I’m pretty sure you do not understand what I’m saying.
Perhaps you are right. To better understand how you would use CMake to
ensure the the correct version of wxPython is somewhere on you system
and gets installed along with KiCad, please modify
Mark Roszko was kind enough to set up a Coverity scan for KiCad at
https://scan.coverity.com/projects/3606?tab=analysis_settings. Thank
you Mark. I would at least like my lead developers to sign up and have
Mark give you access to see the scan results. If you see a high
severity issue that is
Just some notes
1. Coverity isn't perfect, there will be false positives and also some
interesting cases where it flags issues due toassumptions made in
code
2. Some of the statistics it displays on the project page are funky
and don't seem to update properly so don't worry about them too much
Sorry, I though I replied to the mailing list.
I don't know why CMake doesn't correctly rebuild the cache when you edit
the CMake files. You would think that would be the default behavior.
I'm not sure if I'm doing something wrong is this is just how CMake
works. On a clean build, you would
Great stuff, I'm already finding genuine (though rarely tripped) problems.
On the embarrassing side, my code has a defect rate of about 2 per 1000
lines.
Bye-bye evenings - looks like I have some code to fix.
- Cirilo
On Mon, Feb 16, 2015 at 7:11 AM, Wayne Stambaugh stambau...@gmail.com
wrote:
Hmm… So, unless I’m missing something, the new wxPython version check isn’t
ever going to work for me. I don’t have wxPython installed as part of my
system install so importing wxversion is always going to fail unless I point it
to my wxPython that I build as part of my kicad builds. Anyone
If you don't have wxPython installed, how are you compiling with
KICAD_SCRIPTING_WXPYTHON=ON? The wxPython configuration check and the
python scripting version selection initialization only happen when you
configure your build with KICAD_SCRIPTING_WXPYTHON=ON.
On 2/15/2015 6:30 PM, Garth Corral
I build wxPython as part of my kicad build. So if you just invoke python and
do, import wxversion, it will fail with an import error because it can’t find
the module. I’d need to set the python path to point to my built wxPython.
When all is compiled and installed, everything works because
Gentlemen,
Once we have the cmake configuration code ready to go and all of the odt
file converted to asciidoc (they don't have to be completely cleaned
up), I would like to push the repo to
https://github.com/KiCad/kicad-docs. Since this is where the libraries
and the source mirror currently
Hi all,
There's been a bug reported [1] that when an OSX user tries to copy text
from a dialog with Cmd-C the dialog is closed. This appears to be due to a
bug in wxWidgets [2]. The bug report includes a list of some dialogs
affected and others that aren't. After a quick look at the code, it
There is a variable that is already in use in CMakeLists.txt,
PYTHON_SITE_PACKAGE_PATH, that can be used to point to an alternate library
path. I don’t know where this variable came from but I believe it was being
used by KicadOSXbuilder for this purpose at one point.
This (or something) just
On Fri, Feb 13, 2015 at 10:09:55PM +0100, Mathias Grimmberger wrote:
The radius of the rounded corners is fixed at 25% of the shorter pad
edge, but not larger than 0.25 mm. I'm not sure whether the radius needs
to be adjustable.
Yep, that's the IPC recommendation for round corner rectangular
21 matches
Mail list logo
