| Thread Previous • Date Previous • Date Next • Thread Next |
On 11/10/2011 6:25 PM, Øyvind Aabling wrote:
On Thu, 10 Nov 2011, Wayne Stambaugh wrote:On 11/10/2011 1:15 PM, Øyvind Aabling wrote:There seems to be a problem with the eeschema library editor in recent BZR versions of kicad: Changes to edited parts aren't saved to disk, and the only way to exit the library editor is to discard all changes :-( I've now checked the BZR versions that I've been running lately, and it works in BZR 3001 and 3153, and is broken in 3212, 3221 and 3226 (so it broke somewhere between 3153 and 3212). I've updated my Debian recently, so I pulled BZR 3001 again (had deleted it :-) and the latest (BZR 3226), and compiled both, to see if the problem was (in some obscure way) related to library files on my system that have been upgraded since compiling the various versions of kicad (No, it isn't ...). To recreate: Start eeschema, start the Library Editor, "Select working library", (any library that you have write access to, e.g. in your project dir) "Load component to edit from the current lib", (any component will do) "Create a new component from the current one", (or change the component in some way, or create a new component, or ... - anything that's considered a change) "Update current component in current library", (this step can be skipped - the next step will then ask for inclusion of the changes, which doesn't make any difference on the behaviour) "Save current library to disk" Include last component changes? Yes Modify library file "<name>.lib"? Yes Now, the <name>.lib and/or <name>.dcm file(s) should have been updated, but no, they're not, and the "Save current library to disk" icon (far left) doesn't inactivate (gray out) either.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.
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.
Let's see if we can save the changed/new part to a new library: "Save current component to new library" Yes :-), the file <part>.lib is created (in the current dir). The file <part>.dcm doesn't get created, but it didn't either in the earlier versions of kicad (maybe it should ?).You should have gotten a warning dialog that your new library needs to be added to the project at this point.Yep, I did get that warning dialog. Save to new lib was only to verify that the lib editor could still save a file, and that it would choose the correct directory (the project dir).The only way to exit the library editor is to discard all changes: "Quit" Library "<name>" was modified! Discard changes? No -> Can't quit library editor :-( Yes -> The changes made are lost :-(This is the correct behavior. You didn't save the changes you made to the current component to the current library. You only save them to a new library which is what you requested. The modified component in the currently library still exists. The new library is not loaded when you saved the modified component to a new library that's why the save current library tool bar button is still enabled. You must open the library dialog in the preferences menu and add your new library to the project in order to use it. I don't ever remember the library editor ever behaving differently than this.Well, I _did_ try to save to the selected lib first, but nothing happened :-(The running eeschema _does_ seem to remember the changes, though, so I didn't notice the failure to save the changes to disk at first (thought it was just a minor problem with the "changes made" flag) ... ... at least until I deleted the *-cache.lib files, and then suddenly parts disappeared or reverted back to an older version :-( Fortunately, it was only a few simple changes ... 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.
WayneØ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.
| Thread Previous • Date Previous • Date Next • Thread Next |
