kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

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