kicad-developers team mailing list archive

["�vind Aabling" <Oyvind.Aabling@xxxxxxxx>]

On Fri, 11 Nov 2011, Wayne Stambaugh wrote:

[]
> > > I do not have this problem on 64 bit Debian Testing using KiCad version 
> > > BZR
> > > 3226 and wxWidgets 2.8.12 even with all of the fancy new Gnome 3 stuff. 
> > > The
> > > library file changes are saved properly and the save current library tool 
> > > bar
> > > icon and file menu entry are disabled as expected.
> >
> > Well, I kinda suspected that, as such a major
> > problem probably couldn't go unnoticed for long :-)
> >
> > I'm also using 64-bit Debian Testing, but with wxWidgets 2.8.10.1-3.1.
> >
> > With wxWidgets upgraded to 2.8.12.1-2, I've now recompiled a
> > clean BZR 3226 tree with $MAKE unset (normally set to "make -j5").
> >
> > The problem isn't in wxWidgets or the parallel
> > make, as the problem still persists :-(
>
> Are you using any custom GCC optimization settings?  I'm using the default 
> settings generated by CMake.  Other than that I don't know what to tell you. 
> I wish I could be more helpful.

No, nothing:
$ cmake -DCMAKE_INSTALL_PREFIX=/usr/local/kicad-XXXX \
        -DKICAD_TESTING_VERSION=ON ../ ; make ; make install

And I don't have any relevant env vars either, except
maybe MAKE="make -j5", but as I said, removing that
doesn't make any difference, so can't be that either.

I've found the (short) piece of code that hits me,
hopefully you can make more sense out of why than I can ...

> > Since you don't see this problem on a similar system, it sounds like
> > my system contains a buggy version of some (other) library - one that
> > contains a feature not used in kicad until somewhere between 3153 and 3212.
> >
> > Even though I upgraded only a few weeks ago, apt-get now wants
> > to update almost 1k packages (out of 3k), so I think I'll do a
> > full (dist-)upgrade tomorrow, and see if that makes a difference.
> >
> > Btw., the only warnings (no errors) I got from the 3226
> > compile was these, which AFAICS doesn't affect eeschema:
> >
> > Scanning dependencies of target pcbcommon
> > [ 50%] Building CXX object common/CMakeFiles/pcbcommon.dir/pcbcommon.cpp.o
> > [ 50%] Building CXX object 
> > common/CMakeFiles/pcbcommon.dir/footprint_info.cpp.o
> > [ 50%] Building CXX object
> > common/CMakeFiles/pcbcommon.dir/class_layer_box_selector.cpp.o
> > /home/kicad/kicad-3226/common/class_layer_box_selector.cpp: In member 
> > function
> > 'int LAYER_BOX_SELECTOR::SetLayerSelection(int)':
> > /home/kicad/kicad-3226/common/class_layer_box_selector.cpp:87:43: warning: 
> > cast
> > to pointer from integer of different size [-Wint-to-pointer-cast]
> > /home/kicad/kicad-3226/common/class_layer_box_selector.cpp: In member 
> > function
> > 'void LAYER_BOX_SELECTOR::Resync()':
> > /home/kicad/kicad-3226/common/class_layer_box_selector.cpp:148:46: warning:
> > cast to pointer from integer of different size [-Wint-to-pointer-cast]
> > [ 50%] Building CXX object
> > common/CMakeFiles/pcbcommon.dir/__/pcbnew/basepcbframe.cpp.o
>
> This is the PCB layer widget so it is not part of Eeschema.  Although we 
> probably should fix the warning.

Yes, figured as much :-)

[]
> > > > Btw., "bzr -r revno:3001 update" _does_ downgrade the source to
> > > > BZR 3001, and the resulting kicad _is_ the older version (old style
> > > > icons and layout, and w/o the lib editor bug), but it presents
> > > > itself in the kicad titlebar as the newest BZR release ?
> > > > This was a bit confusing at first ...
> > >
> > > Run "make rebuild_cache" before running "make" to update the version file
> > > every time you update your source branch. Otherwise the version file will 
> > > be
> > > out of synch with the repo version.
> >
> > This was just a minor confusion, but as I copy (rsync) a clean and
> > freshly updated (or in this case, downgraded) bzr source tree to another
> > location for cmake + make, I found this behaviour a bit strange.
> >
> > "make rebuild_cache" sounds like the right cure, although
> > I don't quite understand why it should be necessary.
> > ... unless the bzr tree contains a file with the newest known release
> > no. in it, which then gets used by kicad (w/o the "make rebuild_cache").
>
> I'm sure CMake could be coerced to generate a make file that check to see if 
> the bzr version has changed and regenerate the version file before compiling. 
> I'll add it to my todo list.

There's some more info in the mail I just sent: Looks like the relevant
info isn't easily available, so probably a bzr bug (or missing feature) ...

> > > Wayne
> >
> > Øyvind.

Øyvind.

**************************************************************************
* Øyvind Aabling     E-mail : Oyvind.Aabling@xxxxxxxx    /~\ The ASCII   *
* UNI-C Lyngby       Phone  : +45 35 87 88 89            \ / Ribbon      *
* DTU Building 304   Phone  : +45 35 87 89 51 (direct)    X  Campaign    *
* DK-2800 Lyngby     Fax    : +45 35 87 89 90            / \ Against     *
* Denmark            Web    : http://www.uni-c.dk/           HTML Email! *
**************************************************************************
Quidquid latine dictum sit, altum viditur.