Re: [Kicad-developers] wxPython version check

[Miguel Ángel Ajo]

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 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 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_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:
> > >  
> > > > 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 configuration.
> > > >  
> > > > On 2/18/2015 6:41 PM, 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 CMakeCache.txt ?
> > > > >  
> > > > >  
> > > > > Miguel Ángel Ajo
> > > > >  
> > > > > On Thursday, 19 de February de 2015 at 00:35, Miguel Ángel Ajo wrote:
> > > > >  
> > > > > > 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, in
> > > > > > select
> > > > > > bestMatch = _get_best_match(installed, versions, optionsRequired)
> > > > > > File "/usr/lib64/python2.7/site-packages/wxversion.py", line 273, in
> > > > > > _get_best_match
> > > > > > score = pkg.Score(_wxPackageInfo(ver), optionsRequired)
> > > > > > File "/usr/lib64/python2.7/site-packages/wxversion.py", line 357, in
> > > > > > __init__
> > > > > > self.version = tuple([int(x) for x in segments[0].split('.')])
> > > > > > ValueError: invalid literal for int() with base 10: ''
> > > > > > ImportError: No module named wx._core_
> > > > > >  
> > > > > >  
> > > > > > If I do this in console, it seems to work
> > > > > > > > > import wxversion
> > > > > > > > > wxversion.select('3.0')
> > > > > > > > >  
> > > > > > > >  
> > > > > > >  
> > > > > >  
> > > > > > I will try to check what’s really getting through WXPYTHON_VERSION,
> > > > > > or why is it failing
> > > > > > in my system when inside pcbnew.
> > > > > >  
> > > > > > Miguel Ángel Ajo
> > > > > >  
> > > > > > On Wednesday, 18 de February de 2015 at 23:38, Miguel Ángel Ajo 
> > > > > > wrote:
> > > > > >  
> > > > > > > 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-3.0;-lwx_baseu_net-3.0;-lwx_baseu-3.0;-lwx_baseu_xml-3.0;-lwx_gtk2u_stc-3.0
> > > > > > > (found suitable version "3.0.2", minimum required is "3.0.0")
> > > > > > >  
> > > > > > >  
> > > > > > > and I set KICAD_SCRIPTING_WXPYTHON on cmake:
> > > > > > >  
> > > > > > > https://copr-be.cloud.fedoraproject.org/results/mangelajo/kicad/fedora-21-x86_64/kicad-5429-nightlies.fc22/build.log.gz
> > > > > > >  
> > > > > > > I’m going to debug a bit to see what’s happening, and read the 
> > > > > > > thread
> > > > > > > about the wxPython changes that
> > > > > > > I didn’t have time to read in full.
> > > > > > >  
> > > > > > > Best reagards,
> > > > > > > Miguel Ángel.
> > > > > > >  
> > > > > > > Miguel Ángel Ajo
> > > > > > >  
> > > > > > > On Wednesday, 18 de February de 2015 at 18:05, Wayne Stambaugh 
> > > > > > > wrote:
> > > > > > >  
> > > > > > > > Miguel,
> > > > > > > >  

Re: [Kicad-developers] wxPython version check

[Bob Gustafson]

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 this helps.

Bob G

On 02/18/2015 05:35 PM, Miguel Ángel Ajo wrote:

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, in
select
bestMatch = _get_best_match(installed, versions, optionsRequired)
  File "/usr/lib64/python2.7/site-packages/wxversion.py", line 273, in
_get_best_match
score = pkg.Score(_wxPackageInfo(ver), optionsRequired)
  File "/usr/lib64/python2.7/site-packages/wxversion.py", line 357, in
__init__
self.version = tuple([int(x) for x in segments[0].split('.')])
ValueError: invalid literal for int() with base 10: ''
ImportError: No module named wx._core_


If I do this in console, it seems to work
>>> import wxversion
>>> wxversion.select('3.0')
>>>
 I will try to check what’s really getting through WXPYTHON_VERSION,
or why is it failing
in my system when inside pcbnew.

Miguel Ángel Ajo

On Wednesday, 18 de February de 2015 at 23:38, Miguel Ángel Ajo wrote:


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-3.0;-lwx_baseu_net-3.0;-lwx_baseu-3.0;-lwx_baseu_xml-3.0;-lwx_gtk2u_stc-3.0
(found suitable version "3.0.2", minimum required is "3.0.0")


and I set KICAD_SCRIPTING_WXPYTHON on cmake:

https://copr-be.cloud.fedoraproject.org/results/mangelajo/kicad/fedora-21-x86_64/kicad-5429-nightlies.fc22/build.log.gz

I’m going to debug a bit to see what’s happening, and read the thread
about the wxPython changes that
I didn’t have time to read in full.

Best reagards,
Miguel Ángel.

Miguel Ángel Ajo

On Wednesday, 18 de February de 2015 at 18:05, Wayne Stambaugh wrote:


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 Ángel Ajo wrote:

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>
> 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

snprintf( cmd, 1023, "import wxversion; wxversion.select('%s')",
WXPYTHON_VERSION );
PyRun_SimpleString( cmd );


Probably a missing

PyLock lock;

Also, we don't need to use snprintf here, we can simply use:

const char* cmd = "import wxversion; wxversion.select('"
WXPYTHON_VERSION "')";

instead.

Sorry I don't have time to investigate the crash right now. Good Luck.

Best Regards,

Brian.

___
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




___
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


___
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






___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-develop

Re: [Kicad-developers] wxPython version check

[Wayne Stambaugh]

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 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_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:
>>
>>> 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 configuration.
>>>
>>> On 2/18/2015 6:41 PM, 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 CMakeCache.txt ?


 Miguel Ángel Ajo

 On Thursday, 19 de February de 2015 at 00:35, Miguel Ángel Ajo wrote:

> 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, in
> select
> bestMatch = _get_best_match(installed, versions, optionsRequired)
> File "/usr/lib64/python2.7/site-packages/wxversion.py", line 273, in
> _get_best_match
> score = pkg.Score(_wxPackageInfo(ver), optionsRequired)
> File "/usr/lib64/python2.7/site-packages/wxversion.py", line 357, in
> __init__
> self.version = tuple([int(x) for x in segments[0].split('.')])
> ValueError: invalid literal for int() with base 10: ''
> ImportError: No module named wx._core_
>
>
> If I do this in console, it seems to work
 import wxversion
 wxversion.select('3.0')
> I will try to check what’s really getting through WXPYTHON_VERSION,
> or why is it failing
> in my system when inside pcbnew.
>
> Miguel Ángel Ajo
>
> On Wednesday, 18 de February de 2015 at 23:38, Miguel Ángel Ajo wrote:
>
>> 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-3.0;-lwx_baseu_net-3.0;-lwx_baseu-3.0;-lwx_baseu_xml-3.0;-lwx_gtk2u_stc-3.0
>> (found suitable version "3.0.2", minimum required is "3.0.0")
>>
>>
>> and I set KICAD_SCRIPTING_WXPYTHON on cmake:
>>
>> https://copr-be.cloud.fedoraproject.org/results/mangelajo/kicad/fedora-21-x86_64/kicad-5429-nightlies.fc22/build.log.gz
>>
>> I’m going to debug a bit to see what’s happening, and read the thread
>> about the wxPython changes that
>> I didn’t have time to read in full.
>>
>> Best reagards,
>> Miguel Ángel.
>>
>> Miguel Ángel Ajo
>>
>> On Wednesday, 18 de February de 2015 at 18:05, Wayne Stambaugh wrote:
>>
>>> 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 Ángel Ajo wrote:
 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>
> 
> > wrote:
>>
>>
>>
>> Hmm, this crashes in the fedora nightly build during pcbnew
>>>

Re: [Kicad-developers] wxPython version check

[Miguel Ángel Ajo]

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 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"  (mailto:majop...@redhat.com)> wrote:
> > 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_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:
> > >  
> > > > 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 configuration.
> > > >  
> > > > On 2/18/2015 6:41 PM, 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 CMakeCache.txt ?  
> > > > >  
> > > > >  
> > > > > Miguel Ángel Ajo
> > > > >  
> > > > > On Thursday, 19 de February de 2015 at 00:35, Miguel Ángel Ajo wrote:
> > > > >  
> > > > > > 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, in
> > > > > > select
> > > > > > bestMatch = _get_best_match(installed, versions, optionsRequired)
> > > > > > File "/usr/lib64/python2.7/site-packages/wxversion.py", line 273, in
> > > > > > _get_best_match
> > > > > > score = pkg.Score(_wxPackageInfo(ver), optionsRequired)
> > > > > > File "/usr/lib64/python2.7/site-packages/wxversion.py", line 357, in
> > > > > > __init__
> > > > > > self.version = tuple([int(x) for x in segments[0].split('.')])
> > > > > > ValueError: invalid literal for int() with base 10: ''
> > > > > > ImportError: No module named wx._core_
> > > > > >  
> > > > > >  
> > > > > > If I do this in console, it seems to work
> > > > > > > > > import wxversion
> > > > > > > > > wxversion.select('3.0')
> > > > > > > > >  
> > > > > > > >  
> > > > > > >  
> > > > > >  
> > > > > > I will try to check what’s really getting through WXPYTHON_VERSION,
> > > > > > or why is it failing
> > > > > > in my system when inside pcbnew.
> > > > > >  
> > > > > > Miguel Ángel Ajo
> > > > > >  
> > > > > > On Wednesday, 18 de February de 2015 at 23:38, Miguel Ángel Ajo 
> > > > > > wrote:
> > > > > >  
> > > > > > > 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-3.0;-lwx_baseu_net-3.0;-lwx_baseu-3.0;-lwx_baseu_xml-3.0;-lwx_gtk2u_stc-3.0
> > > > > > > (found suitable version "3.0.2", minimum required is "3.0.0")
> > > > > > >  
> > > > > > >  
> > > > > > > and I set KICAD_SCRIPTING_WXPYTHON on cmake:
> > > > > > >  
> > > > > > > https://copr-be.cloud.fedoraproject.org/results/mangelajo/kicad/fedora-21-x86_64/kicad-5429-nightlies.fc22/build.log.gz
> > > > > > >  
> > > > > > > I’m going to debug a bit to see what’s happening, and read the 
> > > > > > > thread
> > > > > > > about the wxPython changes that
> > > > > > > I didn’t have time to read in full.
> > > > > > >  
> > > > > > > Best reagards,
> > > > > > > Miguel Ángel.
> > > > > > >  
> > > > > > > Miguel Ángel Ajo
> > > > > > >  
> > > > > > > On Wednesday, 18 de February de 2015 at 18:05, Wayne Stambaugh 
> > > 

Re: [Kicad-developers] wxPython version check

[Adam Wolf]

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 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_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:
>
> 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 configuration.
>
> On 2/18/2015 6:41 PM, 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 CMakeCache.txt ?
>
>
> Miguel Ángel Ajo
>
> On Thursday, 19 de February de 2015 at 00:35, Miguel Ángel Ajo wrote:
>
> 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, in
> select
> bestMatch = _get_best_match(installed, versions, optionsRequired)
> File "/usr/lib64/python2.7/site-packages/wxversion.py", line 273, in
> _get_best_match
> score = pkg.Score(_wxPackageInfo(ver), optionsRequired)
> File "/usr/lib64/python2.7/site-packages/wxversion.py", line 357, in
> __init__
> self.version = tuple([int(x) for x in segments[0].split('.')])
> ValueError: invalid literal for int() with base 10: ''
> ImportError: No module named wx._core_
>
>
> If I do this in console, it seems to work
>
> import wxversion
> wxversion.select('3.0')
>
> I will try to check what’s really getting through WXPYTHON_VERSION,
> or why is it failing
> in my system when inside pcbnew.
>
> Miguel Ángel Ajo
>
> On Wednesday, 18 de February de 2015 at 23:38, Miguel Ángel Ajo wrote:
>
> 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-3.0;-lwx_baseu_net-3.0;-lwx_baseu-3.0;-lwx_baseu_xml-3.0;-lwx_gtk2u_stc-3.0
> (found suitable version "3.0.2", minimum required is "3.0.0")
>
>
> and I set KICAD_SCRIPTING_WXPYTHON on cmake:
>
>
> https://copr-be.cloud.fedoraproject.org/results/mangelajo/kicad/fedora-21-x86_64/kicad-5429-nightlies.fc22/build.log.gz
>
> I’m going to debug a bit to see what’s happening, and read the thread
> about the wxPython changes that
> I didn’t have time to read in full.
>
> Best reagards,
> Miguel Ángel.
>
> Miguel Ángel Ajo
>
> On Wednesday, 18 de February de 2015 at 18:05, Wayne Stambaugh wrote:
>
> 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 Ángel Ajo wrote:
>
> 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 >
> > 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
>
> snprintf( cmd, 1023, "import wxversion; wxversion.select('%s')",
> WXPYTHON_VERSION );
> PyRun_SimpleString( cmd );
>
>
> Probably a missing
>
> PyLock lock;
>
> Also, we don't need to use snprintf here, we can simply use:
>
> const char* cmd = "import wxversion; wxversion.select('"
> WXPYTHON_VERSION "')";
>
> instead.
>
> Sorry I don't have time to investi

Re: [Kicad-developers] wxPython version check

[Miguel Ángel Ajo]

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_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:
>  
> > 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 configuration.
> >  
> > On 2/18/2015 6:41 PM, 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 CMakeCache.txt ?  
> > >  
> > >  
> > > Miguel Ángel Ajo
> > >  
> > > On Thursday, 19 de February de 2015 at 00:35, Miguel Ángel Ajo wrote:
> > >  
> > > > 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, in
> > > > select
> > > > bestMatch = _get_best_match(installed, versions, optionsRequired)
> > > > File "/usr/lib64/python2.7/site-packages/wxversion.py", line 273, in
> > > > _get_best_match
> > > > score = pkg.Score(_wxPackageInfo(ver), optionsRequired)
> > > > File "/usr/lib64/python2.7/site-packages/wxversion.py", line 357, in
> > > > __init__
> > > > self.version = tuple([int(x) for x in segments[0].split('.')])
> > > > ValueError: invalid literal for int() with base 10: ''
> > > > ImportError: No module named wx._core_
> > > >  
> > > >  
> > > > If I do this in console, it seems to work
> > > > > > > import wxversion
> > > > > > > wxversion.select('3.0')
> > > > > > >  
> > > > > >  
> > > > >  
> > > >  
> > > > I will try to check what’s really getting through WXPYTHON_VERSION,
> > > > or why is it failing
> > > > in my system when inside pcbnew.
> > > >  
> > > > Miguel Ángel Ajo
> > > >  
> > > > On Wednesday, 18 de February de 2015 at 23:38, Miguel Ángel Ajo wrote:
> > > >  
> > > > > 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-3.0;-lwx_baseu_net-3.0;-lwx_baseu-3.0;-lwx_baseu_xml-3.0;-lwx_gtk2u_stc-3.0
> > > > > (found suitable version "3.0.2", minimum required is "3.0.0")
> > > > >  
> > > > >  
> > > > > and I set KICAD_SCRIPTING_WXPYTHON on cmake:
> > > > >  
> > > > > https://copr-be.cloud.fedoraproject.org/results/mangelajo/kicad/fedora-21-x86_64/kicad-5429-nightlies.fc22/build.log.gz
> > > > >  
> > > > > I’m going to debug a bit to see what’s happening, and read the thread
> > > > > about the wxPython changes that
> > > > > I didn’t have time to read in full.
> > > > >  
> > > > > Best reagards,
> > > > > Miguel Ángel.
> > > > >  
> > > > > Miguel Ángel Ajo
> > > > >  
> > > > > On Wednesday, 18 de February de 2015 at 18:05, Wayne Stambaugh wrote:
> > > > >  
> > > > > > 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 Ángel Ajo wrote:
> > > > > > > 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

Re: [Kicad-developers] wxPython version check

[Miguel Ángel Ajo]

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:

> 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 configuration.
>  
> On 2/18/2015 6:41 PM, 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 CMakeCache.txt ?  
> >  
> >  
> > Miguel Ángel Ajo
> >  
> > On Thursday, 19 de February de 2015 at 00:35, Miguel Ángel Ajo wrote:
> >  
> > > 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, in
> > > select
> > > bestMatch = _get_best_match(installed, versions, optionsRequired)
> > > File "/usr/lib64/python2.7/site-packages/wxversion.py", line 273, in
> > > _get_best_match
> > > score = pkg.Score(_wxPackageInfo(ver), optionsRequired)
> > > File "/usr/lib64/python2.7/site-packages/wxversion.py", line 357, in
> > > __init__
> > > self.version = tuple([int(x) for x in segments[0].split('.')])
> > > ValueError: invalid literal for int() with base 10: ''
> > > ImportError: No module named wx._core_
> > >  
> > >  
> > > If I do this in console, it seems to work
> > > > > > import wxversion
> > > > > > wxversion.select('3.0')
> > > > > >  
> > > > >  
> > > >  
> > >  
> > > I will try to check what’s really getting through WXPYTHON_VERSION,
> > > or why is it failing
> > > in my system when inside pcbnew.
> > >  
> > > Miguel Ángel Ajo
> > >  
> > > On Wednesday, 18 de February de 2015 at 23:38, Miguel Ángel Ajo wrote:
> > >  
> > > > 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-3.0;-lwx_baseu_net-3.0;-lwx_baseu-3.0;-lwx_baseu_xml-3.0;-lwx_gtk2u_stc-3.0
> > > > (found suitable version "3.0.2", minimum required is "3.0.0")
> > > >  
> > > >  
> > > > and I set KICAD_SCRIPTING_WXPYTHON on cmake:
> > > >  
> > > > https://copr-be.cloud.fedoraproject.org/results/mangelajo/kicad/fedora-21-x86_64/kicad-5429-nightlies.fc22/build.log.gz
> > > >  
> > > > I’m going to debug a bit to see what’s happening, and read the thread
> > > > about the wxPython changes that
> > > > I didn’t have time to read in full.
> > > >  
> > > > Best reagards,
> > > > Miguel Ángel.
> > > >  
> > > > Miguel Ángel Ajo
> > > >  
> > > > On Wednesday, 18 de February de 2015 at 18:05, Wayne Stambaugh wrote:
> > > >  
> > > > > 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 Ángel Ajo wrote:
> > > > > > 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>
> > > > > > > > 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
> > > > > > > >  
> > > > > > > > snprintf( cmd, 1023, "import wxversion; wxversion.select('%s')

Re: [Kicad-developers] wxPython version check

[Wayne Stambaugh]

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 CMake would rebuild the cache when any
of the CMake files were modified but it doesn't.  I've had issues with
this in the past.

> 
> 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 CMakeCache.txt ? 
>>
>>
>> Miguel Ángel Ajo
>>
>> On Thursday, 19 de February de 2015 at 00:35, Miguel Ángel Ajo wrote:
>>
>>> 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,
>>> in select
>>> bestMatch = _get_best_match(installed, versions, optionsRequired)
>>>   File "/usr/lib64/python2.7/site-packages/wxversion.py", line 273,
>>> in _get_best_match
>>> score = pkg.Score(_wxPackageInfo(ver), optionsRequired)
>>>   File "/usr/lib64/python2.7/site-packages/wxversion.py", line 357,
>>> in __init__
>>> self.version = tuple([int(x) for x in segments[0].split('.')])
>>> ValueError: invalid literal for int() with base 10: ''
>>> ImportError: No module named wx._core_
>>>
>>>
>>> If I do this in console, it seems to work
>>> >>> import wxversion
>>> >>> wxversion.select('3.0')
>>> >>>
>>>  I will try to check what’s really getting through WXPYTHON_VERSION,
>>> or why is it failing
>>> in my system when inside pcbnew.
>>>
>>> Miguel Ángel Ajo
>>>
>>> On Wednesday, 18 de February de 2015 at 23:38, Miguel Ángel Ajo wrote:
>>>
 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-3.0;-lwx_baseu_net-3.0;-lwx_baseu-3.0;-lwx_baseu_xml-3.0;-lwx_gtk2u_stc-3.0
 (found suitable version "3.0.2", minimum required is "3.0.0")


 and I set KICAD_SCRIPTING_WXPYTHON on cmake:

 https://copr-be.cloud.fedoraproject.org/results/mangelajo/kicad/fedora-21-x86_64/kicad-5429-nightlies.fc22/build.log.gz

 I’m going to debug a bit to see what’s happening, and read the
 thread about the wxPython changes that
 I didn’t have time to read in full.

 Best reagards,
 Miguel Ángel.

 Miguel Ángel Ajo

 On Wednesday, 18 de February de 2015 at 18:05, Wayne Stambaugh wrote:

> 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 Ángel Ajo wrote:
>> 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>
>>> > 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

 snprintf( cmd, 1023, "import wxversion; wxversion.select('%s')",
 WXPYTHON_VERSION );
 PyRun_SimpleString( cmd );
>>>
>>> Probably a missing
>>>
>>> PyLock lock;
>>>
>>> Also, we don't need to use snprintf here, we can simply use:
>>>
>>> const char* cmd = "import wxversion; wxversion.select('"
>>> WXPYTHON_VERSION "')";
>>>
>>> instead.
>>>
>>> Sorry I don't have time to investigate the crash right now. Good
>>> Luck.
>>>
>>> Best Regards,
>>>
>>> Brian.
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : ki

Re: [Kicad-developers] wxPython version check

[Wayne Stambaugh]

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 configuration.

On 2/18/2015 6:41 PM, 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 CMakeCache.txt ? 
> 
> 
> Miguel Ángel Ajo
> 
> On Thursday, 19 de February de 2015 at 00:35, Miguel Ángel Ajo wrote:
> 
>> 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, in
>> select
>> bestMatch = _get_best_match(installed, versions, optionsRequired)
>>   File "/usr/lib64/python2.7/site-packages/wxversion.py", line 273, in
>> _get_best_match
>> score = pkg.Score(_wxPackageInfo(ver), optionsRequired)
>>   File "/usr/lib64/python2.7/site-packages/wxversion.py", line 357, in
>> __init__
>> self.version = tuple([int(x) for x in segments[0].split('.')])
>> ValueError: invalid literal for int() with base 10: ''
>> ImportError: No module named wx._core_
>>
>>
>> If I do this in console, it seems to work
>> >>> import wxversion
>> >>> wxversion.select('3.0')
>> >>>
>>  I will try to check what’s really getting through WXPYTHON_VERSION,
>> or why is it failing
>> in my system when inside pcbnew.
>>
>> Miguel Ángel Ajo
>>
>> On Wednesday, 18 de February de 2015 at 23:38, Miguel Ángel Ajo wrote:
>>
>>> 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-3.0;-lwx_baseu_net-3.0;-lwx_baseu-3.0;-lwx_baseu_xml-3.0;-lwx_gtk2u_stc-3.0
>>> (found suitable version "3.0.2", minimum required is "3.0.0")
>>>
>>>
>>> and I set KICAD_SCRIPTING_WXPYTHON on cmake:
>>>
>>> https://copr-be.cloud.fedoraproject.org/results/mangelajo/kicad/fedora-21-x86_64/kicad-5429-nightlies.fc22/build.log.gz
>>>
>>> I’m going to debug a bit to see what’s happening, and read the thread
>>> about the wxPython changes that
>>> I didn’t have time to read in full.
>>>
>>> Best reagards,
>>> Miguel Ángel.
>>>
>>> Miguel Ángel Ajo
>>>
>>> On Wednesday, 18 de February de 2015 at 18:05, Wayne Stambaugh wrote:
>>>
 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 Ángel Ajo wrote:
> 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>
>> > 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
>>>
>>> snprintf( cmd, 1023, "import wxversion; wxversion.select('%s')",
>>> WXPYTHON_VERSION );
>>> PyRun_SimpleString( cmd );
>>
>> Probably a missing
>>
>> PyLock lock;
>>
>> Also, we don't need to use snprintf here, we can simply use:
>>
>> const char* cmd = "import wxversion; wxversion.select('"
>> WXPYTHON_VERSION "')";
>>
>> instead.
>>
>> Sorry I don't have time to investigate the crash right now. Good Luck.
>>
>> Best Regards,
>>
>> Brian.
>>
>> ___
>> 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] wxPython version check

[Miguel Ángel Ajo]

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 CMakeCache.txt ?  
>  
>  
> Miguel Ángel Ajo
>  
>  
> On Thursday, 19 de February de 2015 at 00:35, Miguel Ángel Ajo wrote:
>  
> > 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, in 
> > select
> > bestMatch = _get_best_match(installed, versions, optionsRequired)
> >   File "/usr/lib64/python2.7/site-packages/wxversion.py", line 273, in 
> > _get_best_match
> > score = pkg.Score(_wxPackageInfo(ver), optionsRequired)
> >   File "/usr/lib64/python2.7/site-packages/wxversion.py", line 357, in 
> > __init__
> > self.version = tuple([int(x) for x in segments[0].split('.')])
> > ValueError: invalid literal for int() with base 10: ''
> > ImportError: No module named wx._core_
> >  
> >  
> >  
> > If I do this in console, it seems to work
> > >>> import wxversion
> > >>> wxversion.select('3.0')
> > >>>
> >  
> >  I will try to check what’s really getting through WXPYTHON_VERSION, or why 
> > is it failing
> >  
> > in my system when inside pcbnew.
> >  
> >  
> > Miguel Ángel Ajo
> >  
> >  
> > On Wednesday, 18 de February de 2015 at 23:38, Miguel Ángel Ajo wrote:
> >  
> > > 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-3.0;-lwx_baseu_net-3.0;-lwx_baseu-3.0;-lwx_baseu_xml-3.0;-lwx_gtk2u_stc-3.0
> > >  (found suitable version "3.0.2", minimum required is "3.0.0")
> > >  
> > > and I set KICAD_SCRIPTING_WXPYTHON on cmake:
> > >  
> > > https://copr-be.cloud.fedoraproject.org/results/mangelajo/kicad/fedora-21-x86_64/kicad-5429-nightlies.fc22/build.log.gz
> > >  
> > > I’m going to debug a bit to see what’s happening, and read the thread 
> > > about the wxPython changes that
> > > I didn’t have time to read in full.
> > >  
> > > Best reagards,
> > > Miguel Ángel.
> > >  
> > >  
> > > Miguel Ángel Ajo
> > >  
> > >  
> > > On Wednesday, 18 de February de 2015 at 18:05, Wayne Stambaugh wrote:
> > >  
> > > > 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 Ángel Ajo wrote:
> > > > > 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)
> > > > > > > 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
> > > > > > >  
> > > > > > > snprintf( cmd, 1023, "import wxversion; wxversion.select('%s')",
> > > > > > > WXPYTHON_VERSION );
> > > > > > > PyRun_SimpleString( cmd );
> > > > > > >  
> > > > > >  
> > > > > >  
> > > > > > Probably a missing
> > > > > >  
> > > > > > PyLock lock;
> > > > > >  
> > > > > > Also, we don't need to use snprintf here, we can simply use:
> > > > > >  
> > > > > > const char* cmd = "import wxversion; wxversion.select('"
> > > > > > WXPYTHON_VERSION "')";
> > > > > >  
> > > > > > instead.
> > > > > >  
> > > > > > Sorry I don't have time to investigate the crash right now. Good 
> > > > > > Luck.
> > > > > >  
> > > > > > Be

Re: [Kicad-developers] wxPython version check

[Miguel Ángel Ajo]

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 CMakeCache.txt ?  


Miguel Ángel Ajo


On Thursday, 19 de February de 2015 at 00:35, Miguel Ángel Ajo wrote:

> 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, in select
> bestMatch = _get_best_match(installed, versions, optionsRequired)
>   File "/usr/lib64/python2.7/site-packages/wxversion.py", line 273, in 
> _get_best_match
> score = pkg.Score(_wxPackageInfo(ver), optionsRequired)
>   File "/usr/lib64/python2.7/site-packages/wxversion.py", line 357, in 
> __init__
> self.version = tuple([int(x) for x in segments[0].split('.')])
> ValueError: invalid literal for int() with base 10: ''
> ImportError: No module named wx._core_
>  
>  
>  
> If I do this in console, it seems to work
> >>> import wxversion
> >>> wxversion.select('3.0')
> >>>
>  
>  I will try to check what’s really getting through WXPYTHON_VERSION, or why 
> is it failing
>  
> in my system when inside pcbnew.
>  
>  
> Miguel Ángel Ajo
>  
>  
> On Wednesday, 18 de February de 2015 at 23:38, Miguel Ángel Ajo wrote:
>  
> > 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-3.0;-lwx_baseu_net-3.0;-lwx_baseu-3.0;-lwx_baseu_xml-3.0;-lwx_gtk2u_stc-3.0
> >  (found suitable version "3.0.2", minimum required is "3.0.0")
> >  
> > and I set KICAD_SCRIPTING_WXPYTHON on cmake:
> >  
> > https://copr-be.cloud.fedoraproject.org/results/mangelajo/kicad/fedora-21-x86_64/kicad-5429-nightlies.fc22/build.log.gz
> >  
> > I’m going to debug a bit to see what’s happening, and read the thread about 
> > the wxPython changes that
> > I didn’t have time to read in full.
> >  
> > Best reagards,
> > Miguel Ángel.
> >  
> >  
> > Miguel Ángel Ajo
> >  
> >  
> > On Wednesday, 18 de February de 2015 at 18:05, Wayne Stambaugh wrote:
> >  
> > > 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 Ángel Ajo wrote:
> > > > 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)
> > > > > > 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
> > > > > >  
> > > > > > snprintf( cmd, 1023, "import wxversion; wxversion.select('%s')",
> > > > > > WXPYTHON_VERSION );
> > > > > > PyRun_SimpleString( cmd );
> > > > > >  
> > > > >  
> > > > >  
> > > > > Probably a missing
> > > > >  
> > > > > PyLock lock;
> > > > >  
> > > > > Also, we don't need to use snprintf here, we can simply use:
> > > > >  
> > > > > const char* cmd = "import wxversion; wxversion.select('"
> > > > > WXPYTHON_VERSION "')";
> > > > >  
> > > > > instead.
> > > > >  
> > > > > Sorry I don't have time to investigate the crash right now. Good Luck.
> > > > >  
> > > > > Best Regards,
> > > > >  
> > > > > Brian.
> > > > >  
> > > > > ___
> > > > > Mailing list: https://launchpad.net/~kicad-developers
> > > > > Post to : kicad-developers@lists.launchpad.net 
> > > > > (mailto:kicad-developers@lists.launchpad.net)
> > > > > 
> > > > > Unsubscribe : https://launchpad.net/~kicad-developers
> > > > > More help : https://help.launchpad.net/ListHelp
> > > > >  
> > > >  
> > > >  
> > > >  
> > > >  
> > > > ___
> > > > Mailing list: https://launchpad.net/~kicad-d

Re: [Kicad-developers] wxPython version check

[Miguel Ángel Ajo]

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, in select
bestMatch = _get_best_match(installed, versions, optionsRequired)
  File "/usr/lib64/python2.7/site-packages/wxversion.py", line 273, in 
_get_best_match
score = pkg.Score(_wxPackageInfo(ver), optionsRequired)
  File "/usr/lib64/python2.7/site-packages/wxversion.py", line 357, in __init__
self.version = tuple([int(x) for x in segments[0].split('.')])
ValueError: invalid literal for int() with base 10: ''
ImportError: No module named wx._core_



If I do this in console, it seems to work
>>> import wxversion
>>> wxversion.select('3.0')
>>>

 I will try to check what’s really getting through WXPYTHON_VERSION, or why is 
it failing

in my system when inside pcbnew.


Miguel Ángel Ajo


On Wednesday, 18 de February de 2015 at 23:38, Miguel Ángel Ajo wrote:

> 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-3.0;-lwx_baseu_net-3.0;-lwx_baseu-3.0;-lwx_baseu_xml-3.0;-lwx_gtk2u_stc-3.0
>  (found suitable version "3.0.2", minimum required is "3.0.0")
>  
> and I set KICAD_SCRIPTING_WXPYTHON on cmake:
>  
> https://copr-be.cloud.fedoraproject.org/results/mangelajo/kicad/fedora-21-x86_64/kicad-5429-nightlies.fc22/build.log.gz
>  
> I’m going to debug a bit to see what’s happening, and read the thread about 
> the wxPython changes that
> I didn’t have time to read in full.
>  
> Best reagards,
> Miguel Ángel.
>  
>  
> Miguel Ángel Ajo
>  
>  
> On Wednesday, 18 de February de 2015 at 18:05, Wayne Stambaugh wrote:
>  
> > 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 Ángel Ajo wrote:
> > > 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)
> > > > > 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
> > > > >  
> > > > > snprintf( cmd, 1023, "import wxversion; wxversion.select('%s')",
> > > > > WXPYTHON_VERSION );
> > > > > PyRun_SimpleString( cmd );
> > > > >  
> > > >  
> > > >  
> > > > Probably a missing
> > > >  
> > > > PyLock lock;
> > > >  
> > > > Also, we don't need to use snprintf here, we can simply use:
> > > >  
> > > > const char* cmd = "import wxversion; wxversion.select('"
> > > > WXPYTHON_VERSION "')";
> > > >  
> > > > instead.
> > > >  
> > > > Sorry I don't have time to investigate the crash right now. Good Luck.
> > > >  
> > > > Best Regards,
> > > >  
> > > > Brian.
> > > >  
> > > > ___
> > > > Mailing list: https://launchpad.net/~kicad-developers
> > > > Post to : kicad-developers@lists.launchpad.net 
> > > > (mailto:kicad-developers@lists.launchpad.net)
> > > > 
> > > > Unsubscribe : https://launchpad.net/~kicad-developers
> > > > More help : https://help.launchpad.net/ListHelp
> > > >  
> > >  
> > >  
> > >  
> > >  
> > > ___
> > > Mailing list: https://launchpad.net/~kicad-developers
> > > Post to : kicad-developers@lists.launchpad.net 
> > > (mailto:kicad-developers@lists.launchpad.net)
> > > Unsubscribe : https://launchpad.net/~kicad-developers
> > > More help : https://help.launchpad.net/ListHelp
> > >  
> >  
> >  
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net 
> > (mailto:kicad-developers@lists.launchpad.net)
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help : https://help.launchpad.net/ListHelp
> >  
> >  
> >  
>  
>  

___
Mailing list: https://launchpad.net/~kicad-developers
Post 

Re: [Kicad-developers] wxPython version check

[Miguel Ángel Ajo]

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-3.0;-lwx_baseu_net-3.0;-lwx_baseu-3.0;-lwx_baseu_xml-3.0;-lwx_gtk2u_stc-3.0
 (found suitable version "3.0.2", minimum required is "3.0.0")

and I set KICAD_SCRIPTING_WXPYTHON on cmake:

https://copr-be.cloud.fedoraproject.org/results/mangelajo/kicad/fedora-21-x86_64/kicad-5429-nightlies.fc22/build.log.gz

I’m going to debug a bit to see what’s happening, and read the thread about the 
wxPython changes that
I didn’t have time to read in full.

Best reagards,
Miguel Ángel.


Miguel Ángel Ajo


On Wednesday, 18 de February de 2015 at 18:05, Wayne Stambaugh wrote:

> 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 Ángel Ajo wrote:
> > 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)
> > > > 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
> > > >  
> > > > snprintf( cmd, 1023, "import wxversion; wxversion.select('%s')",
> > > > WXPYTHON_VERSION );
> > > > PyRun_SimpleString( cmd );
> > > >  
> > >  
> > >  
> > > Probably a missing
> > >  
> > > PyLock lock;
> > >  
> > > Also, we don't need to use snprintf here, we can simply use:
> > >  
> > > const char* cmd = "import wxversion; wxversion.select('"
> > > WXPYTHON_VERSION "')";
> > >  
> > > instead.
> > >  
> > > Sorry I don't have time to investigate the crash right now. Good Luck.
> > >  
> > > Best Regards,
> > >  
> > > Brian.
> > >  
> > > ___
> > > Mailing list: https://launchpad.net/~kicad-developers
> > > Post to : kicad-developers@lists.launchpad.net 
> > > (mailto:kicad-developers@lists.launchpad.net)
> > > 
> > > Unsubscribe : https://launchpad.net/~kicad-developers
> > > More help : https://help.launchpad.net/ListHelp
> > >  
> >  
> >  
> >  
> >  
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net 
> > (mailto:kicad-developers@lists.launchpad.net)
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help : https://help.launchpad.net/ListHelp
> >  
>  
>  
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net 
> (mailto:kicad-developers@lists.launchpad.net)
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp
>  
>  


___
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] wxPython version check

[Wayne Stambaugh]

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 Ángel Ajo wrote:
> 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 > > 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
>>>
>>> snprintf( cmd, 1023, "import wxversion; wxversion.select('%s')",
>>> WXPYTHON_VERSION );
>>> PyRun_SimpleString( cmd );
>>
>> Probably a missing
>>
>> PyLock lock;
>>
>> Also, we don't need to use snprintf here, we can simply use:
>>
>> const char* cmd = "import wxversion; wxversion.select('"
>> WXPYTHON_VERSION "')";
>>
>> instead.
>>
>> Sorry I don't have time to investigate the crash right now. Good Luck.
>>
>> Best Regards,
>>
>> Brian.
>>
>> ___
>> 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
> 
> 
> 
> ___
> 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
> 

___
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] wxPython version check

[Miguel Ángel Ajo]

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)> 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
> >  
> > snprintf( cmd, 1023, "import wxversion; wxversion.select('%s')",
> > WXPYTHON_VERSION );
> > PyRun_SimpleString( cmd );
> >  
>  
>  
> Probably a missing
>  
> PyLock lock;
>  
> Also, we don't need to use snprintf here, we can simply use:
>  
> const char* cmd = "import wxversion; wxversion.select('"
> WXPYTHON_VERSION "')";
>  
> instead.
>  
> Sorry I don't have time to investigate the crash right now. Good Luck.
>  
> Best Regards,
>  
> Brian.
>  
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net 
> (mailto:kicad-developers@lists.launchpad.net)
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp
>  
>  


___
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] wxPython version check

[Brian Sidebotham]

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
>
> snprintf( cmd, 1023, "import wxversion; wxversion.select('%s')",
> WXPYTHON_VERSION );
> PyRun_SimpleString( cmd );
>

Probably a missing

PyLock lock;

Also, we don't need to use snprintf here, we can simply use:

const char* cmd = "import wxversion; wxversion.select('"
WXPYTHON_VERSION "')";

instead.

Sorry I don't have time to investigate the crash right now. Good Luck.

Best Regards,

Brian.

___
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] wxPython version check

[Miguel Ángel Ajo]

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')", 
WXPYTHON_VERSION ); PyRun_SimpleString( cmd );  


Miguel Ángel Ajo


On Tuesday, 17 de February de 2015 at 17:31, Brian Sidebotham wrote:

> On 16 February 2015 at 17:44, Wayne Stambaugh  (mailto:stambau...@gmail.com)> wrote:
> > On 2/16/2015 11:44 AM, Brian Sidebotham wrote:
> > > On 16 February 2015 at 15:42, Brian Sidebotham
> > > mailto:brian.sidebot...@gmail.com)> wrote:
> > > > On 16 February 2015 at 14:17, Wayne Stambaugh  > > > (mailto:stambau...@gmail.com)> 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 install wxPython somewhere other than where you defined
> > > > > PYTHON_SITE_PACKAGE_PATH, you would be right back to where you 
> > > > > started.
> > > > > In other words you could build kicad but when you launched the python
> > > > > console, it would most likely crash because wxPython would not be
> > > > > located at PYTHON_SITE_PACKAGE_PATH or worse a different version of
> > > > > wxPython would be loaded.
> > > > >  
> > > >  
> > > >  
> > > > Hi Wayne,
> > >  
> > > > These days however packages like mingw-w64-python2 exist and so really
> > > > we should be able to make use of that in KiCad-Winbuilder instead of
> > > > the custom projects. I'll look into it.
> > > >  
> > >  
> > >  
> > > I just checked 
> > > http://sourceforge.net/projects/msys2/files/REPOS/MINGW/i686/mingw-w64-i686-python2-2.7.9-2-any.pkg.tar.xz/download
> > >  
> > > Unfortunately we get: libgcc_s_dw2-1.dll is missing. This is a
> > > show-stopper in my opinion because dwarf-2 is known to be broken with
> > > regards to throwing exceptions across DLL boundaries. Since the Kiway
> > > work there's no real option but to support exception throwing across
> > > DLL boundaries otherwise exceptions cannot propagate correctly.
> > >  
> >  
> >  
> > After all this time, this issue hasn't been addressed? This was an
> > issue over 10 years ago. This makes me feel better about the bug fixing
> > rate in KiCad. I'm not sure which code in KiCad would cause this error.
> > Most of the exceptions that I can think of do not cross DLL boundaries.
> > They only cross from the DLL to the main executable which does not
> > fail. I just tested the pretty library parser which throws an IO_ERROR
> > from _pcbnew.kiface to pcbnew.exe without any issues. I don't think
> > wxWidgets raises any an most of Boost is the header libraries so that
> > wouldn't be an issue either. Do Python exceptions cross over into C++
> > land? If so, that could be an error.
> >  
>  
>  
> Hi Wayne,
>  
> Thanks so much for doing a quick sanity check. I forget the check I
> used to do. Perhaps it is no longer an issue these days and I'm worry
> about a past issue. I'll try and re-base KiCad-Winbuilder off the
> MSYS2 project MINGW repos for wxPython and python.
>  
> With regards to Python throwing exceptions, it's written entirely in C
> so there's no risk of it throwing exceptions.
>  
> Best Regards,
>  
> Brian.
>  
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net 
> (mailto:kicad-developers@lists.launchpad.net)
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp
>  
>  


___
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] wxPython version check

[Brian Sidebotham]

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 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_PACKAGE_PATH, you would be right back to where you started.
  In other words you could build kicad but when you launched the python
 console, it would most likely crash because wxPython would not be
 located at PYTHON_SITE_PACKAGE_PATH or worse a different version of
 wxPython would be loaded.
>>>
>>> Hi Wayne,
>>
>>> These days however packages like mingw-w64-python2 exist and so really
>>> we should be able to make use of that in KiCad-Winbuilder instead of
>>> the custom projects. I'll look into it.
>>>
>>
>> I just checked 
>> http://sourceforge.net/projects/msys2/files/REPOS/MINGW/i686/mingw-w64-i686-python2-2.7.9-2-any.pkg.tar.xz/download
>>
>> Unfortunately we get: libgcc_s_dw2-1.dll is missing. This is a
>> show-stopper in my opinion because dwarf-2 is known to be broken with
>> regards to throwing exceptions across DLL boundaries. Since the Kiway
>> work there's no real option but to support exception throwing across
>> DLL boundaries otherwise exceptions cannot propagate correctly.
>
> After all this time, this issue hasn't been addressed?  This was an
> issue over 10 years ago.  This makes me feel better about the bug fixing
> rate in KiCad.  I'm not sure which code in KiCad would cause this error.
>  Most of the exceptions that I can think of do not cross DLL boundaries.
>  They only cross from the DLL to the main executable which does not
> fail.  I just tested the pretty library parser which throws an IO_ERROR
> from _pcbnew.kiface to pcbnew.exe without any issues.  I don't think
> wxWidgets raises any an most of Boost is the header libraries so that
> wouldn't be an issue either.  Do Python exceptions cross over into C++
> land?  If so, that could be an error.
>

Hi Wayne,

Thanks so much for doing a quick sanity check. I forget the check I
used to do. Perhaps it is no longer an issue these days and I'm worry
about a past issue. I'll try and re-base KiCad-Winbuilder off the
MSYS2 project MINGW repos for wxPython and python.

With regards to Python throwing exceptions, it's written entirely in C
so there's no risk of it throwing exceptions.

Best Regards,

Brian.

___
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] wxPython version check

[Wayne Stambaugh]

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?  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_PACKAGE_PATH, you would be right back to where you started.
>>>  In other words you could build kicad but when you launched the python
>>> console, it would most likely crash because wxPython would not be
>>> located at PYTHON_SITE_PACKAGE_PATH or worse a different version of
>>> wxPython would be loaded.
>>
>> Hi Wayne,
> 
>> These days however packages like mingw-w64-python2 exist and so really
>> we should be able to make use of that in KiCad-Winbuilder instead of
>> the custom projects. I'll look into it.
>>
> 
> I just checked 
> http://sourceforge.net/projects/msys2/files/REPOS/MINGW/i686/mingw-w64-i686-python2-2.7.9-2-any.pkg.tar.xz/download
> 
> Unfortunately we get: libgcc_s_dw2-1.dll is missing. This is a
> show-stopper in my opinion because dwarf-2 is known to be broken with
> regards to throwing exceptions across DLL boundaries. Since the Kiway
> work there's no real option but to support exception throwing across
> DLL boundaries otherwise exceptions cannot propagate correctly.

After all this time, this issue hasn't been addressed?  This was an
issue over 10 years ago.  This makes me feel better about the bug fixing
rate in KiCad.  I'm not sure which code in KiCad would cause this error.
 Most of the exceptions that I can think of do not cross DLL boundaries.
 They only cross from the DLL to the main executable which does not
fail.  I just tested the pretty library parser which throws an IO_ERROR
from _pcbnew.kiface to pcbnew.exe without any issues.  I don't think
wxWidgets raises any an most of Boost is the header libraries so that
wouldn't be an issue either.  Do Python exceptions cross over into C++
land?  If so, that could be an error.

> 
> That's why the KiCad-Winbuilder toolchain uses mingw-w64 sjlj
> throughout (including dependencies) because it's not broken,
> regardless of whether it's regarded as slower than dwarf-2. x86_64
> should be good though as it uses SEH.
> 
> Is the KiCad msys2 package built using the same, I guess it must be?
> Really it means it's broken because there are plenty of places in the
> KiCad code when exceptions go across DLL boundaries. While it will
> work until an exception occurs, it will simply crash rather than
> handle the exception *if* the exception goes across a DLL boundary. I
> used to know how to trigger that in the KiCad code, but I cannot
> remember what I used to do. It is testable.
> 
> Therefore msys2 packages are not usable by KiCad-Winbuilder for now
> anyway, unless I move it to 64-bit only. (Does anyone still run 32-bit
> these days?)
> 
> Best Regards,
> 
> Brian.
> 


___
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] wxPython version check

[Nick Østergaard]

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?  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_PACKAGE_PATH, you would be right back to where you started.
>>>  In other words you could build kicad but when you launched the python
>>> console, it would most likely crash because wxPython would not be
>>> located at PYTHON_SITE_PACKAGE_PATH or worse a different version of
>>> wxPython would be loaded.
>>
>> Hi Wayne,
>
>> These days however packages like mingw-w64-python2 exist and so really
>> we should be able to make use of that in KiCad-Winbuilder instead of
>> the custom projects. I'll look into it.
>>
>
> I just checked 
> http://sourceforge.net/projects/msys2/files/REPOS/MINGW/i686/mingw-w64-i686-python2-2.7.9-2-any.pkg.tar.xz/download
>
> Unfortunately we get: libgcc_s_dw2-1.dll is missing. This is a
> show-stopper in my opinion because dwarf-2 is known to be broken with
> regards to throwing exceptions across DLL boundaries. Since the Kiway
> work there's no real option but to support exception throwing across
> DLL boundaries otherwise exceptions cannot propagate correctly.
>
> That's why the KiCad-Winbuilder toolchain uses mingw-w64 sjlj
> throughout (including dependencies) because it's not broken,
> regardless of whether it's regarded as slower than dwarf-2. x86_64
> should be good though as it uses SEH.
>
> Is the KiCad msys2 package built using the same, I guess it must be?
> Really it means it's broken because there are plenty of places in the
> KiCad code when exceptions go across DLL boundaries. While it will
> work until an exception occurs, it will simply crash rather than
> handle the exception *if* the exception goes across a DLL boundary. I
> used to know how to trigger that in the KiCad code, but I cannot
> remember what I used to do. It is testable.
>
> Therefore msys2 packages are not usable by KiCad-Winbuilder for now
> anyway, unless I move it to 64-bit only. (Does anyone still run 32-bit
> these days?)

MSYS2 can also build 32-bit, as far as I understand. (I am not sure if
this is what you say it can't according to your statement, but I think
so.)

___
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] wxPython version check

[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?  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_PACKAGE_PATH, you would be right back to where you started.
>>  In other words you could build kicad but when you launched the python
>> console, it would most likely crash because wxPython would not be
>> located at PYTHON_SITE_PACKAGE_PATH or worse a different version of
>> wxPython would be loaded.
>
> Hi Wayne,

> These days however packages like mingw-w64-python2 exist and so really
> we should be able to make use of that in KiCad-Winbuilder instead of
> the custom projects. I'll look into it.
>

I just checked 
http://sourceforge.net/projects/msys2/files/REPOS/MINGW/i686/mingw-w64-i686-python2-2.7.9-2-any.pkg.tar.xz/download

Unfortunately we get: libgcc_s_dw2-1.dll is missing. This is a
show-stopper in my opinion because dwarf-2 is known to be broken with
regards to throwing exceptions across DLL boundaries. Since the Kiway
work there's no real option but to support exception throwing across
DLL boundaries otherwise exceptions cannot propagate correctly.

That's why the KiCad-Winbuilder toolchain uses mingw-w64 sjlj
throughout (including dependencies) because it's not broken,
regardless of whether it's regarded as slower than dwarf-2. x86_64
should be good though as it uses SEH.

Is the KiCad msys2 package built using the same, I guess it must be?
Really it means it's broken because there are plenty of places in the
KiCad code when exceptions go across DLL boundaries. While it will
work until an exception occurs, it will simply crash rather than
handle the exception *if* the exception goes across a DLL boundary. I
used to know how to trigger that in the KiCad code, but I cannot
remember what I used to do. It is testable.

Therefore msys2 packages are not usable by KiCad-Winbuilder for now
anyway, unless I move it to 64-bit only. (Does anyone still run 32-bit
these days?)

Best Regards,

Brian.

___
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] wxPython version check

[Garth Corral]

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 (PATH)
---
Default: System site library path

When building KiCad with Python scripting enable, the Python site library path
is used by default.  If you want to install the KiCad Python extension in a
different path, set this variable to the desired path.

…

So, there is a documented build config variable that is for the express purpose 
of doing this, but it is not honored when checking the result, which means that 
using this variable can now lead to failure even if it’s properly done.  This 
is an issue at least on OS X.  For the record, I’m not using .download_foo to 
build wxPython.  I simply build it and point the kicad build at it through this 
config variable.  It never needs to be “installed” system-wide.

Garth

> On Feb 16, 2015, at 7:42 AM, 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?  The only issue I see with Garth's solution is
>> that if you install wxPython somewhere other than where you defined
>> PYTHON_SITE_PACKAGE_PATH, you would be right back to where you started.
>> In other words you could build kicad but when you launched the python
>> console, it would most likely crash because wxPython would not be
>> located at PYTHON_SITE_PACKAGE_PATH or worse a different version of
>> wxPython would be loaded.
> 
> Hi Wayne,
> 
> First off, I just had a look and this is an easy fix; In the
> environment I set up for building KiCad I just need to add the
> wxpython base dir to the PYTHONPATH. Easy peasy. I will roll a new
> version of KiCad-Winbuilder to fix this and also the dependencies of
> the keyword lexers are now correct so parallel build jobs can be used
> for the first compilation of KiCad too, so there are a few fixes that
> can be released. I need to bump wxPython up now too.
> 
> Currently, I just point wxWidgets_ROOT_DIR to the root directory of
> the wxpython-cmake archive (I won't call it an install because it's
> just a decompressed release from https://launchpad.net/wxwidgets-cmake
> ). This has previously been enough to complete the build.
> 
> If we wind the clock back to when wxPython was being integrated with
> KiCad life was different to what it is now. wxPython and Python on
> Windows were both built using MSVC. The official distributions still
> are of course. Dick made the commendable effort of providing a CMake
> system for building Python with gcc on Windows, so this meant we could
> link against libpython and pass around FILE* objects without fear of
> the dreaded C-Runtime version mismatch crashes.
> 
> After that, I did the same for wxPython because the gcc build using
> python on Windows was completely broke. That's not surprising as I
> just said, gcc python modules couldn't be linked to libpython after
> v2.4 ( or thereabouts ).
> 
> Those two projects got us everything we needed to link against
> wxPython and produce a working KiCad with python scripting on Windows.
> KiCad-Winbuilder became the testbed for it, in part to make sure the
> Windows install was going to be valid.
> 
> Because of the MSVC compilation of the official distributions of
> Python and wxPython we cannot use pre-installed versions and
> pragmatically enable wxPython support as far as I know. Hence, KiCad
> will have to bundle its own local Python and wxPython install that it
> was linked against. Hence, there's no need to worry about crossing
> over versions.
> 
> Boost is really the same, generally on Windows it's only available
> officially as an MSVC compiled target.
> 
> It's very much safest to build and link everything with the same
> compiler, ensuring that the ABI and C-Runtime remain constant across
> the whole build. These days I think these packages are available in a
> format we can use elsewhere, but they certainly weren't at the time.
> We had a load of problems with C-Runtime versioning and also C++ DLL
> ABI changes (That's just compiling with different versions of gcc!)
> 
> These days however packages like mingw-w64-python2 exist and so really
> we should be able to make use of that in KiCad-Winbuilder instead of
> the custom projects. I'll look into it.
> 
> Sorry for the long diatribe!
> 
>> I appreciate that you are providing external builders and I'm not trying
>> to make your life miserable.  Although I'm sure at times it must seem
>> that way.  I'm trying to find robust solutions for configuring and
>> building kicad.  I wish we had never gone down the download_foo path,
>> even for Boost.  It has been a tremendous suppor

Re: [Kicad-developers] wxPython version check

[Brian Sidebotham]

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 install wxPython somewhere other than where you defined
> PYTHON_SITE_PACKAGE_PATH, you would be right back to where you started.
>  In other words you could build kicad but when you launched the python
> console, it would most likely crash because wxPython would not be
> located at PYTHON_SITE_PACKAGE_PATH or worse a different version of
> wxPython would be loaded.

Hi Wayne,

First off, I just had a look and this is an easy fix; In the
environment I set up for building KiCad I just need to add the
wxpython base dir to the PYTHONPATH. Easy peasy. I will roll a new
version of KiCad-Winbuilder to fix this and also the dependencies of
the keyword lexers are now correct so parallel build jobs can be used
for the first compilation of KiCad too, so there are a few fixes that
can be released. I need to bump wxPython up now too.

Currently, I just point wxWidgets_ROOT_DIR to the root directory of
the wxpython-cmake archive (I won't call it an install because it's
just a decompressed release from https://launchpad.net/wxwidgets-cmake
). This has previously been enough to complete the build.

If we wind the clock back to when wxPython was being integrated with
KiCad life was different to what it is now. wxPython and Python on
Windows were both built using MSVC. The official distributions still
are of course. Dick made the commendable effort of providing a CMake
system for building Python with gcc on Windows, so this meant we could
link against libpython and pass around FILE* objects without fear of
the dreaded C-Runtime version mismatch crashes.

After that, I did the same for wxPython because the gcc build using
python on Windows was completely broke. That's not surprising as I
just said, gcc python modules couldn't be linked to libpython after
v2.4 ( or thereabouts ).

Those two projects got us everything we needed to link against
wxPython and produce a working KiCad with python scripting on Windows.
KiCad-Winbuilder became the testbed for it, in part to make sure the
Windows install was going to be valid.

Because of the MSVC compilation of the official distributions of
Python and wxPython we cannot use pre-installed versions and
pragmatically enable wxPython support as far as I know. Hence, KiCad
will have to bundle its own local Python and wxPython install that it
was linked against. Hence, there's no need to worry about crossing
over versions.

Boost is really the same, generally on Windows it's only available
officially as an MSVC compiled target.

It's very much safest to build and link everything with the same
compiler, ensuring that the ABI and C-Runtime remain constant across
the whole build. These days I think these packages are available in a
format we can use elsewhere, but they certainly weren't at the time.
We had a load of problems with C-Runtime versioning and also C++ DLL
ABI changes (That's just compiling with different versions of gcc!)

These days however packages like mingw-w64-python2 exist and so really
we should be able to make use of that in KiCad-Winbuilder instead of
the custom projects. I'll look into it.

Sorry for the long diatribe!

> I appreciate that you are providing external builders and I'm not trying
> to make your life miserable.  Although I'm sure at times it must seem
> that way.  I'm trying to find robust solutions for configuring and
> building kicad.  I wish we had never gone down the download_foo path,
> even for Boost.  It has been a tremendous support burden and a constant
> source of headaches.  We should have provided separate external builders
> for each dependency for problem the problem child platforms (OSX and
> windows) and kept the kicad source build configuration clean of any
> dependency building.  Hindsight is always 20/20.  The more I have to
> deal with this issue, the more I'm inclined to rip out all of the
> dependency build stuff once and for all.  It probably wont happen for
> the next stable release but it's priority continues to move up my todo
> list for the next development cycle.

No problem, don't worry about it too much. Everything is a moving
target. Wait until Windows 10 is out! ;)

I think the only thing that should be absolute is whatever clever
package searching we do is to provide a *_ROOT_DIR= be provided for
all packages we're using.

Certainly what we did have in mind were projects similar to the
https://launchpad.net/inkscape-devlibs project. That way, if anyone
wants to get developing KiCad fast they can grab the devlibs project
to satisfy all dependencies.

Sorry for the long email!

Best Regards,

Brian.

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.

Re: [Kicad-developers] wxPython version check

[Wayne Stambaugh]

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_PACKAGE_PATH, you would be right back to where you started.
 In other words you could build kicad but when you launched the python
console, it would most likely crash because wxPython would not be
located at PYTHON_SITE_PACKAGE_PATH or worse a different version of
wxPython would be loaded.

I appreciate that you are providing external builders and I'm not trying
to make your life miserable.  Although I'm sure at times it must seem
that way.  I'm trying to find robust solutions for configuring and
building kicad.  I wish we had never gone down the download_foo path,
even for Boost.  It has been a tremendous support burden and a constant
source of headaches.  We should have provided separate external builders
for each dependency for problem the problem child platforms (OSX and
windows) and kept the kicad source build configuration clean of any
dependency building.  Hindsight is always 20/20.  The more I have to
deal with this issue, the more I'm inclined to rip out all of the
dependency build stuff once and for all.  It probably wont happen for
the next stable release but it's priority continues to move up my todo
list for the next development cycle.

Cheers,

Wayne

On 2/16/2015 7:11 AM, Brian Sidebotham wrote:
> 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 had time to investigate the issue at all, I've just seen bug
> reports against KiCad-Winbuilder to this effect. Most likely I can fix
> it in KiCad-Winbuilder.
> 
> Best Regards,
> 
> Brian.
> 
> 
> On 16 February 2015 at 01:39, Garth Corral  wrote:
>> 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 needs to be prepended to the path of the python 
>> performing the check.
>>
>> -set( _py_cmd "import wxversion;print 
>> wxversion.checkInstalled('${_wxpy_version}')" )
>> +set( _py_cmd "import sys;sys.path.insert(0, 
>> \"${PYTHON_SITE_PACKAGE_PATH}\");import wxversion;print 
>> wxversion.checkInstalled('${_wxpy_version}')" )
>>
>> This works for me but if anyones sees an issue with this please speak up.  
>> If I got the quoting right then an unset PYTHON_SITE_PACKAGE_PATH would 
>> simply prepend an empty path and search the default sys.path as usual.
>>
>> Garth
>>
>>
>>> On Feb 15, 2015, at 4:55 PM, Wayne Stambaugh  wrote:
>>>
>>> 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 CMakeList.txt and
>>> send me a patch.  Maybe then I will understand how you would solve the
>>> problem.  Ignoring wxPython as a build dependency is not an option and
>>> neither is the download_foo ugliness that we currently have.  That
>>> should be moved to a higher level outside of the kicad source like
>>> kicad-winbuilder.
>>>


> 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 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 versions of wxWidgets for other developement work and
>> also wanted to build kicad with a different version?  It seems perfectly
>> reasonable to build wxPython specifically for kicad.
>
> It is.  I do it all the time.  I build and install the latest versions
> wxPython, wxWidgets, Boost, etc. and set up my build environment to
> build kicad against these custom builds without touching my default
> system configuration.  The key action is the install and configure part.
> Just building the correct version of a dependency is not enough.
>
>>
>> I also think that the build time and runtime behavior are being
>> conflated.  There is nothing other than the version check that requires
>> wxPython to ‘run’ at build time.  Prior to this it was enough to build
>> it and put ev

Re: [Kicad-developers] wxPython version check

[Brian Sidebotham]

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 had time to investigate the issue at all, I've just seen bug
reports against KiCad-Winbuilder to this effect. Most likely I can fix
it in KiCad-Winbuilder.

Best Regards,

Brian.


On 16 February 2015 at 01:39, Garth Corral  wrote:
> 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 needs to be prepended to the path of the python 
> performing the check.
>
> -set( _py_cmd "import wxversion;print 
> wxversion.checkInstalled('${_wxpy_version}')" )
> +set( _py_cmd "import sys;sys.path.insert(0, 
> \"${PYTHON_SITE_PACKAGE_PATH}\");import wxversion;print 
> wxversion.checkInstalled('${_wxpy_version}')" )
>
> This works for me but if anyones sees an issue with this please speak up.  If 
> I got the quoting right then an unset PYTHON_SITE_PACKAGE_PATH would simply 
> prepend an empty path and search the default sys.path as usual.
>
> Garth
>
>
>> On Feb 15, 2015, at 4:55 PM, Wayne Stambaugh  wrote:
>>
>> 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 CMakeList.txt and
>> send me a patch.  Maybe then I will understand how you would solve the
>> problem.  Ignoring wxPython as a build dependency is not an option and
>> neither is the download_foo ugliness that we currently have.  That
>> should be moved to a higher level outside of the kicad source like
>> kicad-winbuilder.
>>
>>>
>>>
 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 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 versions of wxWidgets for other developement work and
> also wanted to build kicad with a different version?  It seems perfectly
> reasonable to build wxPython specifically for kicad.

 It is.  I do it all the time.  I build and install the latest versions
 wxPython, wxWidgets, Boost, etc. and set up my build environment to
 build kicad against these custom builds without touching my default
 system configuration.  The key action is the install and configure part.
 Just building the correct version of a dependency is not enough.

>
> I also think that the build time and runtime behavior are being
> conflated.  There is nothing other than the version check that requires
> wxPython to ‘run’ at build time.  Prior to this it was enough to build
> it and put everything int the right place and then tell the python
> interpreter where to look a runtime.  At least that’s what’s been
> happening all along on OS X.

 This has been happening on all platform all along and it has bitten
 other devs because their wxWidgets and wxPythons version did not match
 causing pcbnew to crash.  There was even a bug report filed against it.
 That is why the change was made.

>
> This version check just assumes that it will be instaled on the system,
> and I think that’s wrong.

 That's exactly what build configuration tools like CMake and autotools
 are designed for not just creating Makefiles.  Why would you even
 attempt to build any software if the prerequisites cannot be found on
 your system?  How would you even know if the software was correctly
 built?  You have been doing this manually except in the wrong order.

>
> Garth
>
> On Feb 15, 2015, at 4:16 PM, Wayne Stambaugh  > wrote:
>>
>> 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 in the version check isn’t
>>> going to work without first pointing it to a path that contains the
>>> wxPython library.
>>>
>>> I’ve been building wxPython as part of my kicad builds and passing
>>> -DPYTHON_SITE_PA

Re: [Kicad-developers] wxPython version check

[Garth Corral]

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 needs to be prepended to the path of the python 
performing the check.

-set( _py_cmd "import wxversion;print 
wxversion.checkInstalled('${_wxpy_version}')" )
+set( _py_cmd "import sys;sys.path.insert(0, 
\"${PYTHON_SITE_PACKAGE_PATH}\");import wxversion;print 
wxversion.checkInstalled('${_wxpy_version}')" )

This works for me but if anyones sees an issue with this please speak up.  If I 
got the quoting right then an unset PYTHON_SITE_PACKAGE_PATH would simply 
prepend an empty path and search the default sys.path as usual.

Garth


> On Feb 15, 2015, at 4:55 PM, Wayne Stambaugh  wrote:
> 
> 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 CMakeList.txt and
> send me a patch.  Maybe then I will understand how you would solve the
> problem.  Ignoring wxPython as a build dependency is not an option and
> neither is the download_foo ugliness that we currently have.  That
> should be moved to a higher level outside of the kicad source like
> kicad-winbuilder.
> 
>> 
>> 
>>> 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 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 versions of wxWidgets for other developement work and
 also wanted to build kicad with a different version?  It seems perfectly
 reasonable to build wxPython specifically for kicad.
>>> 
>>> It is.  I do it all the time.  I build and install the latest versions
>>> wxPython, wxWidgets, Boost, etc. and set up my build environment to
>>> build kicad against these custom builds without touching my default
>>> system configuration.  The key action is the install and configure part.
>>> Just building the correct version of a dependency is not enough.
>>> 
 
 I also think that the build time and runtime behavior are being
 conflated.  There is nothing other than the version check that requires
 wxPython to ‘run’ at build time.  Prior to this it was enough to build
 it and put everything int the right place and then tell the python
 interpreter where to look a runtime.  At least that’s what’s been
 happening all along on OS X.
>>> 
>>> This has been happening on all platform all along and it has bitten
>>> other devs because their wxWidgets and wxPythons version did not match
>>> causing pcbnew to crash.  There was even a bug report filed against it.
>>> That is why the change was made.
>>> 
 
 This version check just assumes that it will be instaled on the system,
 and I think that’s wrong.
>>> 
>>> That's exactly what build configuration tools like CMake and autotools
>>> are designed for not just creating Makefiles.  Why would you even
>>> attempt to build any software if the prerequisites cannot be found on
>>> your system?  How would you even know if the software was correctly
>>> built?  You have been doing this manually except in the wrong order.
>>> 
 
 Garth
 
 On Feb 15, 2015, at 4:16 PM, Wayne Stambaugh >>> > wrote:
> 
> 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 in the version check isn’t
>> going to work without first pointing it to a path that contains the
>> wxPython library.
>> 
>> I’ve been building wxPython as part of my kicad builds and passing
>> -DPYTHON_SITE_PACKAGE_PATH to cmake with the built wxPython library.
>> Up to now this has worked for me.
> 
> This should have never worked in the first place.  Would you expect
> kicad to build if a valid version of wxWidgets or Boost could not be
> found?  The build configuration should have always checked for a valid
> install of wxPython before allowing you to build kicad with
> -DKICAD_SCRIPTING_WXPYTHON=ON.  You will have to tell the python
> interpreter where wxPython is installed before you configure the kicad
> build.  I'm sorry for the inconvenience but you've been skating on thin
>

Re: [Kicad-developers] wxPython version check

[Wayne Stambaugh]

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 CMakeList.txt and
send me a patch.  Maybe then I will understand how you would solve the
problem.  Ignoring wxPython as a build dependency is not an option and
neither is the download_foo ugliness that we currently have.  That
should be moved to a higher level outside of the kicad source like
kicad-winbuilder.

> 
> 
>> 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 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 versions of wxWidgets for other developement work and
>>> also wanted to build kicad with a different version?  It seems perfectly
>>> reasonable to build wxPython specifically for kicad.
>>
>> It is.  I do it all the time.  I build and install the latest versions
>> wxPython, wxWidgets, Boost, etc. and set up my build environment to
>> build kicad against these custom builds without touching my default
>> system configuration.  The key action is the install and configure part.
>> Just building the correct version of a dependency is not enough.
>>
>>>
>>> I also think that the build time and runtime behavior are being
>>> conflated.  There is nothing other than the version check that requires
>>> wxPython to ‘run’ at build time.  Prior to this it was enough to build
>>> it and put everything int the right place and then tell the python
>>> interpreter where to look a runtime.  At least that’s what’s been
>>> happening all along on OS X.
>>
>> This has been happening on all platform all along and it has bitten
>> other devs because their wxWidgets and wxPythons version did not match
>> causing pcbnew to crash.  There was even a bug report filed against it.
>> That is why the change was made.
>>
>>>
>>> This version check just assumes that it will be instaled on the system,
>>> and I think that’s wrong.
>>
>> That's exactly what build configuration tools like CMake and autotools
>> are designed for not just creating Makefiles.  Why would you even
>> attempt to build any software if the prerequisites cannot be found on
>> your system?  How would you even know if the software was correctly
>> built?  You have been doing this manually except in the wrong order.
>>
>>>
>>> Garth
>>>
>>> On Feb 15, 2015, at 4:16 PM, Wayne Stambaugh >> > wrote:

 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 in the version check isn’t
> going to work without first pointing it to a path that contains the
> wxPython library.
>
> I’ve been building wxPython as part of my kicad builds and passing
> -DPYTHON_SITE_PACKAGE_PATH to cmake with the built wxPython library.
> Up to now this has worked for me.

 This should have never worked in the first place.  Would you expect
 kicad to build if a valid version of wxWidgets or Boost could not be
 found?  The build configuration should have always checked for a valid
 install of wxPython before allowing you to build kicad with
 -DKICAD_SCRIPTING_WXPYTHON=ON.  You will have to tell the python
 interpreter where wxPython is installed before you configure the kicad
 build.  I'm sorry for the inconvenience but you've been skating on thin
 ice with the previous behavior.

>
>
> Garth
>
>
>> On Feb 15, 2015, at 3:54 PM, Wayne Stambaugh > > wrote:
>>
>> 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 installed before you can use it either by installing wxPython into
>> your python library path, adding the path programmatically during python
>> scripting initialization, or using PTYHONPATH.
>>
>> On 2/15/2015 6:39 PM, Garth Corral wrote:
>>> 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 bu

Re: [Kicad-developers] wxPython version check

[Garth Corral]

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 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 versions of wxWidgets for other developement work and
>> also wanted to build kicad with a different version?  It seems perfectly
>> reasonable to build wxPython specifically for kicad.
> 
> It is.  I do it all the time.  I build and install the latest versions
> wxPython, wxWidgets, Boost, etc. and set up my build environment to
> build kicad against these custom builds without touching my default
> system configuration.  The key action is the install and configure part.
> Just building the correct version of a dependency is not enough.
> 
>> 
>> I also think that the build time and runtime behavior are being
>> conflated.  There is nothing other than the version check that requires
>> wxPython to ‘run’ at build time.  Prior to this it was enough to build
>> it and put everything int the right place and then tell the python
>> interpreter where to look a runtime.  At least that’s what’s been
>> happening all along on OS X.
> 
> This has been happening on all platform all along and it has bitten
> other devs because their wxWidgets and wxPythons version did not match
> causing pcbnew to crash.  There was even a bug report filed against it.
> That is why the change was made.
> 
>> 
>> This version check just assumes that it will be instaled on the system,
>> and I think that’s wrong.
> 
> That's exactly what build configuration tools like CMake and autotools
> are designed for not just creating Makefiles.  Why would you even
> attempt to build any software if the prerequisites cannot be found on
> your system?  How would you even know if the software was correctly
> built?  You have been doing this manually except in the wrong order.
> 
>> 
>> Garth
>> 
>> On Feb 15, 2015, at 4:16 PM, Wayne Stambaugh > > wrote:
>>> 
>>> 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 in the version check isn’t
 going to work without first pointing it to a path that contains the
 wxPython library.
 
 I’ve been building wxPython as part of my kicad builds and passing
 -DPYTHON_SITE_PACKAGE_PATH to cmake with the built wxPython library.
 Up to now this has worked for me.
>>> 
>>> This should have never worked in the first place.  Would you expect
>>> kicad to build if a valid version of wxWidgets or Boost could not be
>>> found?  The build configuration should have always checked for a valid
>>> install of wxPython before allowing you to build kicad with
>>> -DKICAD_SCRIPTING_WXPYTHON=ON.  You will have to tell the python
>>> interpreter where wxPython is installed before you configure the kicad
>>> build.  I'm sorry for the inconvenience but you've been skating on thin
>>> ice with the previous behavior.
>>> 
 
 
 Garth
 
 
> On Feb 15, 2015, at 3:54 PM, Wayne Stambaugh  > wrote:
> 
> 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 installed before you can use it either by installing wxPython into
> your python library path, adding the path programmatically during python
> scripting initialization, or using PTYHONPATH.
> 
> On 2/15/2015 6:39 PM, Garth Corral wrote:
>> 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 the libraries are moved into the right places.
>> 
>> Garth
>> 
>>> On Feb 15, 2015, at 3:36 PM, Wayne Stambaugh >> > wrote:
>>> 
>>> 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 wrote:
>>>

Re: [Kicad-developers] wxPython version check

[Wayne Stambaugh]

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 right thing.  What if I
> needed different versions of wxWidgets for other developement work and
> also wanted to build kicad with a different version?  It seems perfectly
> reasonable to build wxPython specifically for kicad.

It is.  I do it all the time.  I build and install the latest versions
wxPython, wxWidgets, Boost, etc. and set up my build environment to
build kicad against these custom builds without touching my default
system configuration.  The key action is the install and configure part.
 Just building the correct version of a dependency is not enough.

> 
> I also think that the build time and runtime behavior are being
> conflated.  There is nothing other than the version check that requires
> wxPython to ‘run’ at build time.  Prior to this it was enough to build
> it and put everything int the right place and then tell the python
> interpreter where to look a runtime.  At least that’s what’s been
> happening all along on OS X.

This has been happening on all platform all along and it has bitten
other devs because their wxWidgets and wxPythons version did not match
causing pcbnew to crash.  There was even a bug report filed against it.
 That is why the change was made.

> 
> This version check just assumes that it will be instaled on the system,
> and I think that’s wrong.

That's exactly what build configuration tools like CMake and autotools
are designed for not just creating Makefiles.  Why would you even
attempt to build any software if the prerequisites cannot be found on
your system?  How would you even know if the software was correctly
built?  You have been doing this manually except in the wrong order.

> 
> Garth
> 
> On Feb 15, 2015, at 4:16 PM, Wayne Stambaugh  > wrote:
>>
>> 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 in the version check isn’t
>>> going to work without first pointing it to a path that contains the
>>> wxPython library.
>>>
>>> I’ve been building wxPython as part of my kicad builds and passing
>>> -DPYTHON_SITE_PACKAGE_PATH to cmake with the built wxPython library.
>>>  Up to now this has worked for me.
>>
>> This should have never worked in the first place.  Would you expect
>> kicad to build if a valid version of wxWidgets or Boost could not be
>> found?  The build configuration should have always checked for a valid
>> install of wxPython before allowing you to build kicad with
>> -DKICAD_SCRIPTING_WXPYTHON=ON.  You will have to tell the python
>> interpreter where wxPython is installed before you configure the kicad
>> build.  I'm sorry for the inconvenience but you've been skating on thin
>> ice with the previous behavior.
>>
>>>
>>>
>>> Garth
>>>
>>>
 On Feb 15, 2015, at 3:54 PM, Wayne Stambaugh >>> > wrote:

 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 installed before you can use it either by installing wxPython into
 your python library path, adding the path programmatically during python
 scripting initialization, or using PTYHONPATH.

 On 2/15/2015 6:39 PM, Garth Corral wrote:
> 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 the libraries are moved into the right places.
>
> Garth
>
>> On Feb 15, 2015, at 3:36 PM, Wayne Stambaugh > > wrote:
>>
>> 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 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 

Re: [Kicad-developers] wxPython version check

[Garth Corral]

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 versions of wxWidgets 
for other developement work and also wanted to build kicad with a different 
version?  It seems perfectly reasonable to build wxPython specifically for 
kicad.

I also think that the build time and runtime behavior are being conflated.  
There is nothing other than the version check that requires wxPython to ‘run’ 
at build time.  Prior to this it was enough to build it and put everything int 
the right place and then tell the python interpreter where to look a runtime.  
At least that’s what’s been happening all along on OS X.

This version check just assumes that it will be instaled on the system, and I 
think that’s wrong.

Garth

On Feb 15, 2015, at 4:16 PM, Wayne Stambaugh  wrote:
> 
> 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 in the version check isn’t going to work without 
>> first pointing it to a path that contains the wxPython library.
>> 
>> I’ve been building wxPython as part of my kicad builds and passing 
>> -DPYTHON_SITE_PACKAGE_PATH to cmake with the built wxPython library.  Up to 
>> now this has worked for me.
> 
> This should have never worked in the first place.  Would you expect
> kicad to build if a valid version of wxWidgets or Boost could not be
> found?  The build configuration should have always checked for a valid
> install of wxPython before allowing you to build kicad with
> -DKICAD_SCRIPTING_WXPYTHON=ON.  You will have to tell the python
> interpreter where wxPython is installed before you configure the kicad
> build.  I'm sorry for the inconvenience but you've been skating on thin
> ice with the previous behavior.
> 
>> 
>> 
>> Garth
>> 
>> 
>>> On Feb 15, 2015, at 3:54 PM, Wayne Stambaugh  wrote:
>>> 
>>> 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 installed before you can use it either by installing wxPython into
>>> your python library path, adding the path programmatically during python
>>> scripting initialization, or using PTYHONPATH.
>>> 
>>> On 2/15/2015 6:39 PM, Garth Corral wrote:
 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 the libraries are moved into the right places.
 
 Garth
 
> On Feb 15, 2015, at 3:36 PM, Wayne Stambaugh  wrote:
> 
> 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 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 else experiencing this?
>> 
>> 
>> Garth
>> 
>> 
>> 
>> ___
>> 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
>> 
> 
> 
> ___
> 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
 
>>> 
>>> 
>>> ___
>>> 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
>> 
> 
> 
> ___
> Mailing list: https:/

Re: [Kicad-developers] wxPython version check

[Wayne Stambaugh]

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 in the version check isn’t going to work without 
> first pointing it to a path that contains the wxPython library.
> 
> I’ve been building wxPython as part of my kicad builds and passing 
> -DPYTHON_SITE_PACKAGE_PATH to cmake with the built wxPython library.  Up to 
> now this has worked for me.

This should have never worked in the first place.  Would you expect
kicad to build if a valid version of wxWidgets or Boost could not be
found?  The build configuration should have always checked for a valid
install of wxPython before allowing you to build kicad with
-DKICAD_SCRIPTING_WXPYTHON=ON.  You will have to tell the python
interpreter where wxPython is installed before you configure the kicad
build.  I'm sorry for the inconvenience but you've been skating on thin
ice with the previous behavior.

> 
> 
> Garth
> 
> 
>> On Feb 15, 2015, at 3:54 PM, Wayne Stambaugh  wrote:
>>
>> 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 installed before you can use it either by installing wxPython into
>> your python library path, adding the path programmatically during python
>> scripting initialization, or using PTYHONPATH.
>>
>> On 2/15/2015 6:39 PM, Garth Corral wrote:
>>> 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 the libraries are moved into the right places.
>>>
>>> Garth
>>>
 On Feb 15, 2015, at 3:36 PM, Wayne Stambaugh  wrote:

 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 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 else experiencing this?
>
>
> Garth
>
>
>
> ___
> 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
>


 ___
 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
>>>
>>
>>
>> ___
>> 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
> 


___
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] wxPython version check

[Garth Corral]

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 first 
pointing it to a path that contains the wxPython library.

I’ve been building wxPython as part of my kicad builds and passing 
-DPYTHON_SITE_PACKAGE_PATH to cmake with the built wxPython library.  Up to now 
this has worked for me.


Garth


> On Feb 15, 2015, at 3:54 PM, Wayne Stambaugh  wrote:
> 
> 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 installed before you can use it either by installing wxPython into
> your python library path, adding the path programmatically during python
> scripting initialization, or using PTYHONPATH.
> 
> On 2/15/2015 6:39 PM, Garth Corral wrote:
>> 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 the 
>> libraries are moved into the right places.
>> 
>> Garth
>> 
>>> On Feb 15, 2015, at 3:36 PM, Wayne Stambaugh  wrote:
>>> 
>>> 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 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 
 else experiencing this?
 
 
 Garth
 
 
 
 ___
 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
 
>>> 
>>> 
>>> ___
>>> 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
>> 
> 
> 
> ___
> 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



smime.p7s
Description: S/MIME cryptographic signature
___
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] wxPython version check

[Wayne Stambaugh]

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 installed before you can use it either by installing wxPython into
your python library path, adding the path programmatically during python
scripting initialization, or using PTYHONPATH.

On 2/15/2015 6:39 PM, Garth Corral wrote:
> 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 the libraries 
> are moved into the right places.
> 
> Garth
> 
>> On Feb 15, 2015, at 3:36 PM, Wayne Stambaugh  wrote:
>>
>> 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 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 
>>> else experiencing this?
>>>
>>>
>>> Garth
>>>
>>>
>>>
>>> ___
>>> 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
>>>
>>
>>
>> ___
>> 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
> 


___
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] wxPython version check

[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 the libraries are 
moved into the right places.

Garth

> On Feb 15, 2015, at 3:36 PM, Wayne Stambaugh  wrote:
> 
> 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 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 else 
>> experiencing this?
>> 
>> 
>> Garth
>> 
>> 
>> 
>> ___
>> 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
>> 
> 
> 
> ___
> 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



smime.p7s
Description: S/MIME cryptographic signature
___
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] wxPython version check

[Wayne Stambaugh]

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 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 else 
> experiencing this?
> 
> 
> Garth
> 
> 
> 
> ___
> 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
> 


___
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] wxPython version check.

[Wayne Stambaugh]

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 never see this but on an existing
build running `make rebuild_cache` is not obvious.

On 2/15/2015 11:20 AM, Nick Østergaard wrote:
> 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.  To verify the
>> correct wxPython version string is being created by CMake, run the
>> following command from your build path:
>>
>> grep WXPYTHON < CMakeCache.txt
>>
>> you should see something like:
>>
>> KICAD_SCRIPTING_WXPYTHON:BOOL=ON
>> WXPYTHON_VERSION_FOUND:STRING=3.0
>>
>> The value of WXPYTHON_VERSION_FOUND should be have the same major and
>> minor version of the version as one of the versions of wxWidgets
>> installed on your system.
>>
>> On 02/15/2015 06:56 AM, Nick Østergaard wrote:
>>> Hi Wayne
>>>
>>> I think I have some problems related to this. I am on 5420.
>>>
>>> When I start pcbnew from commandline I get:
>>> $ pcbnew
>>> Traceback (most recent call last):
>>>   File "", line 1, in 
>>>   File "/usr/lib/python2.7/site-packages/wxversion.py", line 149, in select
>>> bestMatch = _get_best_match(installed, versions, optionsRequired)
>>>   File "/usr/lib/python2.7/site-packages/wxversion.py", line 273, in
>>> _get_best_match
>>> score = pkg.Score(_wxPackageInfo(ver), optionsRequired)
>>>   File "/usr/lib/python2.7/site-packages/wxversion.py", line 357, in 
>>> __init__
>>> self.version = tuple([int(x) for x in segments[0].split('.')])
>>> ValueError: invalid literal for int() with base 10: ''
>>> ImportError: No module named wx._core_
>>>
>>> When I start the scripting console from the toolbar it segfaults. I
>>> can provide a trace if nessesary.
>>>
>>> Also I get these error messages in an error dialog when pcbnew starts:
>>>
>>> 12:53:33: * Error importing the wxPython API! *
>>> 12:53:33: pcbnewInitPythonScripting() failed. (error 0: Success)
>>>
>>> If I try to import the module wx._core_ in python3 I get the import
>>> error, if I do it in python2 the imoport works. It should be mentioned
>>> that my default python is python3.
>>>
>>> I have the following installed on archlinux:
>>> wxgtk 3.0.2
>>> wxgtk2.8 2.8.12.1
>>> wxpython 3.0.2.0
>>> wxpython2.8 2.8.12.1
>>>
>>> Regards
>>> Nick Østergaard
>>>
>>> 2015-02-15 1:42 GMT+01:00 Wayne Stambaugh :
 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 the found wxWidgets and fail the build
 configuration when the wxPython version does not match the wxWidgets
 version.  I did not test the micro version number because wxPython tends
 to lag wxWidgets and the micro version changes are according to
 wxWidgets only bug fixes so using the major and minor version numbers
 should be safe.

 3) Add code to the python scripting initialization to select the
 appropriate version of wxPython.

 I tested this on windows and Linux and it seems to work but I do not
 have multiple versions of wxPython installed on either system.  If
 someone has multiple versions of wxPython on their system, please verify
 that this change fixes the problem.  I would also like one of the OSX
 devs to confirm that this didn't break anything on OSX.

 Thanks,

 Wayne

 ___
 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


___
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] wxPython version check.

[Nick Østergaard]

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.  To verify the
> correct wxPython version string is being created by CMake, run the
> following command from your build path:
>
> grep WXPYTHON < CMakeCache.txt
>
> you should see something like:
>
> KICAD_SCRIPTING_WXPYTHON:BOOL=ON
> WXPYTHON_VERSION_FOUND:STRING=3.0
>
> The value of WXPYTHON_VERSION_FOUND should be have the same major and
> minor version of the version as one of the versions of wxWidgets
> installed on your system.
>
> On 02/15/2015 06:56 AM, Nick Østergaard wrote:
>> Hi Wayne
>>
>> I think I have some problems related to this. I am on 5420.
>>
>> When I start pcbnew from commandline I get:
>> $ pcbnew
>> Traceback (most recent call last):
>>   File "", line 1, in 
>>   File "/usr/lib/python2.7/site-packages/wxversion.py", line 149, in select
>> bestMatch = _get_best_match(installed, versions, optionsRequired)
>>   File "/usr/lib/python2.7/site-packages/wxversion.py", line 273, in
>> _get_best_match
>> score = pkg.Score(_wxPackageInfo(ver), optionsRequired)
>>   File "/usr/lib/python2.7/site-packages/wxversion.py", line 357, in __init__
>> self.version = tuple([int(x) for x in segments[0].split('.')])
>> ValueError: invalid literal for int() with base 10: ''
>> ImportError: No module named wx._core_
>>
>> When I start the scripting console from the toolbar it segfaults. I
>> can provide a trace if nessesary.
>>
>> Also I get these error messages in an error dialog when pcbnew starts:
>>
>> 12:53:33: * Error importing the wxPython API! *
>> 12:53:33: pcbnewInitPythonScripting() failed. (error 0: Success)
>>
>> If I try to import the module wx._core_ in python3 I get the import
>> error, if I do it in python2 the imoport works. It should be mentioned
>> that my default python is python3.
>>
>> I have the following installed on archlinux:
>> wxgtk 3.0.2
>> wxgtk2.8 2.8.12.1
>> wxpython 3.0.2.0
>> wxpython2.8 2.8.12.1
>>
>> Regards
>> Nick Østergaard
>>
>> 2015-02-15 1:42 GMT+01:00 Wayne Stambaugh :
>>> 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 the found wxWidgets and fail the build
>>> configuration when the wxPython version does not match the wxWidgets
>>> version.  I did not test the micro version number because wxPython tends
>>> to lag wxWidgets and the micro version changes are according to
>>> wxWidgets only bug fixes so using the major and minor version numbers
>>> should be safe.
>>>
>>> 3) Add code to the python scripting initialization to select the
>>> appropriate version of wxPython.
>>>
>>> I tested this on windows and Linux and it seems to work but I do not
>>> have multiple versions of wxPython installed on either system.  If
>>> someone has multiple versions of wxPython on their system, please verify
>>> that this change fixes the problem.  I would also like one of the OSX
>>> devs to confirm that this didn't break anything on OSX.
>>>
>>> Thanks,
>>>
>>> Wayne
>>>
>>> ___
>>> 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

___
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