← Back to team overview

kicad-developers team mailing list archive

Re: Failure-to-save bug in eeschema library editor ?


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

With wxWidgets upgraded to, 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
/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

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




* Ø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.

Follow ups