On 11/11/2011 8:55 AM, Øyvind Aabling wrote: > 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 found it. I got bitten by KiCad's internal use or relative paths again. I thought I had fixed all of those cases. Apparently not. When I save to a library in the project path, I get the empty path assertion. I was saving my libraries to a different path which isn't a problem where as you were saving to a library in the project path. I'll take another look and make sure I didn't miss this anywhere else. I should be able to get this fixed today. Thanks again for you effort and patience. Wayne > > 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 : [email protected] /~\ 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. _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
