Awesome Wayne!!, there it was [1]!!! :) :-D
Miguel Ángel Ajo
[1]
https://github.com/KiCad/kicad-source-mirror/commit/04c55f0956b6e69cfc925be77cd9dfaa01537d1a
On Thursday, 19 de February de 2015 at 02:49, Wayne Stambaugh wrote:
> I figured it out. The wxPython version was getting initializ
In a previous build a couple of weeks ago, I had a problem with
specifying the 'type' of the env var.
You might try leaving off the :BOOL and :STRING in your commands.
In theory, the 'type's should be there (for general code safety), but it
seemed to work better for me when they were gone.
Hope
I figured it out. The wxPython version was getting initialize after
config.h was getting written. Duh! This should be fixed in r5431. I'm
going to bed now :)
On 2/18/2015 7:26 PM, Miguel Ángel Ajo wrote:
> Just a note:
>
> I’m running cmake from an *empty* build dir:
>
> mkdir build
> cd bui
What was the problem with download_boost?, PPA builds didn’t allow network
connections?
Miguel Ángel Ajo
On Thursday, 19 de February de 2015 at 01:30, Adam Wolf wrote:
> Years ago, when I maintained an Ubuntu PPA pre - download_boost, I had to do
> cmake rebuild_cache on every build, but I di
Years ago, when I maintained an Ubuntu PPA pre - download_boost, I had to
do cmake rebuild_cache on every build, but I didn't have to on my PC.
Never tracked that down before download_boost made that methodology
impossible.
Adam Wolf
On Feb 18, 2015 6:27 PM, "Miguel Ángel Ajo" wrote:
> Just a no
Just a note:
I’m running cmake from an *empty* build dir:
mkdir build
cd build
cmake -D… -D… ..
and I get into the problem, which goes away with the make rebuild_cache.
Miguel Ángel Ajo
On Thursday, 19 de February de 2015 at 01:24, Miguel Ángel Ajo wrote:
> Exactly, if I runs make rebuild_
Exactly, if I runs make rebuild_cache, or if I simply rerun cmake twice (no
need to delete config.h) the #define WXPYTHON_VERSION turns from “” to “3.0”.
When is cmake supposed to generate config.h exactly?
Miguel Ángel Ajo
On Thursday, 19 de February de 2015 at 01:21, Wayne Stambaugh wrote
On 2/18/2015 7:08 PM, Miguel Ángel Ajo wrote:
> Hmm, if I re-run cmake or, as Wayne suggested, I run
> make rebuild_cache, WXPYTHON_VERSION turns into “3.0” inside config.h
>
> I will add that workaround to the kicad fedora builder, but…
> why does that happen?
Good question. You would think CM
They should match so that's the problem. I have the same problem when I
build from an existing build. It appears that config.h is not getting
rebuilt. Try running `make rebuild_cache` or deleting config.h and see
if CMake sets the WXPYTON_VERSION string to "3.0" which is what is found
during the
Hmm, if I re-run cmake or, as Wayne suggested, I run
make rebuild_cache, WXPYTHON_VERSION turns into “3.0” inside config.h
I will add that workaround to the kicad fedora builder, but…
why does that happen?
Miguel Ángel Ajo
On Thursday, 19 de February de 2015 at 00:41, Miguel Ángel Ajo wrote:
Hmm, it seems that in my system it’s getting an empty string ‘’,
where does WXPYTHON_VERSION come from?
/// The wxPython version found during configuration.
#if defined( KICAD_SCRIPTING_WXPYTHON )
#define WXPYTHON_VERSION""
#endif
Shouldn’t that match WXPYTHON_VERSION_FOUND from
KICAD_SCRIPTING_WXPYTHON:BOOL=ON
and
WXPYTHON_VERSION_FOUND:STRING=3.0
I wonder what’s wrong with my “wxversion” thing… the exact error is:
[ajo@kicad kicad-5430]$ pcbnew
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib64/python2.7/site-packages/wxversion.py", line 149,
Hi Wayne,
I don’t have direct access to the CmakeCache (due that I’m relying on copr for
my builds),
but I could try to replicate locally, btw, this is from the build logs:
-- Found wxWidgets:
-pthread;;;-lwx_gtk2u_gl-3.0;-lwx_gtk2u_aui-3.0;-lwx_gtk2u_adv-3.0;-lwx_gtk2u_html-3.0;-lwx_gtk2u_core
Miguel,
What is the output of:
grep WXPYTHON < kicad_build_path/CMakeCache.txt
You should see something like this:
KICAD_SCRIPTING_WXPYTHON:BOOL=ON
WXPYTHON_VERSION_FOUND:STRING=3.0
If WXPYTHON_VERSON_FOUND is empty, run `make rebuild_cache`.
Cheers,
Wayne
On 2/18/2015 10:44 AM, Miguel Ánge
It looks like something related to the python paths not
being able to find wx._core_.
I’ll put some time tonight on it.
Miguel Ángel Ajo
On Wednesday, 18 de February de 2015 at 16:33, Brian Sidebotham wrote:
> On 18 February 2015 at 14:26, Miguel Ángel Ajo (mailto:majop...@redhat.com)> wrot
On 18 February 2015 at 14:26, Miguel Ángel Ajo wrote:
>
>
>
> Hmm, this crashes in the fedora nightly build during pcbnew startup, I need
> to investigate why.
>
> https://github.com/KiCad/kicad-source-mirror/commit/69553d6fa31a60a4694395f0dcadfdbd787c21a8#diff-cdb8e872a96e63280c27292a5845cfbeR147
Hmm, this crashes in the fedora nightly build during pcbnew startup, I need to
investigate why.
https://github.com/KiCad/kicad-source-mirror/commit/69553d6fa31a60a4694395f0dcadfdbd787c21a8#diff-cdb8e872a96e63280c27292a5845cfbeR147
snprintf( cmd, 1023, "import wxversion; wxversion.select('%s')
On 16 February 2015 at 17:44, Wayne Stambaugh wrote:
> On 2/16/2015 11:44 AM, Brian Sidebotham wrote:
>> On 16 February 2015 at 15:42, Brian Sidebotham
>> wrote:
>>> On 16 February 2015 at 14:17, Wayne Stambaugh wrote:
Brian,
How are you telling the kicad configuration where wxPyt
On 2/16/2015 11:44 AM, Brian Sidebotham wrote:
> On 16 February 2015 at 15:42, Brian Sidebotham
> wrote:
>> On 16 February 2015 at 14:17, Wayne Stambaugh wrote:
>>> Brian,
>>>
>>> How are you telling the kicad configuration where wxPython build is
>>> located during you winbuilder configuration?
2015-02-16 17:44 GMT+01:00 Brian Sidebotham :
> On 16 February 2015 at 15:42, Brian Sidebotham
> wrote:
>> On 16 February 2015 at 14:17, Wayne Stambaugh wrote:
>>> Brian,
>>>
>>> How are you telling the kicad configuration where wxPython build is
>>> located during you winbuilder configuration?
On 16 February 2015 at 15:42, Brian Sidebotham
wrote:
> On 16 February 2015 at 14:17, Wayne Stambaugh wrote:
>> Brian,
>>
>> How are you telling the kicad configuration where wxPython build is
>> located during you winbuilder configuration? Would Garth's solution
>> below solve your problem? Th
Using PYTHON_SITE_PACKAGE_PATH is documented as being for this purpose, and it
works on OS X because the libraries end up in the application bundle and all
the paths are set up properly during the build and packaging.
From Documentation/compiling/build-config.txt:
…
PYTHON_SITE_PACKAGE_PATH (
On 16 February 2015 at 14:17, Wayne Stambaugh wrote:
> Brian,
>
> How are you telling the kicad configuration where wxPython build is
> located during you winbuilder configuration? Would Garth's solution
> below solve your problem? The only issue I see with Garth's solution is
> that if you inst
Brian,
How are you telling the kicad configuration where wxPython build is
located during you winbuilder configuration? Would Garth's solution
below solve your problem? The only issue I see with Garth's solution is
that if you install wxPython somewhere other than where you defined
PYTHON_SITE_P
This commit broke KiCad-Winbuilder because of the same reason as
Garth. wxPython is not "installed" in the compilation environment. It
gets installed by the build system. We will be installing wxPython
locally to the KiCad installation on Windows, there's no other way to
distribute it.
I haven't h
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 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 CMakeL
I’m pretty sure you do not understand what I’m saying.
> On Feb 15, 2015, at 4:41 PM, Wayne Stambaugh 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 and then point
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
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 versi
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 don
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 without
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 inst
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 th
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 w
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
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 neve
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 :
> I had the same problem and had to run `make rebuild_cache` to get CMake
> to properly configure the wxPython version string.
I just committed code to fix the following wxPython issues:
1) Verify if wxPython is installed on the system when
KICAD_SCRIPTING_WXPYTHON=ON and fail the build configuration when
wxPython is not found.
2) Verify the major and minor versions of the wxPython match the major
and minor versions of t
39 matches
Mail list logo
