Re: [Kicad-developers] Back annotate references from PCB

[Brian Piccioni]

Usually, pin swapping is constrained to the same package, so Unit A -> 
Unit B, or inputs of a particular unit. As I understand it, this is 
constrained by the schematic symbol definition.


When I was an engineer, I always had to sign off on a layout, just in 
case the PCB designer did something like what you describe. I'm guessing 
somebody goofed.




On 2022-05-29 4:09 p.m., Kevin Cozens wrote:

On 2019-12-02 12:52 a.m., Alexander Shuklin wrote:

I would say, pin swapping is just will be an another tool (you
probably need some specific piece of GUI for that).


Be very careful about how pin swapping is handled. Many years ago 
someone made a board that could be plugged in to an Amiga 1000 to 
allow the use of a 68020 CPU in place of the stock 68000.


The board editor swapped a few gates between packages to simplify 
routing. It didn't take in to account that it was swapping some gates 
between a regular LS part and an F part. As a result the final board 
would work properly if you installed one of the LS parts with a low 
enough propagation delay.




___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Get wxWidgets 3.1.5 package for MSYS2

[Brian Piccioni]

Are you doing this from an MSYS2 window or MinGW64 window? Because I was 
doing the former and had all sorts of problems like this.


On 2021-07-02 11:39 p.m., Pradeepa Senanayake wrote:
One more issue in the build related to the crypt.h file in python. Are 
there any other package changes from the doc?


>>>>
[  6%] Building CXX object 
common/CMakeFiles/gal.dir/view/wx_view_controls.cpp.obj
In file included from 
I:/my_projects/kicad/thirdparty/pybind11/include/pybind11/detail/common.h:119,
                 from 
I:/my_projects/kicad/thirdparty/pybind11/include/pybind11/pytypes.h:12,
                 from 
I:/my_projects/kicad/thirdparty/pybind11/include/pybind11/cast.h:13,
                 from 
I:/my_projects/kicad/thirdparty/pybind11/include/pybind11/attr.h:13,
                 from 
I:/my_projects/kicad/thirdparty/pybind11/include/pybind11/pybind11.h:45,
                 from 
I:/my_projects/kicad/thirdparty/pybind11/include/pybind11/embed.h:12,

                 from I:/my_projects/kicad/include/pgm_base.h:41,
                 from 
I:/my_projects/kicad/common/view/wx_view_controls.cpp:29:
C:/msys64/usr/include/python3.9/Python.h:44:10: fatal error: crypt.h: 
No such file or directory

   44 | #include 
      |          ^
compilation terminated.
make[2]: *** [common/CMakeFiles/gal.dir/build.make:272: 
common/CMakeFiles/gal.dir/view/wx_view_controls.cpp.obj] Error 1
make[1]: *** [CMakeFiles/Makefile2:2688: 
common/CMakeFiles/gal.dir/all] Error 2

make: *** [Makefile:146: all] Error 2
<<<<

Following are the python packages I have for python:

Pradeepa@DESKTOP-OA7GTE5 MINGW64 /i/my_projects/kicad/build/release
$ pacman -Qs python
local/mingw-w64-x86_64-python 3.8.9-2
    A high-level scripting language (mingw-w64)
local/mingw-w64-x86_64-python-numpy 1.21.0-1
    Scientific tools for Python (mingw-w64)
local/mingw-w64-x86_64-python-pillow 8.3.0-1
    Python Imaging Library (PIL) fork Python3 version (mingw-w64)
local/mingw-w64-x86_64-python-six 1.16.0-1
    Python 2 and 3 compatibility utilities (mingw-w64)
local/mingw-w64-x86_64-python2 2.7.18-1
    A high-level scripting language (mingw-w64)
local/mingw-w64-x86_64-wxPython 4.1.1-1
    A wxWidgets GUI toolkit for Python (mingw-w64)
local/python 3.9.5-1
    Next generation of the python high-level scripting language
local/scons 3.1.2-6 (base-devel)
    Extensible Python-based build utility

Best Regards,
Pradeepa Senanayake.


On Sat, Jul 3, 2021 at 1:10 PM Pradeepa Senanayake 
mailto:pradeepa@gmail.com>> wrote:


Thanks! You are right.

I had to remove the outdated wxWidgets package and clean up my
build folder.

Best Regards,
Pradeepa Senanayake.


On Sat, Jul 3, 2021 at 1:03 PM Brian Piccioni
mailto:br...@documenteddesigns.com>>
wrote:

Yes, I checked

mingw-w64-x86_64-wxmsw3.1 gets you 3.1.5


mingw64/mingw-w64-x86_64-wxmsw3.1 3.1.5-1 [installed]
    A C++ library that lets developers create applications for
Windows, Linux and UNIX (mingw-w64)

On 2021-07-02 10:51 p.m., Pradeepa Senanayake wrote:

Hello,

I'm trying to build the KiCad in MSYS2.

I get the following error,

  Could NOT find wxWidgets: Found unsuitable version "3.0.5",
but required is
  at least "3.1.5"

I cannot download the required version through the suggested
pacman -S mingw-w64-x86_64-wxWidgets command.
(https://packages.msys2.org/package/mingw-w64-x86_64-wxWidgets
<https://packages.msys2.org/package/mingw-w64-x86_64-wxWidgets>)

Do I need to build wxWidgets from the source?

Best Regards,
Pradeepa Senanayake.

___
Mailing list:https://launchpad.net/~kicad-developers  
<https://launchpad.net/~kicad-developers>
Post to :kicad-developers@lists.launchpad.net  
<mailto:kicad-developers@lists.launchpad.net>
Unsubscribe :https://launchpad.net/~kicad-developers  
<https://launchpad.net/~kicad-developers>
More help   :https://help.launchpad.net/ListHelp  
<https://help.launchpad.net/ListHelp>

___
Mailing list: https://launchpad.net/~kicad-developers
<https://launchpad.net/~kicad-developers>
Post to     : kicad-developers@lists.launchpad.net
<mailto:kicad-developers@lists.launchpad.net>
Unsubscribe : https://launchpad.net/~kicad-developers
<https://launchpad.net/~kicad-developers>
More help   : https://help.launchpad.net/ListHelp
<https://help.launchpad.net/ListHelp>


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More he

Re: [Kicad-developers] Get wxWidgets 3.1.5 package for MSYS2

[Brian Piccioni]

Yes, I checked

mingw-w64-x86_64-wxmsw3.1 gets you 3.1.5


mingw64/mingw-w64-x86_64-wxmsw3.1 3.1.5-1 [installed]
    A C++ library that lets developers create applications for Windows, 
Linux and UNIX (mingw-w64)


On 2021-07-02 10:51 p.m., Pradeepa Senanayake wrote:

Hello,

I'm trying to build the KiCad in MSYS2.

I get the following error,

  Could NOT find wxWidgets: Found unsuitable version "3.0.5", but 
required is

  at least "3.1.5"

I cannot download the required version through the suggested pacman 
-S mingw-w64-x86_64-wxWidgets command. 
(https://packages.msys2.org/package/mingw-w64-x86_64-wxWidgets 
)


Do I need to build wxWidgets from the source?

Best Regards,
Pradeepa Senanayake.

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Error loading drawing sheet.

[Brian Piccioni]

Hello

Having put a great deal of work into a design and layout I find myself
with "Error loading drawing sheet" when I load the schematic. I have
tried all means to fix this. At one point I deleted the contents of the
schematic and created a new (empty) one and that reports "Error loading
drawing sheet" when created suggesting this is somehow related to the
project. Here is the contents of the Kicad created schematic (5.99
latest nightly) which causes the error.

When I create an entirely new project I do not get this error when
creating a new sheet


(kicad_sch (version 20210621) (generator eeschema)

  (uuid 5081e04a-a8b1-4256-8df1-1e019c9c003e)

  (paper "B")

  (lib_symbols
  )


  (sheet_instances
    (path "/" (page "1"))
  )
)


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] MSYS2 Could NOT find GLEW (missing: GLEW_LIBRARY)

[Brian Piccioni]

Ah.

Perhaps it would be useful to throw up a dialog to the effect that that 
the schematic should be updated?


It still says

PCB and schematic successfully reannotated

In the dialog.


On 2021-06-28 11:29 a.m., Wayne Stambaugh wrote:

The reannotation dialog update schematic option because it was removed
because it could leave schematics in an undefined state under certain
conditions.  See commit 54e18f6b1f4c2199f8748fff82198f86522bef83 and the
related issue for details.

Wayne

On 6/28/21 9:51 AM, Brian Piccioni wrote:

Hello

I have observed that Geographical Reannotation (my contribution) no
longer seems to update the schematic. Manual "Update Schematic from PCB"
seems to work so I assume there has been a modification to the Kiway
commands. In order to track this down I need to set up build on msys2.

I have followed the instructions at
https://dev-docs.kicad.org/en/build/windows-msys2/. In addition I had to

pacman -S cmake
pacman -S gcc.

cmake fails with Could NOT find GLEW (missing: GLEW_LIBRARY)

Glew is installed as per the instructions.

Any suggestions?

Brian


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] MSYS2 Could NOT find GLEW (missing: GLEW_LIBRARY)

[Brian Piccioni]

That was probably it!

I get much farther now. It stopped at

CMake Error at 
C:/msys64/mingw64/share/cmake-3.20/Modules/FindPackageHandleStandardArgs.cmake:230 
(message):
  Could NOT find wxWidgets: Found unsuitable version "3.0.5", but 
required is

  at least "3.1.5" (found
-LC:/msys64/mingw64/lib;;;-pipe;-Wl,--dynamicbase,--high-entropy-va,--nxcompat,--default-image-base-high;-Wl,--subsystem,windows;-mwindows;-lwx_mswu_gl-3.0;-lwx_mswu_aui-3.0;-lwx_mswu_adv-3.0;-lwx_mswu_html-3.0;-lwx_mswu_core-3.0;-lwx_baseu_net-3.0;-lwx_baseu-3.0;-lwx_mswu_propgrid-3.0;-lwx_baseu_xml-3.0;-lwx_mswu_stc-3.0)

Because it found 3.0.5 (even though 3.1.5 was installed) so I ran

 pacman -R mingw-w64-x86_64-wxWidgets

and it went through.


Thanks everybody!



On 2021-06-28 11:00 a.m., Nick Østergaard wrote:
Brian,  think that is because you started the msys shell instead of 
one of the mingw64 one.


On Mon, 28 Jun 2021 at 16:46, jp charras <mailto:jp.char...@wanadoo.fr>> wrote:



    Le 28/06/2021 à 16:14, Brian Piccioni a écrit :
> JP
>
> Thanks for the quick reply
>
> bjpic@LAPTOP-70Q5CT1Q MSYS ~/kicad-source/build/release~
> $ find /mingw64/ -name *glew*
> /mingw64/bin/glew32.dll
> /mingw64/bin/glewinfo.exe
> /mingw64/bin/libvtkglew-8.2.dll
> /mingw64/include/GL/glew.h
> /mingw64/include/GL/wglew.h
> /mingw64/include/OGRE/RenderSystems/GL/GL/glew.h
> /mingw64/include/OGRE/RenderSystems/GL/GL/wglew.h
> /mingw64/include/vtk-8.2/vtkglew
> /mingw64/include/vtk-8.2/vtkglew/include/GL/glew.h
> /mingw64/include/vtk-8.2/vtkglew/include/GL/vtk_glew_mangle.h
> /mingw64/include/vtk-8.2/vtkglew/include/GL/wglew.h
> /mingw64/include/vtk-8.2/vtk_glew.h
> /mingw64/lib/cmake/glew
> /mingw64/lib/cmake/glew/glew-config.cmake
> /mingw64/lib/cmake/glew/glew-targets-release.cmake
> /mingw64/lib/cmake/glew/glew-targets.cmake
> /mingw64/lib/cmake/vtk-8.2/Modules/vtkglew.cmake
> /mingw64/lib/libglew32.a
> /mingw64/lib/libglew32.dll.a
> /mingw64/lib/libvtkglew-8.2.dll.a
> /mingw64/lib/pkgconfig/glew.pc
> /mingw64/share/licenses/glew
>
> bjpic@LAPTOP-70Q5CT1Q MSYS ~/kicad-source/build/release~
> $ pacman -Ss glew
> mingw32/mingw-w64-i686-glew 2.2.0-2
>     GLEW, The OpenGL Extension Wrangler Library (mingw-w64)
> mingw64/mingw-w64-x86_64-glew 2.2.0-2 [installed]
>     GLEW, The OpenGL Extension Wrangler Library (mingw-w64)
> ucrt64/mingw-w64-ucrt-x86_64-glew 2.2.0-2
>     GLEW, The OpenGL Extension Wrangler Library (mingw-w64)
> clang64/mingw-w64-clang-x86_64-glew 2.2.0-2
>     GLEW, The OpenGL Extension Wrangler Library (mingw-w64)
>
> bjpic@LAPTOP-70Q5CT1Q MSYS ~/kicad-source/build/release~
>
>

This is similar to what I see on my computer (but I have less files).

GLEW_LIBRARY should be found by cmake.

You can try the brute force (that helped me in some cases):

invoke cmake with the option:

-DGLEW_LIBRARY=/d/mingw/mingw64/lib

(expecting your mingw path is /d/mingw) to force the GLEW_LIBRARY
path.


-- 
Jean-Pierre CHARRAS



___
Mailing list: https://launchpad.net/~kicad-developers
<https://launchpad.net/~kicad-developers>
Post to     : kicad-developers@lists.launchpad.net
<mailto:kicad-developers@lists.launchpad.net>
Unsubscribe : https://launchpad.net/~kicad-developers
<https://launchpad.net/~kicad-developers>
More help   : https://help.launchpad.net/ListHelp
<https://help.launchpad.net/ListHelp>


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] MSYS2 Could NOT find GLEW (missing: GLEW_LIBRARY)

[Brian Piccioni]

JP

Thanks for the quick reply

bjpic@LAPTOP-70Q5CT1Q MSYS ~/kicad-source/build/release~
$ find /mingw64/ -name *glew*
/mingw64/bin/glew32.dll
/mingw64/bin/glewinfo.exe
/mingw64/bin/libvtkglew-8.2.dll
/mingw64/include/GL/glew.h
/mingw64/include/GL/wglew.h
/mingw64/include/OGRE/RenderSystems/GL/GL/glew.h
/mingw64/include/OGRE/RenderSystems/GL/GL/wglew.h
/mingw64/include/vtk-8.2/vtkglew
/mingw64/include/vtk-8.2/vtkglew/include/GL/glew.h
/mingw64/include/vtk-8.2/vtkglew/include/GL/vtk_glew_mangle.h
/mingw64/include/vtk-8.2/vtkglew/include/GL/wglew.h
/mingw64/include/vtk-8.2/vtk_glew.h
/mingw64/lib/cmake/glew
/mingw64/lib/cmake/glew/glew-config.cmake
/mingw64/lib/cmake/glew/glew-targets-release.cmake
/mingw64/lib/cmake/glew/glew-targets.cmake
/mingw64/lib/cmake/vtk-8.2/Modules/vtkglew.cmake
/mingw64/lib/libglew32.a
/mingw64/lib/libglew32.dll.a
/mingw64/lib/libvtkglew-8.2.dll.a
/mingw64/lib/pkgconfig/glew.pc
/mingw64/share/licenses/glew

bjpic@LAPTOP-70Q5CT1Q MSYS ~/kicad-source/build/release~
$ pacman -Ss glew
mingw32/mingw-w64-i686-glew 2.2.0-2
    GLEW, The OpenGL Extension Wrangler Library (mingw-w64)
mingw64/mingw-w64-x86_64-glew 2.2.0-2 [installed]
    GLEW, The OpenGL Extension Wrangler Library (mingw-w64)
ucrt64/mingw-w64-ucrt-x86_64-glew 2.2.0-2
    GLEW, The OpenGL Extension Wrangler Library (mingw-w64)
clang64/mingw-w64-clang-x86_64-glew 2.2.0-2
    GLEW, The OpenGL Extension Wrangler Library (mingw-w64)

bjpic@LAPTOP-70Q5CT1Q MSYS ~/kicad-source/build/release~

On 2021-06-28 10:10 a.m., jp charras wrote:


Le 28/06/2021 à 15:51, Brian Piccioni a écrit :

Hello

I have observed that Geographical Reannotation (my contribution) no 
longer seems to update the schematic. Manual "Update Schematic from 
PCB" seems to work so I assume there has been a modification to the 
Kiway commands. In order to track this down I need to set up build on 
msys2.


I have followed the instructions at 
https://dev-docs.kicad.org/en/build/windows-msys2/. In addition I had to


pacman -S cmake
pacman -S gcc.

cmake fails with Could NOT find GLEW (missing: GLEW_LIBRARY)

Glew is installed as per the instructions.

Any suggestions?

Brian


What the command "find /mingw64/ -name *glew*" find?

What the command "pacman -Ss glew" says.



--


Jean-Pierre CHARRAS


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] MSYS2 Could NOT find GLEW (missing: GLEW_LIBRARY)

[Brian Piccioni]

Hello

I have observed that Geographical Reannotation (my contribution) no 
longer seems to update the schematic. Manual "Update Schematic from PCB" 
seems to work so I assume there has been a modification to the Kiway 
commands. In order to track this down I need to set up build on msys2.


I have followed the instructions at 
https://dev-docs.kicad.org/en/build/windows-msys2/. In addition I had to


pacman -S cmake
pacman -S gcc.

cmake fails with Could NOT find GLEW (missing: GLEW_LIBRARY)

Glew is installed as per the instructions.

Any suggestions?

Brian


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] 5.99.0-7573-ge07848d887 Warning: Missing ngspice + problems seting up a working development environment

[Brian Piccioni]

If you are just going to use Kicad and not build it from scratch, you 
are better off downloading the installer or one of the nightlies 
(https://kicad-downloads.s3.cern.ch/index.html?prefix=windows/nightly/ 
at the bottom of the list) and running that installer. It will install 
in a few minutes and set everything up for you.



On 2020-12-18 6:00 a.m., Stefan Auracher wrote:

I started KiCad from within msys like
/d/proj/msys_mingw/KiCad_git_repo/kicad/build/release/kicad/kicad.exe

And within this build tree in
D:\proj\msys_mingw\KiCad_git_repo\kicad\build\release

I don't have the directory structure as in an regular KiCad installation
like C:\auracher\pgr\eda\KiCad\kicad-5.1.6_1-x86_64\KiCad with

the subdirectories bin lib share ssl. So there is no directory
kicad/lib/ngspice/


Sorry I am a beginner in this. I Think I am missing the installation
steps from the build tree to the real independant installation of KiCad
outside of msys/mingw

I would expect that this should be collected to
D:\proj\msys_mingw\KiCad_git_repo\kicad\out. But also ther are no
subdirectorys bin lib share ssl. Do I need another

make target?


How can I do that. Or what other possibilities do I have to work with
the KiCad Code ?

Or is it a silly idea to work on windows. Is it easier on Linux?


Thanks for any help


Besides this I have a second problem.

On Windows 10 I installed Microsoft Visual Studio C++ 2019 to get an IDE
for the kiCad Source

Also I compiled the vcpg packages with

.\vcpkg install boost
.\vcpkg install cairo
.\vcpkg install curl
.\vcpkg install glew
.\vcpkg install gettext
.\vcpkg install glm
.\vcpkg install icu
.\vcpkg install ngspice
.\vcpkg install opencascade
.\vcpkg install opengl
.\vcpkg install openssl
.\vcpkg install python3
.\vcpkg install wxwidgets
.\vcpkg install zlib

as desribed in
https://docs.kicad.org/doxygen/md_Documentation_development_compiling.html 



and did the other steps documented there.

This all worked very well as described in the above kiCad Docu.


After starting Visual Studio 2019 I tried to build the project via
CMake. I opened:

D:\proj\msys_mingw\KiCad_git_repo\kicad\CmakeLists.txt

I had to modify the file:

D:\proj\msys_mingw\KiCad_git_repo\kicd\CMakeLists.txt

I inserted at the top


set( GLEW_INCLUDE_DIR
"/d/proj/msys_mingw/vcpkg_repo/vcpkg/packages/glew_x86-windows/include/" 
)

set( GLEW_LIBRARY
"/d/proj/msys_mingw/vcpkg_repo/vcpkg/packages/glew_x86-windows/lib" )

set ( GLM_INCLUDE_DIR
"/d/proj/msys_mingw/vcpkg_repo/vcpkg/packages/glm_x86-windows/include" )
set ( GLM_VERSION "0.9.9.8" )

set ( ZLIB_LIBRARY
"/d/proj/msys_mingw/vcpkg_repo/vcpkg/packages/zlib_x86-windows/lib" )
set ( ZLIB_INCLUDE_DIR
"/d/proj/msys_mingw/vcpkg_repo/vcpkg/packages/zlib_x86-windows/include")

set ( CURL_LIBRARY
"/d/proj/msys_mingw/vcpkg_repo/vcpkg/packages/curl_x86-windows/lib" )
set ( CURL_INCLUDE_DIR
"/d/proj/msys_mingw/vcpkg_repo/vcpkg/packages/curl_x86-windows/include")

set ( CAIRO_LIBRARIES
"/d/proj/msys_mingw/vcpkg_repo/vcpkg/packages/cairo_x86-windows/lib")
set ( CAIRO_INCLUDE_DIR
"/d/proj/msys_mingw/vcpkg_repo/vcpkg/packages/cairo_x86-windows/include")
set ( CAIRO_RELEASE "1.16.0" )

set( PKG_CONFIG_EXECUTABLE "/c/msys64/mingw64/bin/pkgconf.exe" )


This eliminated some errors


But I still have the following problem

1> [CMake] -- KiCad install dir:
(Standard)>

1> [CMake] -- Check for installed GLEW -- found
1> [CMake] -- Check for installed ZLIB -- found
1> [CMake] -- Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE)
1> [CMake] CMake Error at CMakeModules/FindCairo.cmake:145 (file):
1> [CMake]   file failed to open for reading (No such file or directory):
1> [CMake]
1> [CMake]
/d/proj/msys_mingw/vcpkg_repo/vcpkg/packages/cairo_x86-windows/include/cairo-version.h 


1> [CMake] Call Stack (most recent call first):

...


many thanks for teh patience


Stefan


On 12/16/20 12:14 PM, Holger Vogt wrote:

Correction:

analog.com and 5 other *.cm files should reside in kicad/lib/ngspice/


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Grouped items can't be locked

[Brian Piccioni]

I am curious as to whether this is intended behavior: I can't seem to 
lock a group of components. If I lock any or all before or after 
creating the group the group acts as unlocked.


I think that locking a group is useful for example in the case of a 
board. Not my example, but imagine you have an Arduino board and you 
want to lock the board outline, connector positions, etc..


Brian


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] eeSchema sporadically switches to "User Grid"

[Brian Piccioni]

I found it in Common and reassigned it to ctl-F12 so I won't use it by 
accident. I can't see how to clear or disable a hotkey.


I think this should be a separate function under eeSchema: changing 
grids, especially to a wonky user grid just causes problems.



On 2020-10-28 11:54 a.m., Brian Piccioni wrote:


Perhaps it is, however, entering "Grid" in the hotkey search box does 
not yield Next Grid so there is no way for a user to know that 'N' 
means next grid, let alone to disable it.


I would want to disable that function as switching grids in eeSchema 
is just a way of creating problems.



On 2020-10-28 11:48 a.m., Laurence DV wrote:

Hello (and all),

I tend to do that by missing the "M" key on my keyboard and hitting 
"N" (select next grid) (fyi Shift-N for previous grid).


User-grid being the last in the list it happen a lot when routing (I 
tend to route on finest grid).


Maybe it is just that?

On 2020-10-28 11:41 a.m., Brian Piccioni wrote:

Hello

I have been having a weird problem for some time now. Every once in 
a while, eeSchema would place things off grid. I am unable to 
replicate this, it just happens.


I noticed just now that eeSchema had switched to "User Grid" of 
0.013 in (0.32 mm), which I suspect is the root of the "off grid" 
issues. I thought perhaps there was a "Set to user grid" hotkey I 
was hitting accidentally, but I cannot find one.


I have switched my User Grid to 0.05 x 0.05 and I'll see if that at 
least stops the "off grid" problem.


However, I suspect that either there is an undisclosed "Set to user 
grid" hotkey or something is overwriting the grid setting. If there 
was some way of alerting that the grid was set I might be able to 
provide replication instructions.



Brian


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] eeSchema sporadically switches to "User Grid"

[Brian Piccioni]

Perhaps it is, however, entering "Grid" in the hotkey search box does 
not yield Next Grid so there is no way for a user to know that 'N' means 
next grid, let alone to disable it.


I would want to disable that function as switching grids in eeSchema is 
just a way of creating problems.



On 2020-10-28 11:48 a.m., Laurence DV wrote:

Hello (and all),

I tend to do that by missing the "M" key on my keyboard and hitting 
"N" (select next grid) (fyi Shift-N for previous grid).


User-grid being the last in the list it happen a lot when routing (I 
tend to route on finest grid).


Maybe it is just that?

On 2020-10-28 11:41 a.m., Brian Piccioni wrote:

Hello

I have been having a weird problem for some time now. Every once in a 
while, eeSchema would place things off grid. I am unable to replicate 
this, it just happens.


I noticed just now that eeSchema had switched to "User Grid" of 0.013 
in (0.32 mm), which I suspect is the root of the "off grid" issues. I 
thought perhaps there was a "Set to user grid" hotkey I was hitting 
accidentally, but I cannot find one.


I have switched my User Grid to 0.05 x 0.05 and I'll see if that at 
least stops the "off grid" problem.


However, I suspect that either there is an undisclosed "Set to user 
grid" hotkey or something is overwriting the grid setting. If there 
was some way of alerting that the grid was set I might be able to 
provide replication instructions.



Brian


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] eeSchema sporadically switches to "User Grid"

[Brian Piccioni]

Hello

I have been having a weird problem for some time now. Every once in a 
while, eeSchema would place things off grid. I am unable to replicate 
this, it just happens.


I noticed just now that eeSchema had switched to "User Grid" of 0.013 in 
(0.32 mm), which I suspect is the root of the "off grid" issues. I 
thought perhaps there was a "Set to user grid" hotkey I was hitting 
accidentally, but I cannot find one.


I have switched my User Grid to 0.05 x 0.05 and I'll see if that at 
least stops the "off grid" problem.


However, I suspect that either there is an undisclosed "Set to user 
grid" hotkey or something is overwriting the grid setting. If there was 
some way of alerting that the grid was set I might be able to provide 
replication instructions.



Brian


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Buses - what am I doing wrong

[Brian Piccioni]

Hello

I thought I had figured out bus aliases, etc. but likely not.

I have a bus alias {SD_SIGNALS}. I run a bus and put a label 
{SD_SIGNALS} on the bus. It is blue.


I can unfold my signals from the bus. I run ERC and it flags my unfolded 
signals "Net is graphically connected to bus but is not a bus member"


I notice the label {SD_SIGNALS} has turned from blue to black.

If I try unfold from the bus I get the error "Bus has no members".

If I move the label away and then back on to the bus it turns blue again 
and I can unfold signals. Unfortunately, if I run ERC I get the same errors.


Rinse and repeat.

What am I doing wrong?

Application: Eeschema



Version: (5.99.0-6550-gd6f91c810f), release build

Libraries:
    wxWidgets 3.0.5
    libcurl/7.71.0 OpenSSL/1.1.1g (Schannel) zlib/1.2.11 brotli/1.0.7 
libidn2/2.3.0 libpsl/0.21.0 (+libidn2/2.3.0) libssh2/1.9.0 nghttp2/1.41.0


Platform: Windows 10 (build 18363), 64-bit edition, 64 bit, Little 
endian, wxMSW


Build Info:
    Date: Oct 25 2020 10:10:16
    wxWidgets: 3.0.5 (wchar_t,wx containers,compatible with 2.8)
    Boost: 1.73.0
    OCE: 6.9.1
    Curl: 7.71.0
    ngspice: 32
    Compiler: GCC 10.2.0 with C++ ABI 1014

Build settings:
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_PYTHON3=OFF
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_SPICE=ON

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] V6 Usability suggestion

[Brian Piccioni]

I did not know that. That would be useful.

I agree with JP's suggestion: any form of ordering would be helpful 
since there are so many options.


Brian

On 2020-10-21 12:53 p.m., Jeff Young wrote:

Hi Brian,

While it doesn’t directly address your suggestion, did you discover that you 
can also edit the severities by right-clicking on an actual DRC error (in the 
DRC dialog)?

Cheers,
Jeff.


On 21 Oct 2020, at 17:44, Brian Piccioni  wrote:

Hello

The power new DRC is great. I believe it would be more usable if the

Board Setup -> Design Rules -> Violation Severity table

would be in alphabetical order.

Until the table has been configured there are a profligacy of DRC errors, many 
of which are novel. The errors have names but since the table is not in 
alphabetical order, finding them in the table to adjust (i.e. error to warning) 
is unnecessarily complicated.

A minor thing, obviously.



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] V6 Usability suggestion

[Brian Piccioni]

Hello

The power new DRC is great. I believe it would be more usable if the

Board Setup -> Design Rules -> Violation Severity table

would be in alphabetical order.

Until the table has been configured there are a profligacy of DRC 
errors, many of which are novel. The errors have names but since the 
table is not in alphabetical order, finding them in the table to adjust 
(i.e. error to warning) is unnecessarily complicated.


A minor thing, obviously.



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Can't see references - V5.99 what am I doing wrong?

[Brian Piccioni]

I just find it unclear at the moment and thought I'd mention it.

As Jon says things will change before release so I'll wait till then.


On 2020-10-14 11:12 a.m., Ruth Ivimey-Cook wrote:


I sympathise with the issue. How about the 'hidden' state is like the 
current hidden icon but about 1/2 the current height, so almost a 
horizontal line?


Ruth


On 14/10/2020 16:05, Brian Piccioni wrote:


Perhaps eye / no eye?

The thing is, the difference between on and off is eyelashes + 
contrast. Depending on the display that can be pretty hard to 
differentiate.



On 2020-10-14 11:00 a.m., Jon Evans wrote:
> FWIW, I find the "open eye", "closed eye" a bit hard to 
differentiate. I'd prefer something like an X or check mark.


The icons are being tweaked before release.  The problem with the 
checkboxes is that they look different on every platform and it's 
not as clear that they are visibility controls -- normally 
checkboxes are for enabling/disabling things.



On Wed, Oct 14, 2020 at 10:57 AM Ian McInerney 
mailto:ian.s.mciner...@ieee.org>> wrote:




On Wed, Oct 14, 2020 at 3:52 PM Jon Evans mailto:j...@craftyjon.com>> wrote:

"Footprint Text" off turns off all footprint text, including
references and values.  This isn't new behavior but I worry
that the simplified objects panel has made it more confusing
than it was in 5.1


This only turns it off when viewing the board, correct? It will
still be included in the plot output if the actual text is
marked "Show" in the dialog.


Yes

We could have the Footprint Text control act as a visual
override for the Values and References controls to make this
more clear...


Can we link these controls so that changing the "Footprint Text"
visibility changes the "references" and "values" visibility, but
those two can still be changed separately? (e.g. to allow
showing only the references text from footprints).


That's what I was proposing

-Jon


___
Mailing list:https://launchpad.net/~kicad-developers
Post to :kicad-developers@lists.launchpad.net
Unsubscribe :https://launchpad.net/~kicad-developers
More help   :https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Can't see references - V5.99 what am I doing wrong?

[Brian Piccioni]

Perhaps eye / no eye?

The thing is, the difference between on and off is eyelashes + contrast. 
Depending on the display that can be pretty hard to differentiate.



On 2020-10-14 11:00 a.m., Jon Evans wrote:
> FWIW, I find the "open eye", "closed eye" a bit hard to 
differentiate. I'd prefer something like an X or check mark.


The icons are being tweaked before release.  The problem with the 
checkboxes is that they look different on every platform and it's not 
as clear that they are visibility controls -- normally checkboxes are 
for enabling/disabling things.



On Wed, Oct 14, 2020 at 10:57 AM Ian McInerney 
mailto:ian.s.mciner...@ieee.org>> wrote:




On Wed, Oct 14, 2020 at 3:52 PM Jon Evans mailto:j...@craftyjon.com>> wrote:

"Footprint Text" off turns off all footprint text, including
references and values.  This isn't new behavior but I worry
that the simplified objects panel has made it more confusing
than it was in 5.1


This only turns it off when viewing the board, correct? It will
still be included in the plot output if the actual text is marked
"Show" in the dialog.


Yes

We could have the Footprint Text control act as a visual
override for the Values and References controls to make this
more clear...


Can we link these controls so that changing the "Footprint Text"
visibility changes the "references" and "values" visibility, but
those two can still be changed separately? (e.g. to allow showing
only the references text from footprints).


That's what I was proposing

-Jon
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Can't see references - V5.99 what am I doing wrong?

[Brian Piccioni]

I think that would make a lot of sense from a usability perspective, or 
grey out related options (reference, value) when set.


On 2020-10-14 10:57 a.m., Ian McInerney wrote:



On Wed, Oct 14, 2020 at 3:52 PM Jon Evans <mailto:j...@craftyjon.com>> wrote:


"Footprint Text" off turns off all footprint text, including
references and values.  This isn't new behavior but I worry that
the simplified objects panel has made it more confusing than it
was in 5.1


This only turns it off when viewing the board, correct? It will still 
be included in the plot output if the actual text is marked "Show" in 
the dialog.


We could have the Footprint Text control act as a visual override
for the Values and References controls to make this more clear...


Can we link these controls so that changing the "Footprint Text" 
visibility changes the "references" and "values" visibility, but those 
two can still be changed separately? (e.g. to allow showing only the 
references text from footprints).


-Ian


On Wed, Oct 14, 2020 at 10:49 AM Brian Piccioni
mailto:br...@documenteddesigns.com>>
wrote:

I am working on a PCB with PCBNew from a couple days ago.

I can't see the references. Silkscreen is on and the little
eye is open but the references don't show up.

If I edit a reference it is on the right layer and show is
clicked.


What am I doing wrong?

___
Mailing list: https://launchpad.net/~kicad-developers
<https://launchpad.net/~kicad-developers>
Post to     : kicad-developers@lists.launchpad.net
<mailto:kicad-developers@lists.launchpad.net>
Unsubscribe : https://launchpad.net/~kicad-developers
<https://launchpad.net/~kicad-developers>
More help   : https://help.launchpad.net/ListHelp
<https://help.launchpad.net/ListHelp>

___
Mailing list: https://launchpad.net/~kicad-developers
<https://launchpad.net/~kicad-developers>
Post to     : kicad-developers@lists.launchpad.net
<mailto:kicad-developers@lists.launchpad.net>
Unsubscribe : https://launchpad.net/~kicad-developers
<https://launchpad.net/~kicad-developers>
More help   : https://help.launchpad.net/ListHelp
<https://help.launchpad.net/ListHelp>

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Can't see references - V5.99 what am I doing wrong?

[Brian Piccioni]

Thanks! Sorry about that. You never know with a nightly. I am using the 
latest distributions as a product tester.


FWIW, I find the "open eye", "closed eye" a bit hard to differentiate. 
I'd prefer something like an X or check mark.




On 2020-10-14 10:51 a.m., Jon Evans wrote:
"Footprint Text" off turns off all footprint text, including 
references and values.  This isn't new behavior but I worry that the 
simplified objects panel has made it more confusing than it was in 5.1


We could have the Footprint Text control act as a visual override for 
the Values and References controls to make this more clear...


On Wed, Oct 14, 2020 at 10:49 AM Brian Piccioni 
mailto:br...@documenteddesigns.com>> wrote:


I am working on a PCB with PCBNew from a couple days ago.

I can't see the references. Silkscreen is on and the little eye is
open but the references don't show up.

If I edit a reference it is on the right layer and show is clicked.


What am I doing wrong?

___
Mailing list: https://launchpad.net/~kicad-developers
<https://launchpad.net/~kicad-developers>
Post to     : kicad-developers@lists.launchpad.net
<mailto:kicad-developers@lists.launchpad.net>
Unsubscribe : https://launchpad.net/~kicad-developers
<https://launchpad.net/~kicad-developers>
More help   : https://help.launchpad.net/ListHelp
<https://help.launchpad.net/ListHelp>

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Can't see references - V5.99 what am I doing wrong?

[Brian Piccioni]

I am working on a PCB with PCBNew from a couple days ago.

I can't see the references. Silkscreen is on and the little eye is open 
but the references don't show up.


If I edit a reference it is on the right layer and show is clicked.


What am I doing wrong?

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Problems with windows installers?

[Brian Piccioni]

Yes, that was the problem. When I clicked that button nothing happened.

So I disabled the check, installed Kicad, and re-enabled it.


On 2020-10-13 8:48 a.m., Mark Roszko wrote:

You should be able to click a button to ignore the warning.

On Mon, Oct 12, 2020 at 8:54 PM Brian Piccioni 
mailto:br...@documenteddesigns.com>> wrote:


That makes sense. I tried installing the same file which installed
perfectly this morning and it hung. I'll wait a few days and try
again ...

On 2020-10-12 6:10 p.m., Mark Roszko wrote:
> It's just the usual Microsoft Smartscreen filter acting up.
Heuristics
> are flagging it. There's nothing that can be done about it until
their
> heuristics recalculate.



--
Mark
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Problems with windows installers?

[Brian Piccioni]

That makes sense. I tried installing the same file which installed 
perfectly this morning and it hung. I'll wait a few days and try again ...


On 2020-10-12 6:10 p.m., Mark Roszko wrote:
It's just the usual Microsoft Smartscreen filter acting up. Heuristics 
are flagging it. There's nothing that can be done about it until their 
heuristics recalculate.


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Problems with windows installers?

[Brian Piccioni]

Windows 10 Home
V1909
OS Build 18363.1082

As noted below My prior version kicad-r18012.7f1c376128-x86_64-lite.exe 
seems to work


I have not tested all versions between


On 2020-10-12 4:20 p.m., Nick Østergaard wrote:

What system are you installing it on?

Does any older nightly builds work?

On Mon, 12 Oct 2020 at 18:42, Brian Piccioni 
mailto:br...@documenteddesigns.com>> wrote:


Hello

I downloaded kicad-r18079.88102bca46-x86_64.exe and
kicad-r18079.88102bca46-x86_64-lite.exe from
https://kicad-downloads.s3.cern.ch/index.html?prefix=windows/nightly/
<https://kicad-downloads.s3.cern.ch/index.html?prefix=windows/nightly/>

On running both throw up the Microsoft warning warning but clicking
"Install Anyway" has no effect.

My prior version kicad-r18012.7f1c376128-x86_64-lite.exe seems to
work
as expected, suggesting this may not be a Windows issue

Brian


___
Mailing list: https://launchpad.net/~kicad-developers
<https://launchpad.net/~kicad-developers>
Post to     : kicad-developers@lists.launchpad.net
<mailto:kicad-developers@lists.launchpad.net>
Unsubscribe : https://launchpad.net/~kicad-developers
<https://launchpad.net/~kicad-developers>
More help   : https://help.launchpad.net/ListHelp
<https://help.launchpad.net/ListHelp>

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Problems with windows installers?

[Brian Piccioni]

Hello

I downloaded kicad-r18079.88102bca46-x86_64.exe and 
kicad-r18079.88102bca46-x86_64-lite.exe from 
https://kicad-downloads.s3.cern.ch/index.html?prefix=windows/nightly/


On running both throw up the Microsoft warning warning but clicking 
"Install Anyway" has no effect.


My prior version kicad-r18012.7f1c376128-x86_64-lite.exe seems to work 
as expected, suggesting this may not be a Windows issue


Brian


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Pcbnew - wxWidgets Debug Alerts on startup

[Brian Piccioni]

I don't see any errors when I run a recent nightly from the Msys 
terminal Kicad or PCBNew. I do get a "Python error - 1 " but that's been 
there for a few days.


On 2020-08-18 3:20 p.m., Ian McInerney wrote:
I saw those when I opened up a windows build yesterday, but I haven't 
had time to dig into it (they appear to be windows only).


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Not a priority: building Kicad on Ubuntu on Windows (WSL)

[Brian Piccioni]

Hello

As I say, not a priority but I thought something I'd try. It might be 
useful to be able to build/run Kicad in WSL for testing. If it works it 
will mean people don't have to dual boot in order to test.


I have two issues:

1) NGSPICE not found. Unfortunately I cannot get the NGSPICE build 
script referenced to work. First it complained about not having yacc and 
after installing byacc I get the error


make[2]: Leaving directory '/tmp/libngspice_so/ngspice/src/maths'
Making all in frontend
make[2]: Entering directory '/tmp/libngspice_so/ngspice/src/frontend'
  YACC parse-bison.c
byacc: e - line 32 of 
"/tmp/libngspice_so/ngspice/src/frontend/parse-bison.y", syntax error

%name-prefix "PP"
^
Makefile:761: recipe for target 'parse-bison.c' failed
make[2]: *** [parse-bison.c] Error 1
make[2]: Leaving directory '/tmp/libngspice_so/ngspice/src/frontend'
Makefile:1414: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/tmp/libngspice_so/ngspice/src'
Makefile:494: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1
*** Build failed ***

so I just set -DKICAD_SPICE=OFF.


2) The make file seems to think the environment is MSYS2. I get this

-- Check for installed GLEW -- found
-- Boost version: 1.65.1
    CMake Error at 
/mnt/c/msys64/mingw64/lib/oce/OCE-libraries.cmake:229 (message):

      The imported target "TKernel" references the file

 "C:/msys64/mingw64/lib/libTKernel.dll.a"

    but this file does not exist.


I assume this is due to the way the make script determines if it is 
Linux or Windows.



If I can get this working I'll document the needed commands.

Thanks


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] ERC Rules Options missing?

[Brian Piccioni]

Hello

I'm running my built Version: (5.99.0-2620-g2af4bd02a), release build.

ERC Rules options seems to have disappeared. It is no longer part of the 
ERC dialog (where I think it should be) and I can't find it in preferences.


Any suggestions?

Brian


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Master won't build

[Brian Piccioni]

FYI I pulled master origin a few hours ago and it fails with

[ 98%] Linking CXX shared module _pcbnew.kiface
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: 
CMakeFiles/pcbnew_kiface.dir/objects.a(drc_rule_parser.cpp.obj):drc_rule_parser.cpp:(.text+0x7308): 
undefined reference to 
`DSNLEXER::findToken(std::__cxx11::basic_stringstd::char_traits, std::allocator > const&)'

collect2.exe: error: ld returned 1 exit status
make[2]: *** [pcbnew/CMakeFiles/pcbnew_kiface.dir/build.make:635: 
pcbnew/_pcbnew.kiface] Error 1
make[1]: *** [CMakeFiles/Makefile2:3402: 
pcbnew/CMakeFiles/pcbnew_kiface.dir/all] Error 2

make: *** [Makefile:161: all] Error 2

I'm on Windows 10, MSYS,

I wiped the release directory and re-ran the script so it isn't likely a 
cache issue.



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Users grid - x, y

[Brian Piccioni]

Hello

While working on geographic annotation I note that it is possible to set 
different x and y for the user grid but the choice menu only shows one 
(I think the x).


I also notice that in footprint_preview_panel.cpp it only takes one of 
the values.


It seems the user grid setting menu is out of sync with the implementation.

Am I missing something?

Brian


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Any chance I can get feedback on my merge request?

[Brian Piccioni]

Jon

Thank you for the feedback. I thought WIP meant in process waiting for 
feedback. I was waiting for feedback from Eeli but none was forthcoming.


There was some back and forth about the UI but it has been functional 
for about 5 months.


I'll remove the WIP.

Thanks again. I look forward to comments.

Brian

On 2020-08-01 9:02 p.m., Jon Evans wrote:

Hi Brian,

This merge request is still marked as WIP, which is probably why it's
been flying under the radar.  If you consider it complete and ready
for a review, please remove the WIP status from the title.  From the
comments, it wasn't clear if you were still working on changes to the
UI based on your discussion with Eeli.

Best,
Jon

On Sat, Aug 1, 2020 at 8:54 PM Brian Piccioni
 wrote:

This is regarding Geographic Reannotation 
https://gitlab.com/kicad/code/kicad/-/merge_requests/108

I don't understand the complete lack of interest/feedback. Its more or less 
been hanging for about 4 months.

I try and keep it up to date with master, but it would be nice to have it 
accepted or get the feedback needed to have it accepted.

Thanks.

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Any chance I can get feedback on my merge request?

[Brian Piccioni]

This is regarding Geographic Reannotation 
https://gitlab.com/kicad/code/kicad/-/merge_requests/108


I don't understand the complete lack of interest/feedback. Its more or 
less been hanging for about 4 months.


I try and keep it up to date with master, but it would be nice to have 
it accepted or get the feedback needed to have it accepted.


Thanks. 



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Profligacy of messages/ link errors building 5.99 on Windows 10/Msys

[Brian Piccioni]

Thanks for the headsup. Compile is much cleaner now.

FYI I seem to recall the issue had an indirect relationship to Python 
and I note Msys upgraded Python when I ran Pacman -Syuu so perhaps that 
had something to do with it working?



On 2020-07-25 8:25 a.m., Wayne Stambaugh wrote:

As of commit 33af2d9a, debug builds started working agian even though I
didn't see anything that would have fixed this issue.

The msys2 project just released gcc 10.2 which gets rid of all of the
warning messages so you should probably upgrade when you get a chance.

On 7/24/2020 8:05 PM, Brian Piccioni wrote:

FWIW I realized that I didn't need a debug version of the code in order
to resolve my merge issues so I built a Release version with no troubles.

In a way I'm glad I reported this because it could have been a problem
later on and at least the people who know what SWIG is and can do
something about it are aware.

On 2020-07-24 5:00 p.m., Wayne Stambaugh wrote:

It's probably too late to tell swig not to wrap everything.  We should
have only wrapped the objects that we wanted to expose to scripting
langauages but that is a lot more work.  That being said, swig only
wraps what we tell it to wrap so if we don't want something wrapped then
we need to let swig know.  If you include a new header an existing
header that gets pull in than you have to tell swig to exclude it.

On 7/24/2020 4:11 PM, Jon Evans wrote:

I am not sure the exact nature of this error, but it seems like somehow
SWIG is failing to wrap some data structures.

Since we are planning on the new Python API not just exposing all
internals, maybe instead of trying to debug SWIG we should just start
restricting it to not wrap everything?


On Fri, Jul 24, 2020 at 4:04 PM Wayne Stambaugh mailto:stambau...@gmail.com>> wrote:

  I filed a issue[1] for this.  Just to add insult to injury,
clang wont
  work because something changed in libcontext that causes it to
choke.
  The hits just keep on coming.

  [1]: https://gitlab.com/kicad/code/kicad/-/issues/4967

  On 7/22/2020 6:39 PM, Jon Evans wrote:
  > If it is the commit I made that Ian points out, I won't be
able to
  debug
  > it very effectively.  I don't have a msys2 build environment,
and it
  > seems to work on all the platforms I do have.
  >
  > On Wed, Jul 22, 2020 at 6:38 PM Wayne Stambaugh
  mailto:stambau...@gmail.com>
  > <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>>>
wrote:
  >
  >     No problem.  I'll file a issue report as soon as I determine
  the guilty
  >     commit.
  >
  >     On 7/22/2020 6:34 PM, Ian McInerney wrote:
  >     > It was committed on July 3rd. I am not sure which commit is
  100 behind
  >     > the current head though, and I really don't want to kill my
  build
  >     > directory by switching that far back to find out.
  >     >
  >     > -Ian
  >     >
  >     > On Wed, Jul 22, 2020 at 11:27 PM Wayne Stambaugh
  >     mailto:stambau...@gmail.com>
  <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>>
  >     > <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>
  <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>>>>
wrote:
  >     >
  >     >     I'm running `git bisect` now from HEAD~100.  Is it
further
  >     back that
  >     >     that?  Given that mingw debug builds are painfully
slow,
  it's
  >     going to
  >     >     take a while.
  >     >
  >     >     On 7/22/2020 6:17 PM, Ian McInerney wrote:
  >     >     > Try going right before
  >     c0aa6965de7b83ca78dd5c4d700b50a2a03a34e4 first.
  >     >     > The errors that Brian showed at the beginning of the
  thread
  >     mention
  >     >     > NETCLASS* and shared_ptr stuff, and it looks like
the last
  >     commit that
  >     >     > touched those Swig parts was from Jon on June 30th
  which moved
  >     >     that from
  >     >     > pcbnew to the common Swig directory. I am not sure
how
  that
  >     could have
  >     >     > broken things, but I think it would be a good
commit to
  >     start with and
  >     >     > see if it is the issue.
  >     >     >
  >     >     > -Ian
  >     >     >
  >     >     > On Wed, Jul 22, 2020 at 11:10 PM Brian Piccioni
  >     >     > mailto:br...@documenteddesigns.com>
  >     <mailto:br...@documenteddesigns.com
  <mailto:br...@documenteddesigns.com>>
  >     <mailto:br...@documenteddesigns.com
  &l

Re: [Kicad-developers] Profligacy of messages/ link errors building 5.99 on Windows 10/Msys

[Brian Piccioni]

FWIW I realized that I didn't need a debug version of the code in order 
to resolve my merge issues so I built a Release version with no troubles.


In a way I'm glad I reported this because it could have been a problem 
later on and at least the people who know what SWIG is and can do 
something about it are aware.


On 2020-07-24 5:00 p.m., Wayne Stambaugh wrote:

It's probably too late to tell swig not to wrap everything.  We should
have only wrapped the objects that we wanted to expose to scripting
langauages but that is a lot more work.  That being said, swig only
wraps what we tell it to wrap so if we don't want something wrapped then
we need to let swig know.  If you include a new header an existing
header that gets pull in than you have to tell swig to exclude it.

On 7/24/2020 4:11 PM, Jon Evans wrote:

I am not sure the exact nature of this error, but it seems like somehow
SWIG is failing to wrap some data structures.

Since we are planning on the new Python API not just exposing all
internals, maybe instead of trying to debug SWIG we should just start
restricting it to not wrap everything?


On Fri, Jul 24, 2020 at 4:04 PM Wayne Stambaugh mailto:stambau...@gmail.com>> wrote:

 I filed a issue[1] for this.  Just to add insult to injury, clang wont
 work because something changed in libcontext that causes it to choke.
 The hits just keep on coming.

 [1]: https://gitlab.com/kicad/code/kicad/-/issues/4967

 On 7/22/2020 6:39 PM, Jon Evans wrote:
 > If it is the commit I made that Ian points out, I won't be able to
 debug
 > it very effectively.  I don't have a msys2 build environment, and it
 > seems to work on all the platforms I do have.
 >
 > On Wed, Jul 22, 2020 at 6:38 PM Wayne Stambaugh
 mailto:stambau...@gmail.com>
 > <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>>> wrote:
 >
 >     No problem.  I'll file a issue report as soon as I determine
 the guilty
 >     commit.
 >
 >     On 7/22/2020 6:34 PM, Ian McInerney wrote:
 >     > It was committed on July 3rd. I am not sure which commit is
 100 behind
 >     > the current head though, and I really don't want to kill my
 build
 >     > directory by switching that far back to find out.
 >     >
 >     > -Ian
 >     >
 >     > On Wed, Jul 22, 2020 at 11:27 PM Wayne Stambaugh
 >     mailto:stambau...@gmail.com>
 <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>>
 >     > <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>
 <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>>>> wrote:
 >     >
 >     >     I'm running `git bisect` now from HEAD~100.  Is it further
 >     back that
 >     >     that?  Given that mingw debug builds are painfully slow,
 it's
 >     going to
 >     >     take a while.
 >     >
 >     >     On 7/22/2020 6:17 PM, Ian McInerney wrote:
 >     >     > Try going right before
 >     c0aa6965de7b83ca78dd5c4d700b50a2a03a34e4 first.
 >     >     > The errors that Brian showed at the beginning of the
 thread
 >     mention
 >     >     > NETCLASS* and shared_ptr stuff, and it looks like the last
 >     commit that
 >     >     > touched those Swig parts was from Jon on June 30th
 which moved
 >     >     that from
 >     >     > pcbnew to the common Swig directory. I am not sure how
 that
 >     could have
     >     >     > broken things, but I think it would be a good commit to
 >     start with and
 >     >     > see if it is the issue.
 >     >     >
 >     >     > -Ian
 >     >     >
 >     >     > On Wed, Jul 22, 2020 at 11:10 PM Brian Piccioni
 >     >     > mailto:br...@documenteddesigns.com>
 >     <mailto:br...@documenteddesigns.com
 <mailto:br...@documenteddesigns.com>>
 >     <mailto:br...@documenteddesigns.com
 <mailto:br...@documenteddesigns.com>
 >     <mailto:br...@documenteddesigns.com
 <mailto:br...@documenteddesigns.com>>>
 >     >     <mailto:br...@documenteddesigns.com
 <mailto:br...@documenteddesigns.com>
 >     <mailto:br...@documenteddesigns.com
 <mailto:br...@documenteddesigns.com>>
 >     >     <mailto:br...@documenteddesigns.com
 <mailto:br...@documenteddesigns.com>
 >     <mailto:br...@documenteddesigns.com
 <mailto:br...@documenteddesigns.com>>>>> wrote:
 >     >     >
 >     >     >     Perhaps what I can try and 

Re: [Kicad-developers] Profligacy of messages/ link errors building 5.99 on Windows 10/Msys

[Brian Piccioni]

Perhaps what I can try and do is a binary search for the last "working" 
master.


I think that is within my abilities.

On 2020-07-22 6:00 p.m., Jon Evans wrote:

If you know a version that builds (you said late June worked) you can
do a git bisect against a commit from back then and eventually this
will tell you which commit changed the behavior

On Wed, Jul 22, 2020 at 5:58 PM Brian Piccioni
 wrote:

You can't imagine how happy it makes me feel to know it isn't some
stupid little thing I did.

I don't know how I can help though. I can try building a release version
to confirm.

On 2020-07-22 5:54 p.m., Wayne Stambaugh wrote:

I've been playing around with this and there is definetly something
amiss.  I don't get the build errors on release builds but I do see them
with debug builds (CMAKE_BUILD_TYPE=Debug).  Downgrading swig from
4.0.2-1 to 4.0.1-3 didn't help.  Interestingly the 5.1 branch builds
just fine so I suspect a recent change in the one of the CMake config
files is to blame.  I don't remember seeing any swig changes recently.

On 7/22/2020 9:30 AM, Brian Piccioni wrote:

Using this script

cmake -DCMAKE_BUILD_TYPE=Debug -G "MSYS Makefiles"
-DCMAKE_PREFIX_PATH=C:/msys64/mingw64
-DCMAKE_INSTALL_PREFIX=C:/msys64/mingw64
-DDEFAULT_INSTALL_PATH=C:/msys64/mingw64 -DMSYS=TRUE ../kicad

I get the same results

[ 98%] Built target qa_eeschema
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.text+0x23cd):
undefined reference to `.refptr.PyObject_GenericGetAttr'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in function
`std::invalid_argument::invalid_argument(std::invalid_argument const&)':
C:/msys64/mingw64/include/c++/10.1.0/stdexcept:174: undefined reference
to `.refptr._ZTVSt16invalid_argument'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in function
`std::_Sp_counted_deleter,
(__gnu_cxx::_Lock_policy)2>::_M_get_deleter(std::type_info const&)':
C:/msys64/mingw64/include/c++/10.1.0/bits/shared_ptr_base.h:490:
undefined reference to `typeinfo for SWIG_null_deleter'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in function
`swig::traits_from::from(KIID const&)':
C:/Users/bjpic/KicadWork/FixedFormatting/clean/debug/pcbnew/pcbnew_wrap.cxx:3929:
undefined reference to `swig::traits_from_ptr::from(KIID*, int)'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.rdata$_ZTI17SWIG_null_deleter+0x8):
undefined reference to `typeinfo name for SWIG_null_deleter'
collect2.exe: error: ld returned 1 exit status
make[2]: *** [pcbnew/CMakeFiles/pcbnew_kiface.dir/build.make:634:
pcbnew/_pcbnew.kiface] Error 1
make[1]: *** [CMakeFiles/Makefile2:3284:
pcbnew/CMakeFiles/pcbnew_kiface.dir/all] Error 2
make: *** [Makefile:161: all] Error 2

bjpic@LAPTOP-70Q5CT1Q MINGW64 ~/FixedFormatting/clean/debug

On 2020-07-22 2:39 a.m., Nick Østergaard wrote:

Did you try to use the normal makefile generator rather than the
eclipse one?

ons. 22. jul. 2020 01.37 skrev Brian Piccioni
mailto:br...@documenteddesigns.com>>:

  FWIW, I re-cloned Kicad master into an empty directory, created a
  new build directory, ran the standard build script

  cmake -DCMAKE_BUILD_TYPE=Debug \
  -G "Eclipse CDT4 - Unix Makefiles" \
  -DCMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT=TRUE \
  -DCMAKE_PREFIX_PATH=C:/msys64/mingw64 \
  -DCMAKE_INSTALL_PREFIX=C:/msys64/mingw64 \
  -DDEFAULT_INSTALL_PATH=C:/msys64/mingw64 \
  -DMSYS=TRUE \
  ../kicad

  and got the same errors

   Built target qa_eeschema
  
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
  
CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.text+0x23cd):
  undefined reference to `.refptr.PyObject_GenericGetAttr'
  
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
  CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in
  function
  `std::invalid_argument::invalid_argument(std::invalid_argument
  const&)':
  C:/msys64/mingw64/include/c++/10.1.0/stdexcept:174: undefined
  reference to `.refptr._ZTVSt16invalid_argument'
  
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
  CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in
  function `std

Re: [Kicad-developers] Profligacy of messages/ link errors building 5.99 on Windows 10/Msys

[Brian Piccioni]

You can't imagine how happy it makes me feel to know it isn't some 
stupid little thing I did.


I don't know how I can help though. I can try building a release version 
to confirm.


On 2020-07-22 5:54 p.m., Wayne Stambaugh wrote:

I've been playing around with this and there is definetly something
amiss.  I don't get the build errors on release builds but I do see them
with debug builds (CMAKE_BUILD_TYPE=Debug).  Downgrading swig from
4.0.2-1 to 4.0.1-3 didn't help.  Interestingly the 5.1 branch builds
just fine so I suspect a recent change in the one of the CMake config
files is to blame.  I don't remember seeing any swig changes recently.

On 7/22/2020 9:30 AM, Brian Piccioni wrote:

Using this script

cmake -DCMAKE_BUILD_TYPE=Debug -G "MSYS Makefiles"
-DCMAKE_PREFIX_PATH=C:/msys64/mingw64
-DCMAKE_INSTALL_PREFIX=C:/msys64/mingw64
-DDEFAULT_INSTALL_PATH=C:/msys64/mingw64 -DMSYS=TRUE ../kicad

I get the same results

[ 98%] Built target qa_eeschema
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.text+0x23cd):
undefined reference to `.refptr.PyObject_GenericGetAttr'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in function
`std::invalid_argument::invalid_argument(std::invalid_argument const&)':
C:/msys64/mingw64/include/c++/10.1.0/stdexcept:174: undefined reference
to `.refptr._ZTVSt16invalid_argument'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in function
`std::_Sp_counted_deleter,
(__gnu_cxx::_Lock_policy)2>::_M_get_deleter(std::type_info const&)':
C:/msys64/mingw64/include/c++/10.1.0/bits/shared_ptr_base.h:490:
undefined reference to `typeinfo for SWIG_null_deleter'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in function
`swig::traits_from::from(KIID const&)':
C:/Users/bjpic/KicadWork/FixedFormatting/clean/debug/pcbnew/pcbnew_wrap.cxx:3929:
undefined reference to `swig::traits_from_ptr::from(KIID*, int)'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.rdata$_ZTI17SWIG_null_deleter+0x8):
undefined reference to `typeinfo name for SWIG_null_deleter'
collect2.exe: error: ld returned 1 exit status
make[2]: *** [pcbnew/CMakeFiles/pcbnew_kiface.dir/build.make:634:
pcbnew/_pcbnew.kiface] Error 1
make[1]: *** [CMakeFiles/Makefile2:3284:
pcbnew/CMakeFiles/pcbnew_kiface.dir/all] Error 2
make: *** [Makefile:161: all] Error 2

bjpic@LAPTOP-70Q5CT1Q MINGW64 ~/FixedFormatting/clean/debug

On 2020-07-22 2:39 a.m., Nick Østergaard wrote:

Did you try to use the normal makefile generator rather than the
eclipse one?

ons. 22. jul. 2020 01.37 skrev Brian Piccioni
mailto:br...@documenteddesigns.com>>:

 FWIW, I re-cloned Kicad master into an empty directory, created a
 new build directory, ran the standard build script

 cmake -DCMAKE_BUILD_TYPE=Debug \
 -G "Eclipse CDT4 - Unix Makefiles" \
 -DCMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT=TRUE \
 -DCMAKE_PREFIX_PATH=C:/msys64/mingw64 \
 -DCMAKE_INSTALL_PREFIX=C:/msys64/mingw64 \
 -DDEFAULT_INSTALL_PATH=C:/msys64/mingw64 \
 -DMSYS=TRUE \
 ../kicad

 and got the same errors

  Built target qa_eeschema
 
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
 
CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.text+0x23cd):
 undefined reference to `.refptr.PyObject_GenericGetAttr'
 
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
 CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in
 function
 `std::invalid_argument::invalid_argument(std::invalid_argument
 const&)':
 C:/msys64/mingw64/include/c++/10.1.0/stdexcept:174: undefined
 reference to `.refptr._ZTVSt16invalid_argument'
 
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
 CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in
 function `std::_Sp_counted_deleter,
 (__gnu_cxx::_Lock_policy)2>::_M_get_deleter(std::type_info const&)':
 C:/msys64/mingw64/include/c++/10.1.0/bits/shared_ptr_base.h:490:
 undefined reference to `typeinfo for SWIG_null_deleter'
 
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
 CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in
 function `swig::traits_from

Re: [Kicad-developers] Profligacy of messages/ link errors building 5.99 on Windows 10/Msys

[Brian Piccioni]

Using this script

cmake -DCMAKE_BUILD_TYPE=Debug -G "MSYS Makefiles" 
-DCMAKE_PREFIX_PATH=C:/msys64/mingw64 
-DCMAKE_INSTALL_PREFIX=C:/msys64/mingw64 
-DDEFAULT_INSTALL_PATH=C:/msys64/mingw64 -DMSYS=TRUE ../kicad


I get the same results

[ 98%] Built target qa_eeschema
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: 
CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.text+0x23cd): 
undefined reference to `.refptr.PyObject_GenericGetAttr'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: 
CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in function 
`std::invalid_argument::invalid_argument(std::invalid_argument const&)':
C:/msys64/mingw64/include/c++/10.1.0/stdexcept:174: undefined reference 
to `.refptr._ZTVSt16invalid_argument'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: 
CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in function 
`std::_Sp_counted_deleterstd::allocator, 
(__gnu_cxx::_Lock_policy)2>::_M_get_deleter(std::type_info const&)':
C:/msys64/mingw64/include/c++/10.1.0/bits/shared_ptr_base.h:490: 
undefined reference to `typeinfo for SWIG_null_deleter'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: 
CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in function 
`swig::traits_from::from(KIID const&)':
C:/Users/bjpic/KicadWork/FixedFormatting/clean/debug/pcbnew/pcbnew_wrap.cxx:3929: 
undefined reference to `swig::traits_from_ptr::from(KIID*, int)'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: 
CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.rdata$_ZTI17SWIG_null_deleter+0x8): 
undefined reference to `typeinfo name for SWIG_null_deleter'

collect2.exe: error: ld returned 1 exit status
make[2]: *** [pcbnew/CMakeFiles/pcbnew_kiface.dir/build.make:634: 
pcbnew/_pcbnew.kiface] Error 1
make[1]: *** [CMakeFiles/Makefile2:3284: 
pcbnew/CMakeFiles/pcbnew_kiface.dir/all] Error 2

make: *** [Makefile:161: all] Error 2

bjpic@LAPTOP-70Q5CT1Q MINGW64 ~/FixedFormatting/clean/debug

On 2020-07-22 2:39 a.m., Nick Østergaard wrote:
Did you try to use the normal makefile generator rather than the 
eclipse one?


ons. 22. jul. 2020 01.37 skrev Brian Piccioni 
mailto:br...@documenteddesigns.com>>:


FWIW, I re-cloned Kicad master into an empty directory, created a
new build directory, ran the standard build script

cmake -DCMAKE_BUILD_TYPE=Debug \
-G "Eclipse CDT4 - Unix Makefiles" \
-DCMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT=TRUE \
-DCMAKE_PREFIX_PATH=C:/msys64/mingw64 \
-DCMAKE_INSTALL_PREFIX=C:/msys64/mingw64 \
-DDEFAULT_INSTALL_PATH=C:/msys64/mingw64 \
-DMSYS=TRUE \
../kicad

and got the same errors

 Built target qa_eeschema

C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:

CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.text+0x23cd):
undefined reference to `.refptr.PyObject_GenericGetAttr'

C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in
function
`std::invalid_argument::invalid_argument(std::invalid_argument
const&)':
C:/msys64/mingw64/include/c++/10.1.0/stdexcept:174: undefined
reference to `.refptr._ZTVSt16invalid_argument'

C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in
function `std::_Sp_counted_deleter,
(__gnu_cxx::_Lock_policy)2>::_M_get_deleter(std::type_info const&)':
C:/msys64/mingw64/include/c++/10.1.0/bits/shared_ptr_base.h:490:
undefined reference to `typeinfo for SWIG_null_deleter'

C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in
function `swig::traits_from::from(KIID const&)':

C:/Users/bjpic/KicadWork/FixedFormatting/clean/debug/pcbnew/pcbnew_wrap.cxx:3929:
undefined reference to `swig::traits_from_ptr::from(KIID*, int)'

C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:

CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.rdata$_ZTI17SWIG_null_deleter+0x8):
undefined reference to `typeinfo name for SWIG_null_deleter'
collect2.exe: error: ld returned 1 exit status
make[2]: *** [pcbnew/CMakeFiles/pcbnew_kiface.dir/build.make:635:
pcbnew/_pcbnew.kiface] Error 1
make[1]: *** [CMakeFiles/Makefile2:3284:
p

Re: [Kicad-developers] Profligacy of messages/ link errors building 5.99 on Windows 10/Msys

[Brian Piccioni]

I'll try it now but but the makefile generator script I used worked fine 
for over a year until now.


On 2020-07-22 2:39 a.m., Nick Østergaard wrote:
Did you try to use the normal makefile generator rather than the 
eclipse one?


ons. 22. jul. 2020 01.37 skrev Brian Piccioni 
mailto:br...@documenteddesigns.com>>:


FWIW, I re-cloned Kicad master into an empty directory, created a
new build directory, ran the standard build script

cmake -DCMAKE_BUILD_TYPE=Debug \
-G "Eclipse CDT4 - Unix Makefiles" \
-DCMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT=TRUE \
-DCMAKE_PREFIX_PATH=C:/msys64/mingw64 \
-DCMAKE_INSTALL_PREFIX=C:/msys64/mingw64 \
-DDEFAULT_INSTALL_PATH=C:/msys64/mingw64 \
-DMSYS=TRUE \
../kicad

and got the same errors

 Built target qa_eeschema

C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:

CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.text+0x23cd):
undefined reference to `.refptr.PyObject_GenericGetAttr'

C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in
function
`std::invalid_argument::invalid_argument(std::invalid_argument
const&)':
C:/msys64/mingw64/include/c++/10.1.0/stdexcept:174: undefined
reference to `.refptr._ZTVSt16invalid_argument'

C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in
function `std::_Sp_counted_deleter,
(__gnu_cxx::_Lock_policy)2>::_M_get_deleter(std::type_info const&)':
C:/msys64/mingw64/include/c++/10.1.0/bits/shared_ptr_base.h:490:
undefined reference to `typeinfo for SWIG_null_deleter'

C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in
function `swig::traits_from::from(KIID const&)':

C:/Users/bjpic/KicadWork/FixedFormatting/clean/debug/pcbnew/pcbnew_wrap.cxx:3929:
undefined reference to `swig::traits_from_ptr::from(KIID*, int)'

C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe:

CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.rdata$_ZTI17SWIG_null_deleter+0x8):
undefined reference to `typeinfo name for SWIG_null_deleter'
collect2.exe: error: ld returned 1 exit status
make[2]: *** [pcbnew/CMakeFiles/pcbnew_kiface.dir/build.make:635:
pcbnew/_pcbnew.kiface] Error 1
make[1]: *** [CMakeFiles/Makefile2:3284:
pcbnew/CMakeFiles/pcbnew_kiface.dir/all] Error 2
make: *** [Makefile:161: all] Error 2

bjpic@LAPTOP-70Q5CT1Q MINGW64 ~/FixedFormatting/clean/debug
$



On 2020-07-21 2:54 p.m., Ian McInerney wrote:

Ignore all of those notes being printed by the compiler about
mismatched struct/class definition. There is a bug in GCC 10.1
that isn't silencing those properly, but that is fixed in GCC
10.2/GCC 11 (I think they are hoping to release 10.2 this week).

The linker errors appear to be Python related. Did you update
your Python installation that KiCad uses recently? Can you
confirm that SWIG and Python are being detected correctly bby CMake?

-Ian

On Tue, Jul 21, 2020 at 6:58 PM Brian Piccioni
mailto:br...@documenteddesigns.com>> wrote:

Before updating master I had successfuIly build a c late June
version.

After failing to build yesterday's master I deleted my build
directory, pulled master, same problem. I then updated msys
in order to make sure it wasn't a tool issue. Same problem. I
deleted the build directory and same result.

When I get home I'll try a new download of master and try
that but I expect the same result

Note the earlier reply claiming to have had a similar problem.

On Tue, Jul 21, 2020, 13:47 Nick Østergaard
mailto:oe.n...@gmail.com>> wrote:

That looks quite strange. Did you try a clean build
directort? Maybe
there is some caching that is broken after a toolchain
update?  Pure
speculation.


    On Tue, 21 Jul 2020 at 16:47, Brian Piccioni
mailto:br...@documenteddesigns.com>> wrote:
>
> It is a non-release tag, but as a developer I sort of
need it to compile ...
>
> On 2020-07-21 10:45 a.m., Alex wrote:
>
> I too, also had the same errors, but assumed that 5.99
was some weird non-release tag, and switched to a
different branch, as this is my first day building the
application.
 

Re: [Kicad-developers] Profligacy of messages/ link errors building 5.99 on Windows 10/Msys

[Brian Piccioni]

FWIW, I re-cloned Kicad master into an empty directory, created a new 
build directory, ran the standard build script


cmake -DCMAKE_BUILD_TYPE=Debug \
-G "Eclipse CDT4 - Unix Makefiles" \
-DCMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT=TRUE \
-DCMAKE_PREFIX_PATH=C:/msys64/mingw64 \
-DCMAKE_INSTALL_PREFIX=C:/msys64/mingw64 \
-DDEFAULT_INSTALL_PATH=C:/msys64/mingw64 \
-DMSYS=TRUE \
../kicad

and got the same errors

 Built target qa_eeschema
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: 
CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.text+0x23cd): 
undefined reference to `.refptr.PyObject_GenericGetAttr'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: 
CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in function 
`std::invalid_argument::invalid_argument(std::invalid_argument const&)':
C:/msys64/mingw64/include/c++/10.1.0/stdexcept:174: undefined reference 
to `.refptr._ZTVSt16invalid_argument'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: 
CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in function 
`std::_Sp_counted_deleterstd::allocator, 
(__gnu_cxx::_Lock_policy)2>::_M_get_deleter(std::type_info const&)':
C:/msys64/mingw64/include/c++/10.1.0/bits/shared_ptr_base.h:490: 
undefined reference to `typeinfo for SWIG_null_deleter'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: 
CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj): in function 
`swig::traits_from::from(KIID const&)':
C:/Users/bjpic/KicadWork/FixedFormatting/clean/debug/pcbnew/pcbnew_wrap.cxx:3929: 
undefined reference to `swig::traits_from_ptr::from(KIID*, int)'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: 
CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.rdata$_ZTI17SWIG_null_deleter+0x8): 
undefined reference to `typeinfo name for SWIG_null_deleter'

collect2.exe: error: ld returned 1 exit status
make[2]: *** [pcbnew/CMakeFiles/pcbnew_kiface.dir/build.make:635: 
pcbnew/_pcbnew.kiface] Error 1
make[1]: *** [CMakeFiles/Makefile2:3284: 
pcbnew/CMakeFiles/pcbnew_kiface.dir/all] Error 2

make: *** [Makefile:161: all] Error 2

bjpic@LAPTOP-70Q5CT1Q MINGW64 ~/FixedFormatting/clean/debug
$



On 2020-07-21 2:54 p.m., Ian McInerney wrote:
Ignore all of those notes being printed by the compiler about 
mismatched struct/class definition. There is a bug in GCC 10.1 that 
isn't silencing those properly, but that is fixed in GCC 10.2/GCC 11 
(I think they are hoping to release 10.2 this week).


The linker errors appear to be Python related. Did you update your 
Python installation that KiCad uses recently? Can you confirm that 
SWIG and Python are being detected correctly bby CMake?


-Ian

On Tue, Jul 21, 2020 at 6:58 PM Brian Piccioni 
mailto:br...@documenteddesigns.com>> wrote:


Before updating master I had successfuIly build a c late June
version.

After failing to build yesterday's master I deleted my build
directory, pulled master, same problem. I then updated msys in
order to make sure it wasn't a tool issue. Same problem. I deleted
the build directory and same result.

When I get home I'll try a new download of master and try that but
I expect the same result

Note the earlier reply claiming to have had a similar problem.

On Tue, Jul 21, 2020, 13:47 Nick Østergaard mailto:oe.n...@gmail.com>> wrote:

That looks quite strange. Did you try a clean build directort?
Maybe
there is some caching that is broken after a toolchain
update?  Pure
speculation.


    On Tue, 21 Jul 2020 at 16:47, Brian Piccioni
mailto:br...@documenteddesigns.com>> wrote:
>
> It is a non-release tag, but as a developer I sort of need
it to compile ...
>
> On 2020-07-21 10:45 a.m., Alex wrote:
>
> I too, also had the same errors, but assumed that 5.99 was
some weird non-release tag, and switched to a different
branch, as this is my first day building the application.
    >
> On Tue, Jul 21, 2020, 4:42 PM Brian Piccioni
mailto:br...@documenteddesigns.com>> wrote:
>>
>> When building I get a slew of errors or information
messages of the type
>> (see below). During linking I then get a pile of
"undefined" errors.
>> There are so many I can't reproduce them all.
>>
>> When I link I get a fatal error.
>>
>> This is the Master branch downloaded a few minutes before
compiling. I
>> tried updating Msys and get the same 

Re: [Kicad-developers] Profligacy of messages/ link errors building 5.99 on Windows 10/Msys

[Brian Piccioni]

Before updating master I had successfuIly build a c late June version.

After failing to build yesterday's master I deleted my build directory,
pulled master, same problem. I then updated msys in order to make sure it
wasn't a tool issue. Same problem. I deleted the build directory and same
result.

When I get home I'll try a new download of master and try that but I expect
the same result

Note the earlier reply claiming to have had a similar problem.

On Tue, Jul 21, 2020, 13:47 Nick Østergaard  wrote:

> That looks quite strange. Did you try a clean build directort? Maybe
> there is some caching that is broken after a toolchain update?  Pure
> speculation.
>
>
> On Tue, 21 Jul 2020 at 16:47, Brian Piccioni
>  wrote:
> >
> > It is a non-release tag, but as a developer I sort of need it to compile
> ...
> >
> > On 2020-07-21 10:45 a.m., Alex wrote:
> >
> > I too, also had the same errors, but assumed that 5.99 was some weird
> non-release tag, and switched to a different branch, as this is my first
> day building the application.
> >
> > On Tue, Jul 21, 2020, 4:42 PM Brian Piccioni <
> br...@documenteddesigns.com> wrote:
> >>
> >> When building I get a slew of errors or information messages of the type
> >> (see below). During linking I then get a pile of "undefined" errors.
> >> There are so many I can't reproduce them all.
> >>
> >> When I link I get a fatal error.
> >>
> >> This is the Master branch downloaded a few minutes before compiling. I
> >> tried updating Msys and get the same result.
> >>
> >>
> >> 42 |   struct ctype_base
> >>|  ^~
> >> In file included from C:/msys64/mingw64/include/c++/10.1.0/string:43,
> >>   from
> C:/msys64/mingw64/include/wx-3.0/wx/stringimpl.h:66,
> >>   from C:/msys64/mingw64/include/wx-3.0/wx/unichar.h:15,
> >>   from
> C:/msys64/mingw64/include/wx-3.0/wx/strvararg.h:22,
> >>   from C:/msys64/mingw64/include/wx-3.0/wx/string.h:46,
> >>   from C:/msys64/mingw64/include/wx-3.0/wx/memory.h:15,
> >>   from C:/msys64/mingw64/include/wx-3.0/wx/object.h:19,
> >>   from C:/msys64/mingw64/include/wx-3.0/wx/wx.h:15,
> >>   from
> >> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/include/fctsys.h:28,
> >>   from
> >>
> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/pcbnew/dialogs/panel_modedit_defaults.cpp:24:
> >> C:/msys64/mingw64/include/c++/10.1.0/bits/localefwd.h:125:9: note:
> >> replace the class-key with 'struct'
> >>125 |   class ctype_base;
> >>| ^~
> >> In file included from
> >> C:/msys64/mingw64/include/c++/10.1.0/bits/locale_facets.h:41,
> >>   from
> >> C:/msys64/mingw64/include/c++/10.1.0/bits/basic_ios.h:37,
> >>   from C:/msys64/mingw64/include/c++/10.1.0/ios:44,
> >>   from C:/msys64/mingw64/include/c++/10.1.0/ostream:38,
> >>   from C:/msys64/mingw64/include/c++/10.1.0/iostream:39,
> >>   from C:/msys64/mingw64/include/wx-3.0/wx/ioswrap.h:18,
> >>   from
> C:/msys64/mingw64/include/wx-3.0/wx/textctrl.h:33,
> >>   from C:/msys64/mingw64/include/wx-3.0/wx/wx.h:81,
> >>   from
> >> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/include/fctsys.h:28,
> >>   from
> >>
> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/pcbnew/dialogs/panel_modedit_defaults.cpp:24:
> >>
> C:/msys64/mingw64/include/c++/10.1.0/x86_64-w64-mingw32/bits/ctype_base.h:42:10:
> >> note: 'std::ctype_base' defined as 'struct' here
> >> 42 |   struct ctype_base
> >>|  ^~
> >> [ 93%] Building CXX object
> >> pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/initpcb.cpp.obj
> >> In file included from
> >>
> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/thirdparty/nlohmann_json/nlohmann/json.hpp:70,
> >>   from
> >>
> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/include/settings/json_settings.h:24,
> >>   from
> >>
> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/include/settings/app_settings.h:25,
> >>   from
> >>
> C:/Users/bjpic/KicadWork/FixedFormatting/kicad/pcbnew/pcbnew_settings.h:24,
> >>   from
> >>
> C:/Users/

Re: [Kicad-developers] Profligacy of messages/ link errors building 5.99 on Windows 10/Msys

[Brian Piccioni]

It is a non-release tag, but as a developer I sort of need it to compile ...

On 2020-07-21 10:45 a.m., Alex wrote:
I too, also had the same errors, but assumed that 5.99 was some weird 
non-release tag, and switched to a different branch, as this is my 
first day building the application.


On Tue, Jul 21, 2020, 4:42 PM Brian Piccioni 
mailto:br...@documenteddesigns.com>> wrote:


When building I get a slew of errors or information messages of
the type
(see below). During linking I then get a pile of "undefined" errors.
There are so many I can't reproduce them all.

When I link I get a fatal error.

This is the Master branch downloaded a few minutes before
compiling. I
tried updating Msys and get the same result.


    42 |   struct ctype_base
   |  ^~
In file included from C:/msys64/mingw64/include/c++/10.1.0/string:43,
  from
C:/msys64/mingw64/include/wx-3.0/wx/stringimpl.h:66,
  from
C:/msys64/mingw64/include/wx-3.0/wx/unichar.h:15,
  from
C:/msys64/mingw64/include/wx-3.0/wx/strvararg.h:22,
  from
C:/msys64/mingw64/include/wx-3.0/wx/string.h:46,
  from
C:/msys64/mingw64/include/wx-3.0/wx/memory.h:15,
  from
C:/msys64/mingw64/include/wx-3.0/wx/object.h:19,
  from C:/msys64/mingw64/include/wx-3.0/wx/wx.h:15,
  from
C:/Users/bjpic/KicadWork/FixedFormatting/kicad/include/fctsys.h:28,
  from

C:/Users/bjpic/KicadWork/FixedFormatting/kicad/pcbnew/dialogs/panel_modedit_defaults.cpp:24:
C:/msys64/mingw64/include/c++/10.1.0/bits/localefwd.h:125:9: note:
replace the class-key with 'struct'
   125 |   class ctype_base;
   | ^~
In file included from
C:/msys64/mingw64/include/c++/10.1.0/bits/locale_facets.h:41,
  from
C:/msys64/mingw64/include/c++/10.1.0/bits/basic_ios.h:37,
  from C:/msys64/mingw64/include/c++/10.1.0/ios:44,
  from
C:/msys64/mingw64/include/c++/10.1.0/ostream:38,
  from
C:/msys64/mingw64/include/c++/10.1.0/iostream:39,
  from
C:/msys64/mingw64/include/wx-3.0/wx/ioswrap.h:18,
  from
C:/msys64/mingw64/include/wx-3.0/wx/textctrl.h:33,
  from C:/msys64/mingw64/include/wx-3.0/wx/wx.h:81,
  from
C:/Users/bjpic/KicadWork/FixedFormatting/kicad/include/fctsys.h:28,
  from

C:/Users/bjpic/KicadWork/FixedFormatting/kicad/pcbnew/dialogs/panel_modedit_defaults.cpp:24:

C:/msys64/mingw64/include/c++/10.1.0/x86_64-w64-mingw32/bits/ctype_base.h:42:10:

note: 'std::ctype_base' defined as 'struct' here
    42 |   struct ctype_base
   |  ^~
[ 93%] Building CXX object
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/initpcb.cpp.obj
In file included from

C:/Users/bjpic/KicadWork/FixedFormatting/kicad/thirdparty/nlohmann_json/nlohmann/json.hpp:70,
  from

C:/Users/bjpic/KicadWork/FixedFormatting/kicad/include/settings/json_settings.h:24,
  from

C:/Users/bjpic/KicadWork/FixedFormatting/kicad/include/settings/app_settings.h:25,
  from
C:/Users/bjpic/KicadWork/FixedFormatting/kicad/pcbnew/pcbnew_settings.h:24,
  from

C:/Users/bjpic/KicadWork/FixedFormatting/kicad/pcbnew/dialogs/dialog_update_pcb.cpp:29:
C:/msys64/mingw64/include/c++/10.1.0/valarray:574:20: note:
replace the
class-key with 'struct'
   574 |   friend class _Array<_Tp>;
   |    ^~~
In file included from
C:/msys64/mingw64/include/c++/10.1.0/valarray:100,
  from

C:/Users/bjpic/KicadWork/FixedFormatting/kicad/thirdparty/nlohmann_json/nlohmann/json.hpp:70,
  from

C:/Users/bjpic/KicadWork/FixedFormatting/kicad/include/settings/json_settings.h:24,
  from

C:/Users/bjpic/KicadWork/FixedFormatting/kicad/include/settings/app_settings.h:25,
  from
C:/Users/bjpic/KicadWork/FixedFormatting/kicad/pcbnew/pcbnew_settings.h:24,
  from

C:/Users/bjpic/KicadWork/FixedFormatting/kicad/pcbnew/dialogs/dialog_update_pcb.cpp:29:
C:/msys64/mingw64/include/c++/10.1.0/bits/valarray_array.h:396:12:
note:
'std::_Array<_Tp>' defined as 'struct' here
   396 | struct _Array
   |    ^~
In file included from
C:/msys64/mingw64/include/c++/10.1.0/bits/ios_base.h:46,
  from
C:/msys64/mingw64/include/c++/10.1.0/streambuf:41,
  from
C:/msys64/mingw64/include/c++/10.1.0/bits/streambuf_iterator.h:35,
  from
   

[Kicad-developers] Profligacy of messages/ link errors building 5.99 on Windows 10/Msys

[Brian Piccioni]

When building I get a slew of errors or information messages of the type 
(see below). During linking I then get a pile of "undefined" errors. 
There are so many I can't reproduce them all.


When I link I get a fatal error.

This is the Master branch downloaded a few minutes before compiling. I 
tried updating Msys and get the same result.



   42 |   struct ctype_base
  |  ^~
In file included from C:/msys64/mingw64/include/c++/10.1.0/string:43,
 from C:/msys64/mingw64/include/wx-3.0/wx/stringimpl.h:66,
 from C:/msys64/mingw64/include/wx-3.0/wx/unichar.h:15,
 from C:/msys64/mingw64/include/wx-3.0/wx/strvararg.h:22,
 from C:/msys64/mingw64/include/wx-3.0/wx/string.h:46,
 from C:/msys64/mingw64/include/wx-3.0/wx/memory.h:15,
 from C:/msys64/mingw64/include/wx-3.0/wx/object.h:19,
 from C:/msys64/mingw64/include/wx-3.0/wx/wx.h:15,
 from 
C:/Users/bjpic/KicadWork/FixedFormatting/kicad/include/fctsys.h:28,
 from 
C:/Users/bjpic/KicadWork/FixedFormatting/kicad/pcbnew/dialogs/panel_modedit_defaults.cpp:24:
C:/msys64/mingw64/include/c++/10.1.0/bits/localefwd.h:125:9: note: 
replace the class-key with 'struct'

  125 |   class ctype_base;
  | ^~
In file included from 
C:/msys64/mingw64/include/c++/10.1.0/bits/locale_facets.h:41,
 from 
C:/msys64/mingw64/include/c++/10.1.0/bits/basic_ios.h:37,

 from C:/msys64/mingw64/include/c++/10.1.0/ios:44,
 from C:/msys64/mingw64/include/c++/10.1.0/ostream:38,
 from C:/msys64/mingw64/include/c++/10.1.0/iostream:39,
 from C:/msys64/mingw64/include/wx-3.0/wx/ioswrap.h:18,
 from C:/msys64/mingw64/include/wx-3.0/wx/textctrl.h:33,
 from C:/msys64/mingw64/include/wx-3.0/wx/wx.h:81,
 from 
C:/Users/bjpic/KicadWork/FixedFormatting/kicad/include/fctsys.h:28,
 from 
C:/Users/bjpic/KicadWork/FixedFormatting/kicad/pcbnew/dialogs/panel_modedit_defaults.cpp:24:
C:/msys64/mingw64/include/c++/10.1.0/x86_64-w64-mingw32/bits/ctype_base.h:42:10: 
note: 'std::ctype_base' defined as 'struct' here

   42 |   struct ctype_base
  |  ^~
[ 93%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/initpcb.cpp.obj
In file included from 
C:/Users/bjpic/KicadWork/FixedFormatting/kicad/thirdparty/nlohmann_json/nlohmann/json.hpp:70,
 from 
C:/Users/bjpic/KicadWork/FixedFormatting/kicad/include/settings/json_settings.h:24,
 from 
C:/Users/bjpic/KicadWork/FixedFormatting/kicad/include/settings/app_settings.h:25,
 from 
C:/Users/bjpic/KicadWork/FixedFormatting/kicad/pcbnew/pcbnew_settings.h:24,
 from 
C:/Users/bjpic/KicadWork/FixedFormatting/kicad/pcbnew/dialogs/dialog_update_pcb.cpp:29:
C:/msys64/mingw64/include/c++/10.1.0/valarray:574:20: note: replace the 
class-key with 'struct'

  574 |   friend class _Array<_Tp>;
  |    ^~~
In file included from C:/msys64/mingw64/include/c++/10.1.0/valarray:100,
 from 
C:/Users/bjpic/KicadWork/FixedFormatting/kicad/thirdparty/nlohmann_json/nlohmann/json.hpp:70,
 from 
C:/Users/bjpic/KicadWork/FixedFormatting/kicad/include/settings/json_settings.h:24,
 from 
C:/Users/bjpic/KicadWork/FixedFormatting/kicad/include/settings/app_settings.h:25,
 from 
C:/Users/bjpic/KicadWork/FixedFormatting/kicad/pcbnew/pcbnew_settings.h:24,
 from 
C:/Users/bjpic/KicadWork/FixedFormatting/kicad/pcbnew/dialogs/dialog_update_pcb.cpp:29:
C:/msys64/mingw64/include/c++/10.1.0/bits/valarray_array.h:396:12: note: 
'std::_Array<_Tp>' defined as 'struct' here

  396 | struct _Array
  |    ^~
In file included from 
C:/msys64/mingw64/include/c++/10.1.0/bits/ios_base.h:46,

 from C:/msys64/mingw64/include/c++/10.1.0/streambuf:41,
 from 
C:/msys64/mingw64/include/c++/10.1.0/bits/streambuf_iterator.h:35,

 from C:/msys64/mingw64/include/c++/10.1.0/iterator:66,
 from C:/msys64/mingw64/include/c++/10.1.0/regex:43,
 from 
C:/Users/bjpic/KicadWork/FixedFormatting/kicad/pcbnew/dialogs/panel_pcbnew_color_settings.cpp:21:
C:/msys64/mingw64/include/c++/10.1.0/system_error:54:9: note: replace 
the class-key with 'struct'

   54 |   class error_code;
  | ^~
C:/msys64/mingw64/include/c++/10.1.0/system_error:180:10: note: 
'std::error_code' defined as 'struct' here

  180 |   struct error_code
  |  ^~
C:/msys64/mingw64/include/c++/10.1.0/system_error:55:9: note: replace 
the class-key with 'struct'

   55 |   class error_condition;
  | ^~~
C:/msys64/mingw64/include/c++/10.1.0/system_error:278:10: note: 
'std::error_condition' 

Re: [Kicad-developers] DRC ladybug symbol origin

[Brian Piccioni]

I'm guessing because it finds bugs?

On 2020-07-16 11:14 p.m., Ben Ellis wrote:

Hi all,

Does anyone know why the DRC symbol is a ladybug? Asking for a friend

Best,
Ben

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Build on msys2 fails : libngspice-x.dll not found in any executable path

[Brian Piccioni]

Wayne

Thanks for the suggestion! It didn't take that much time to build. When 
it was done, the output file had a different extension.


pacman -U mingw-w64-x86_64-wxPython-3.0.2.0-9-any.pkg.tar.zst

I am now trying to compile origin/master.

On 2020-05-25 11:28 a.m., Wayne Stambaugh wrote:

I've had this problem the last couple of times that a new build of the
wxWidgets package was released.  You will have to checkout a copy of the
mingw package repo on github and rebuild the wxPython package with the
latest compiler (gcc 10) to fix the ABI warning.  It's not terribly
difficult just do the following:

* Launch the msys2 console.  This does not work with a mingw console.
* Run `cd /to/your/src/folder`
* Run `git clonehttps://github.com/msys2/MINGW-packages.git`
* Run `cd ./MINGW-packages/mingw-w64-wxPython`
* Run `makepkg-mingw`
* Wait a really long time for both 64 and 32 bit packages to build.
* Run `pacman -U mingw-w64-x86_64-wxPython-3.0.2.0-9-any.pkg.tar.xz` or
`pacman -U mingw-w64-i686-wxPython-3.0.2.0-9-any.pkg.tar.xz` depending
if you are using mingw64 or mingw32.
* Reconfigure your KiCad build.  You may have to do a clean configure.


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Build on msys2 fails : libngspice-x.dll not found in any executable path

[Brian Piccioni]

I did  that and got a weird error from cmake to the effect it wanted to 
build MSVS make files (from long, long, long ago).


I deleted all CMakeCacke.txt on my system.

I decided to run pacman -Syuu and it did a small update.

I then ran the cmake script without scripting off

cmake -DCMAKE_BUILD_TYPE=Debug
 -G "Eclipse CDT4 - Unix Makefiles"
 -DCMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT=TRUE
 -DCMAKE_PREFIX_PATH=C:/msys64/mingw64
 -DCMAKE_INSTALL_PREFIX=C:/msys64/mingw64
 -DDEFAULT_INSTALL_PATH=C:/msys64/mingw64
 -DMSYS=TRUE
 ../kicad

this completed with no errors. I am running

make -j install   presently.


perhaps they fixed the wxPython issue?



On 2020-05-25 10:57 a.m., jp charras wrote:

Le 25/05/2020 à 15:33, Brian Piccioni a écrit :

Unfortunately, while we seem to get past the libngspice-0.dll problem with the 
fix, the old workaround  for the python problem no longer works.

cmake -DCMAKE_BUILD_TYPE=Debug \
-DKICAD_SCRIPTING=OFF\ <<<<<<<<<<<<<<<<<<<< I believe this used to get around 
the pyhton mismatch.
-G "Eclipse CDT4 - Unix Makefiles" \
-DCMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT=TRUE \
-DCMAKE_PREFIX_PATH=C:/msys64/mingw64 \
-DCMAKE_INSTALL_PREFIX=C:/msys64/mingw64 \
-DDEFAULT_INSTALL_PATH=C:/msys64/mingw64 \
-DMSYS=TRUE \
../kicad


Throws the library mismatch error.


$ cmake -DCMAKE_BUILD_TYPE=Debug \

-DKICAD_SCRIPTING=OFF\
-G "Eclipse CDT4 - Unix Makefiles" \
-DCMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT=TRUE \
-DCMAKE_PREFIX_PATH=C:/msys64/mingw64 \
-DCMAKE_INSTALL_PREFIX=C:/msys64/mingw64 \
-DDEFAULT_INSTALL_PATH=C:/msys64/mingw64 \
-DMSYS=TRUE \
../kicad

-- Eclipse version is set to 3.6 (Helios). Adjust CMAKE_ECLIPSE_VERSION if this 
is wrong.
-- KiCad install dir: 
-- Enabling warning -Wsuggest-override
-- Enabling warning -Wduplicated-branches
-- Enabling warning -Wduplicated-cond
-- Enabling error for -Wvla
-- Enabling warning -Wimplicit-fallthrough
-- Enabling error for -Wreturn-type
-- Enabling warning -Wshadow
-- Check for installed GLEW -- found
info: libngspice shared lib found: C:/msys64/mingw64/bin/libngspice-0.dll

-- Check for installed Python Interpreter -- found
-- Python module install path: lib/python2.7/site-packages
CMake Error at CMakeModules/FindwxPython.cmake:52 (message):
   wxPython/Phoenix does not appear to be installed on the system
Call Stack (most recent call first):
   CMakeLists.txt:740 (find_package)


-- Configuring incomplete, errors occurred!
See also 
"C:/msys64/home/Msys_bjpic/FixedFormatting/debug/CMakeFiles/CMakeOutput.log".
See also 
"C:/msys64/home/Msys_bjpic/FixedFormatting/debug/CMakeFiles/CMakeError.log".


I do not see this issue.

FindwxPython is not called if cmake is called with -DKICAD_SCRIPTING=OFF
(or DKICAD_SCRIPTING_WXPYTHON=OFF)
Try to delete CMakeCacke.txt and rerun cmake.




___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Build on msys2 fails : libngspice-x.dll not found in any executable path

[Brian Piccioni]

Unfortunately, while we seem to get past the libngspice-0.dll problem 
with the fix, the old workaround  for the python problem no longer works.


cmake -DCMAKE_BUILD_TYPE=Debug \
-DKICAD_SCRIPTING=OFF\  I believe this used to get 
around the pyhton mismatch.

-G "Eclipse CDT4 - Unix Makefiles" \
-DCMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT=TRUE \
-DCMAKE_PREFIX_PATH=C:/msys64/mingw64 \
-DCMAKE_INSTALL_PREFIX=C:/msys64/mingw64 \
-DDEFAULT_INSTALL_PATH=C:/msys64/mingw64 \
-DMSYS=TRUE \
../kicad


Throws the library mismatch error.


$ cmake -DCMAKE_BUILD_TYPE=Debug \
> -DKICAD_SCRIPTING=OFF\
> -G "Eclipse CDT4 - Unix Makefiles" \
> -DCMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT=TRUE \
> -DCMAKE_PREFIX_PATH=C:/msys64/mingw64 \
> -DCMAKE_INSTALL_PREFIX=C:/msys64/mingw64 \
> -DDEFAULT_INSTALL_PATH=C:/msys64/mingw64 \
> -DMSYS=TRUE \
> ../kicad
-- Eclipse version is set to 3.6 (Helios). Adjust CMAKE_ECLIPSE_VERSION 
if this is wrong.

-- KiCad install dir: 
-- Enabling warning -Wsuggest-override
-- Enabling warning -Wduplicated-branches
-- Enabling warning -Wduplicated-cond
-- Enabling error for -Wvla
-- Enabling warning -Wimplicit-fallthrough
-- Enabling error for -Wreturn-type
-- Enabling warning -Wshadow
-- Check for installed GLEW -- found
info: libngspice shared lib found: C:/msys64/mingw64/bin/libngspice-0.dll

-- Check for installed Python Interpreter -- found
-- Python module install path: lib/python2.7/site-packages
CMake Error at CMakeModules/FindwxPython.cmake:52 (message):
  wxPython/Phoenix does not appear to be installed on the system
Call Stack (most recent call first):
  CMakeLists.txt:740 (find_package)


-- Configuring incomplete, errors occurred!
See also 
"C:/msys64/home/Msys_bjpic/FixedFormatting/debug/CMakeFiles/CMakeOutput.log".
See also 
"C:/msys64/home/Msys_bjpic/FixedFormatting/debug/CMakeFiles/CMakeError.log".




On 2020-05-25 6:55 a.m., jp charras wrote:

Le 23/05/2020 à 17:55, jp charras a écrit :

Le 23/05/2020 à 17:35, Wayne Stambaugh a écrit :

There is definitely something wrong but I'm not sure where the issue is.
  I downgraded both cmake a couple of versions but cmake started
complaining about missing libraries.  I even modified Findngspice.cmake
with the absolute path to libngspice-0.dll and it still didn't work so
something is definitely broken.  I'm may try a full clean reinstall of
msys2 when I have a *lot* of free time so I don't know when that will
happen.  For all of you windows devs using msys2, you might want to hold
off updating until this issue is resolved.



I also tried the last msys version.
I found 2 issues:
this issue: libngspice-0.dll is not found even if it is in path.
This is an issue but one can invoke cmake with option 
-DNGSPICE_DLL=
The other issue is the fact the last msys version comes with wxWidgets 3.05 
compiled with gcc10
but wxPython was not rebuild and there is an ABI issue.



I just committed a fix for the libngspice-x.dll issue.
I am not entirely convinced this is a msys issue.
However, the wxPython problem is a msys issue.



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Build on msys2 fails : libngspice-x.dll not found in any executable path

[Brian Piccioni]

I am glad to hear it wasn't finger trouble on my part at least.

On 2020-05-23 11:55 a.m., jp charras wrote:

Le 23/05/2020 à 17:35, Wayne Stambaugh a écrit :

There is definitely something wrong but I'm not sure where the issue is.
  I downgraded both cmake a couple of versions but cmake started
complaining about missing libraries.  I even modified Findngspice.cmake
with the absolute path to libngspice-0.dll and it still didn't work so
something is definitely broken.  I'm may try a full clean reinstall of
msys2 when I have a *lot* of free time so I don't know when that will
happen.  For all of you windows devs using msys2, you might want to hold
off updating until this issue is resolved.



I also tried the last msys version.
I found 2 issues:
this issue: libngspice-0.dll is not found even if it is in path.
This is an issue but one can invoke cmake with option 
-DNGSPICE_DLL=
The other issue is the fact the last msys version comes with wxWidgets 3.05 
compiled with gcc10
but wxPython was not rebuild and there is an ABI issue.




___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Build on msys2 fails : libngspice-x.dll not found in any executable path

[Brian Piccioni]

Hello

I updated Msys2 (pacman -Syuu) and it borked the terminal (basically 
when building the nice percentages, etc., became more or less random  
strings).


I decided to reinstall Msys2. I wiped the directory and reinstalled.

After doing so and following the directions at 
https://docs.kicad-pcb.org/doxygen/md_Documentation_development_compiling.html#build_windows


cmake -DCMAKE_BUILD_TYPE=Release \
  -G "MSYS Makefiles" \
  -DCMAKE_PREFIX_PATH=/mingw64 \
  -DCMAKE_INSTALL_PREFIX=/mingw64 \
  -DDEFAULT_INSTALL_PATH=/mingw64 \
  ../../

Fails with

-- Found Boost: C:/msys64/mingw64/include (found suitable version 
"1.72.0", minimum required is "1.59.0")

ERROR:
* libngspice-x.dll not found in any executable path *


CMake Error at 
C:/msys64/mingw64/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:164 
(message):

  Could NOT find ngspice (missing: NGSPICE_DLL)
Call Stack (most recent call first):
C:/msys64/mingw64/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:445 
(_FPHSA_FAILURE_MESSAGE)

  CMakeModules/Findngspice.cmake:63 (find_package_handle_standard_args)
  CMakeLists.txt:628 (find_package)



However, I do have C:\msys64\mingw64\bin\libngspice-0.dll and my path is 
PATH=C:\msys64;C:\msys64\mingw64\bin; ... (in the cmake file there is a 
remark


    # Note: libngspice-0.dll or libngspice-1.dll must be in a 
executable path



Any suggestions how to fix this would be appreciated.



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] v6 breaking changes to eeschema - starting new refactor wise?

[Brian Piccioni]

James

Yes, it is entirely separate. Geographic re-annotation require back 
annotation of the schematic. This required functionality added by 
Alexannder Shuklin.


Annotation of the schematic does not require re-annotation of the PCB, 
however, my menu does offer the option to update the PCB when done. 
Pushing changes from schematic to PCB uses the same function as "Update 
PCB from Schematic" (F8). The eeSchema and PCBNew code bases are largely 
separate.


FYI I update my (geographic) reannotation branch the other day. My 
(schematic) annotation branch is based on that so I can have 
re-annotation functionality when I use PCBNew and I'll update it once I 
send my PCB to the PCB shop.


Brian



On 2020-05-12 8:59 p.m., James Jackson wrote:
Hi Nick - Yep I've been chatting with Brian about having a look at his 
schematic annotation code. Either me or him (depends who gets to it 
first!) are going to merge his development branch with the 
upstream/master to check it still works, and then take it from 
there, either collaborating to get it working if it ticks all the 
boxes, or adding any other functionality that has been suggested in 
the other threads.


What I'm not clear on yet, Brian, is if the schematic annotation work 
you have done is logically separate from the geographic annotation? It 
looks like it on the comments from your merge request, but it's just 
another thing I need to be sure before I go looking at code seriously.


On Tue, May 12, 2020 at 11:48 PM Nick Østergaard > wrote:


I am not sure exactly what kind of annotation stuff you are working
on, but there is another guy working on some geographical annotation.
See https://gitlab.com/kicad/code/kicad/-/merge_requests/108

On Tue, 12 May 2020 at 19:07, Wayne Stambaugh
mailto:stambau...@gmail.com>> wrote:
>
> Hi James,
>
> By "breaking" changes, I'm assuming you mean changes yet to come
and not
> broken changes which is something all together different.  I don't
> foresee any changes that would significantly impact the
annotation code
> if any at all so you are probably safe to work on it.  I highly
> recommend that write up a simple proposal either on your GitLab
instance
> or something like Google docs so that the lead dev team can comment.
> This helps to prevent you from wasting your time by implementing
> something that get rejected by the dev team.
>
> I am surprised you think the annotation code looks deceptively
simple.
> I'm still trying to wrap my head around all of the potential
sheet path
> issues and I've written and/or refactored most of that code.  I
don't
> think anyone has gotten this right the first time including myself.
>
> All that being said, I think most users would find more advanced
> annotation options useful so I would be in favor of it.
>
> Cheers,
>
> Wayne
>
> On 5/12/20 12:36 PM, James Jackson wrote:
> > Hi all,
> >
> > I'm starting to dig through the code to understand how to
implement a
> > new annotation scheme (all looks deceptively simple in terms
of object
> > manipulation... there will be a crocodile hiding there
somewhere I'm
> > sure!). However, I've noted in a few bug reports and new feature
> > requests that there are likely to be significant changes to
eeschema
> > moving towards v6 (last reference I saw was in relation to
vector and
> > group busses). So, is it wise to start looking at a
significant feature
> > now (if the big changes have happened already), or wait until
those
> > changes are made, or is this not actually an issue? Just
trying to avoid
> > wasting effort and then have to re-duplicate it later!
> >
> > Thanks,
> > James.
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to     : kicad-developers@lists.launchpad.net

> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@lists.launchpad.net

> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to     : kicad-developers@lists.launchpad.net

Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

___
Mailing list: 

Re: [Kicad-developers] v6 breaking changes to eeschema - starting new refactor wise?

[Brian Piccioni]

Nick

Thanks for remembering me!

I am still hoping for some feedback on my geographic reannotation 
feature. I did do some work on schematic reannotation but I think it 
makes sense to put this one to bed as soon as possible.


Although geographic reannotation seems finished, I did hit some issues 
with schematic reannotation and need some guidance from somebody 
familiar with the schematic data structures.



Brian

On 2020-05-12 5:39 p.m., Nick Østergaard wrote:

I am not sure exactly what kind of annotation stuff you are working
on, but there is another guy working on some geographical annotation.
See https://gitlab.com/kicad/code/kicad/-/merge_requests/108

On Tue, 12 May 2020 at 19:07, Wayne Stambaugh  wrote:

Hi James,

By "breaking" changes, I'm assuming you mean changes yet to come and not
broken changes which is something all together different.  I don't
foresee any changes that would significantly impact the annotation code
if any at all so you are probably safe to work on it.  I highly
recommend that write up a simple proposal either on your GitLab instance
or something like Google docs so that the lead dev team can comment.
This helps to prevent you from wasting your time by implementing
something that get rejected by the dev team.

I am surprised you think the annotation code looks deceptively simple.
I'm still trying to wrap my head around all of the potential sheet path
issues and I've written and/or refactored most of that code.  I don't
think anyone has gotten this right the first time including myself.

All that being said, I think most users would find more advanced
annotation options useful so I would be in favor of it.

Cheers,

Wayne

On 5/12/20 12:36 PM, James Jackson wrote:

Hi all,

I'm starting to dig through the code to understand how to implement a
new annotation scheme (all looks deceptively simple in terms of object
manipulation... there will be a crocodile hiding there somewhere I'm
sure!). However, I've noted in a few bug reports and new feature
requests that there are likely to be significant changes to eeschema
moving towards v6 (last reference I saw was in relation to vector and
group busses). So, is it wise to start looking at a significant feature
now (if the big changes have happened already), or wait until those
changes are made, or is this not actually an issue? Just trying to avoid
wasting effort and then have to re-duplicate it later!

Thanks,
James.

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Geographic reannotation - any feedback

[Brian Piccioni]

Gabriel

Thank you for the reply!

I am using Windows 10/MSYS2 64/Eclipse.

I think the important part is MSYS2 since it really seems to be 
something between clang-format and git. I believe I followed the kicad 
instructions to set up clang-format exactly


In my kicad source directory I entered

git config core.hooksPath .githooks
git config clangFormat.style file
git config kicad.check-format true

And didn't get any errors.

Yet I have got all sorts of feedback that my code doesn't seem to follow 
the kicad clang-format standards with respect to the things it should catch.


I looked into this a while ago and asked but got no replies. I assume 
clang-format isn't doing its job.


I am happy to fix whatever issues they are, even manually if I have to.

But I need feedback for that ...

Brian






On 2020-05-10 12:20 p.m., Gabriel Staples, ElectricRCAircraftGuy.com wrote:

Brian,

I'd like to help you get clang-format working if possible. What OS are 
you on? Do these install instructions help? I haven't looked at any 
instructions for KICAD but I wrote these for another project I 
contribute to:


https://github.com/AmboVent-1690-108/AmboVent/blob/master/README.md#software


Thanks!

Gabriel Staples
Electric RC Aircraft Guy, LLC
www.ElectricRCAircraftGuy.com <http://www.ElectricRCAircraftGuy.com>

Check out my "Computa Pranksta" USB device sold on Amazon!

(sent from my Android)

Le dim. 10 mai 2020 à 8:51 AM, Brian Piccioni 
mailto:br...@documenteddesigns.com>> a 
écrit :


Hello

I managed to update my Merge Request
(https://gitlab.com/kicad/code/kicad/-/merge_requests/108) to master
without any GIT screw ups.

The only change I had to make to the code was the name of the PCBNew
configuration method.

It compiles and runs.

I have been using this for some time without any issues. I am sure
there
are style problems since I can't get clang-format to work.

That said, I'd appreciate feedback or some idea when this might be
merged.

I know everybody is busy with COVID, etc., but things seem to be more
active nowadays.


Thanks

Brian


___
Mailing list: https://launchpad.net/~kicad-developers
Post to     : kicad-developers@lists.launchpad.net
<mailto:kicad-developers@lists.launchpad.net>
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Geographic reannotation - any feedback

[Brian Piccioni]

Hello

I managed to update my Merge Request 
(https://gitlab.com/kicad/code/kicad/-/merge_requests/108) to master 
without any GIT screw ups.


The only change I had to make to the code was the name of the PCBNew 
configuration method.


It compiles and runs.

I have been using this for some time without any issues. I am sure there 
are style problems since I can't get clang-format to work.


That said, I'd appreciate feedback or some idea when this might be merged.

I know everybody is busy with COVID, etc., but things seem to be more 
active nowadays.



Thanks

Brian


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Eeschema annotate block / specific component types proposal

[Brian Piccioni]

Hello James

I had been working on this for some time and ran into a brick wall so I 
set it aside.


There seems to be an issue with the structures used within eeSchema 
(sheets, screens, etc.) which don't seem to consistently track UUIDs, 
etc. I suspect that this may be because eeSchema started as a single 
page app then added hierarchies. Currently, annotate has an essentially 
binary approach (whole schematic or single page) and, in theory it 
should be possible to add those functions but you end up with bad 
pointers, display not refreshing, etc..


I put out several requests for the devs for help but, given the lock 
down got no replies.


I implemented similar functionality for PCBNew. My gitlab is 
https://gitlab.com/bjpiccioni/kicad and the branch is annotate if you 
want to take a look. It is out of date because I got really frustrated 
trying to unnscramble it. All the menus, etc., are done, the problem is 
just that the result doesn't work.



If you want to collaborate, let me know. And I'll try bring it up to 
date with the current dev branch of Kicad. Alas I find git to be a  
nightmare.


Brian



On 2020-05-07 9:19 a.m., James Jackson wrote:

Hi all,

Firstly thanks Wayne for adding me to the list - long time KiCad user 
for hobby stuff, but I've got a background (partially) in fast 
real-time mixed-signal electronics.


Working on a fairly large personal project recently, with many nested 
and shared schematics, I would really have liked the ability to only 
automatically annotate either a selected block of components, and/or 
only a subset of the component types. I haven't done an KiCad 
UI-facing dev work (or, frankly, much at all bar poking around in the 
code a little bit) but I'd be happy to have a bash at implementing it 
- but would welcome others' thoughts. I can't find any mention of it 
in roadmaps etc.


*Proposal*: Add the ability to annotate only a selected block and / or 
only specific component types
*UI Flow: *Two changes required, as detailed below. As described, they 
do not change the current default UI flow, but offer up more options 
for users should they wish to use them:


   1. Add a new menu item to the block selection context menu, with 
text 'Annotate block...'. On clicking, takes the user to the current 
'Annotate Schematic' dialog.

   2. Modify the 'Annotate Schematic' dialog to include:
       a. Within the 'Scope' radio button selection list, add 'Use the 
current selected block' (not enabled if the dialog is entered the 
existing way through the Tools menu) - autoselected if dialog entered 
through the block context menu
       b. Add a checklist containing the prefixes of component types 
available for annotation (i.e. 'R', 'C', 'U', whatever...). Default to 
all being selected.


I'd welcome thoughts on this proposal, and also, if people think it's 
worth looking at, any pointers to a quick guide to KiCad dev wrt 
branch handling. I.e., do developers work to the head of the 
repository or the last stable release, etc etc? I couldn't find 
anything on this hiding in the dev docs. I can figure the rest out 
(internationalisation, code structures, etc etc).


Yours,
James.

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] eeSchema : force refresh of all schematics

[Brian Piccioni]

Hi

I am working on updating eeschema annotation. I expanded it to work on a 
selection and current sheet + all subsheets.


I am stuck on a weird problem: my code does indeed update all the 
annotation. I have an unexpected problem with subsheets re-annotation 
sequencing but I know how to deal with that.


My problem is this: only the displayed sheet is shown as re-annotated. 
So if I have R?, R?, R? R? on the displayed sheet and C?, C?, C?, C? on 
a subsheet I end up with R1, R2, R3, R4 on the displayed sheet but still 
C?, C?, C?, C? on the subsheet.


However, if I save the files and reopen the schematic, C?, C?, C?, C? 
have indeed been numbered.


It appears eeSchema caches a pre-rendered version of each schematic and 
I need to flush that cache.


Any suggestions as to how I can flush this cache and/or force all the 
rendered schematics to be re-rendered? I've tried every permutation of 
refresh, I can think of.



Thanks

Brian


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Help with Gitlab, push failed to my fork

[Brian Piccioni]

Mario

I don't know if this is your problem but some projects are set up to 
mirror the kicad source repository automatically (as mine was).


In other words, remote origin did point like this

origin  https://gitlab.com/kicad/code/kicad.git (fetch)
origin  https://gitlab.com/kicad/code/kicad.git (push)

it pointed to

https://gitlab.com/bjpiccioni/kicad.git (fetch)

This caused all sorts of problems for me. In addition, Git stopped 
mirroring forks (I might not be using the right term)


I had to switch over to origin as /kicad/kicad.git

Brian


On 2020-03-28 3:11 p.m., Mário Luzeiro wrote:

Hi all,
It worked all the time, now I cannot push to my fork on gitlab.

I got this error:
remote: GitLab: Author 'alexandr.shuklin biovitrum.ru' is not a member of team
! [remote rejected] master -> master (pre-receive hook declined)

Looks it is related with this recent commit:
https://gitlab.com/kicad/code/kicad/-/commit/cf259758761d48628b7fbca91b1083e45b2fb34f

Is that happening only to me? how can it be fixed?

Mario
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Annotation Epic/Geographic reannotation

[Brian Piccioni]

Jon

Thanks for the reply. I was referring to 
https://gitlab.com/kicad/code/kicad/-/merge_requests/108, not the 
earlier one which I borked.


I understand people have lots of things to do but given my lack of 
expertise I am never sure if its something I did or just part of the 
process so I always assume radio silence means I screwed something up.


I think !108 is pretty up to date with master. I will have to push a new 
version with consistent handling of references with eeSchema.


Brian


On 2020-03-01 7:31 p.m., Jon Evans wrote:

Hi Brian,

I haven't looked at your MR yet since it seemed like a lot of other 
people were already engaged and I think "too many cooks in the 
kitchen" can be a detriment to code review.
I just opened it up today and noticed that it needs to be rebased on 
master (can't be done automatically, which probably means some code it 
is based on has diverged)


@Ian McInerney <mailto:ian.s.mciner...@ieee.org> since you already 
were reviewing, any comments on the latest?


Best,
-Jon

On Sun, Mar 1, 2020 at 12:06 PM Brian Piccioni 
mailto:br...@documenteddesigns.com>> wrote:


Hello

I haven't had any feedback/comments regarding my merge request or
Annotation suggestion for quite a few days now so I don't know
whether
my comments/pushes are being broadcast or people are simply busy
working
on other things.

So, sorry for the spam.

I just added this to the Annotations epic
(https://gitlab.com/groups/kicad/code/-/epics/19) as I have been
working
on annotation. I would appreciate any feedback on the issues
mentioned
below.


1) No undo for annotation dialog
 Problem: eeSchema undo seems to be page confined.
 Fixing this would probably be a good idea but a lot of work and
likely beyond my abilities
 at a this time. I can make a special "undo" stack for
annotation as
a stop gap.

2) Annotate while adding is a WIP see
https://lists.launchpad.net/kicad-developers/msg42354.html

See https://bugs.launchpad.net/kicad/+bug/1660134 for items 4 - 6.
4) Annotate selection

 I should be able to manage this


5) Anotate without a number
6) Annotate number only.

    5 and 6 seem pretty straightforward to implement though there are
filters on dialogs which will
    have to be fixed. There may be an issue with transfer between
schematic and PCB
    (i.e. Update PCB to/from schematic) as well as geographic
annotation
from the PCB as error
    checking is done on all of these. I am working on a unified
reference "splitter" for eeSchema and
    PCBNew to ensure consistency.

    My concern is that annotation seems pretty well woven into
eeSchema,
DRC, library editor, etc., and
    something will break if we do this. For example, having a
reference
with RK causes DRC to ask for
    annotation as does updating PCB from Schematic. If things
break they
can be fixed, but what if the
    breakage is only apparent on edge conditions? How can we test?

8) Subsheets don't match multi-unit element annotations. (lp:#1788976)
    I do not understand this

9) Implement more (and custom?) annotation schemes
https://bugs.launchpad.net/kicad/+bug/1800726
    I have already coded prefixs to allow for IEE 200, etc.. One can
then annotate sheet by sheet
    to give a prefix to each sheet. Alternatively we could add a
sheet
specific symbol/flag/notation
    which defines a prefix per sheet. I suspect that reannotating
each
sheet with a sheet prefix
    would meet most use cases.

10) Clear annotation does not work under MSW
https://gitlab.com/kicad/code/kicad/issues/1942
 I cannot replicate this. The results I get are different from
the
video. It works fine for me.




___
Mailing list: https://launchpad.net/~kicad-developers
Post to     : kicad-developers@lists.launchpad.net
<mailto:kicad-developers@lists.launchpad.net>
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Annotation Epic/Geographic reannotation

[Brian Piccioni]

Hello

I haven't had any feedback/comments regarding my merge request or 
Annotation suggestion for quite a few days now so I don't know whether 
my comments/pushes are being broadcast or people are simply busy working 
on other things.


So, sorry for the spam.

I just added this to the Annotations epic 
(https://gitlab.com/groups/kicad/code/-/epics/19) as I have been working 
on annotation. I would appreciate any feedback on the issues mentioned 
below.



1) No undo for annotation dialog
    Problem: eeSchema undo seems to be page confined.
    Fixing this would probably be a good idea but a lot of work and 
likely beyond my abilities
    at a this time. I can make a special "undo" stack for annotation as 
a stop gap.


2) Annotate while adding is a WIP see 
https://lists.launchpad.net/kicad-developers/msg42354.html


See https://bugs.launchpad.net/kicad/+bug/1660134 for items 4 - 6.
4) Annotate selection

    I should be able to manage this


5) Anotate without a number
6) Annotate number only.

   5 and 6 seem pretty straightforward to implement though there are 
filters on dialogs which will
   have to be fixed. There may be an issue with transfer between 
schematic and PCB
   (i.e. Update PCB to/from schematic) as well as geographic annotation 
from the PCB as error
   checking is done on all of these. I am working on a unified 
reference "splitter" for eeSchema and

   PCBNew to ensure consistency.

   My concern is that annotation seems pretty well woven into eeSchema, 
DRC, library editor, etc., and
   something will break if we do this. For example, having a reference 
with RK causes DRC to ask for
   annotation as does updating PCB from Schematic. If things break they 
can be fixed, but what if the

   breakage is only apparent on edge conditions? How can we test?

8) Subsheets don't match multi-unit element annotations. (lp:#1788976)
   I do not understand this

9) Implement more (and custom?) annotation schemes 
https://bugs.launchpad.net/kicad/+bug/1800726
   I have already coded prefixs to allow for IEE 200, etc.. One can 
then annotate sheet by sheet
   to give a prefix to each sheet. Alternatively we could add a sheet 
specific symbol/flag/notation
   which defines a prefix per sheet. I suspect that reannotating each 
sheet with a sheet prefix

   would meet most use cases.

10) Clear annotation does not work under MSW 
https://gitlab.com/kicad/code/kicad/issues/1942
    I cannot replicate this. The results I get are different from the 
video. It works fine for me.





___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Proposal to update eeSchema annotation?

[Brian Piccioni]

Cool! A great idea.

I'd never heard of "epics" before this.


On 2020-02-23 11:35 a.m., Eeli Kaikkonen wrote:



On Sat, Feb 22, 2020 at 4:48 PM Brian Piccioni 
mailto:br...@documenteddesigns.com>> wrote:


Hello

Now that Geographic Reannotation is a WIP I was thinking it might
make sense to update eeSchema's Annotate dialog.


I created an epic for annotation related issues. You should probably 
file each proposition as a report if there's no report already.


https://gitlab.com/groups/kicad/code/-/epics/19


Incorporate undo


There's an existing issue for "Back annotation changes unable to be 
undone in schematic", but there are more problems with Annotation.


With one simple component open the annotation dialog, annotate and 
close. The component is annotated, but:


1) "Save" is not activated in the toolbar. It's activated in the File 
menu. But when I click on the canvas, the button is activated.


2) There's no undo. If I annotate manually by editing the refdes, Undo 
works. IIRC Undo has worked previously.


These must be reported separately, right? (I'm asking from the senior 
developers.)


Eeli Kaikkonen
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Proposal to update eeSchema annotation?

[Brian Piccioni]

Hello

Now that Geographic Reannotation is a WIP I was thinking it might make 
sense to update eeSchema's Annotate dialog.


I propose the following:

*Change to dialog:*

**Add to Scope:             Selection

Add to Numbering:    Add/Remove prefixes (allows conformance to ASME 
Y14.44 and IEEE 315)
                                      Replace "page number times 100, 
1000" with "page number times X"


Add optional push to PCB

Place Advanced options on a tab.

*General:
*Incorporate undo
Perform a "sanity check" on new annotation to check for redundant 
references before committing it.


*Other:
*Additional suggestions?


Compared to Geographic Reannotation this should be straightforward. I do 
not see any need to modify PCBNew code.


Also I have a better understanding of the code and process and should 
require less hand holding.


Any thoughts?

Brian

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] What does /path do in PCBNew files?

[Brian Piccioni]

I'd like a head's up when UUID is implemented as a lot of my code is 
based on timestamps as unique IDs.



On 2020-02-15 6:47 p.m., Jeff Young wrote:
Pasting creates new timestamps.  So copy/paste works fine, there’s 
just no way to do a unified copy/paste between eeschema *and* pcbnew.


The timestamps are moving to UUIDs as we speak.

The links are reset/updated when you do an Update PCB from Schematic 
and chose the “re-associate by reference” option.  (The 
timestamps/UUIDs encode said “association”.)


Cheers,
Jeff.


On 15 Feb 2020, at 23:40, Brian Piccioni <mailto:br...@documenteddesigns.com>> wrote:


I guess I'd wonder then why provide Copy and Paste/Duplicate if the 
result is not usable?


It seems like a sort of honey pot.

On 2020-02-15 6:34 p.m., Eeli Kaikkonen wrote:




On Sun, Feb 16, 2020 at 1:20 AM Brian Piccioni 
mailto:br...@documenteddesigns.com>> 
wrote:


I think optionally removing the path might be a good idea - or,
simply removing it from duplicated/pasted footprints. Of course
I am probably missing something.

Brian

You can't backannotate something which doesn't have the "path". But 
those footprints can of course be re-annotated.


I don't think it's possible to cleanly copypaste groups of 
footprints to create "duplicated design elements" as you say. Either 
they point to one group of symbols while they should point to 
hierarchical sheet instances (each of which have different path), or 
they don't have corresponding symbols at all.


If you have two footprints with identical "paths" you can reannotate 
from eeshcema (with a warning IIRC) and both footprints will have 
the same refdes. But it doesn't make sense to have two footprints 
with different refdes to point to one symbol because the symbol has 
only one refdes.


Having identical paths in more than one footprints is problematic 
anyways. I have used it but I don't recommend it.


Eeli Kaikkonen

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net 
<mailto:kicad-developers@lists.launchpad.net>

Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] What does /path do in PCBNew files?

[Brian Piccioni]

I see.

So the approach to duplicating a section would be

1) Copy the design in eeschema
2) in eeSchema push to PCBNew
3) Layout a single section.
4) Copy and paste that section
5) Re-annotate the PCB section (this works now!) without pushing to 
schematic so the references correspond to the schematic

6) in eeSchema push to PCBNew associating by reference

Brian


On 2020-02-15 6:47 p.m., Jeff Young wrote:
Pasting creates new timestamps.  So copy/paste works fine, there’s 
just no way to do a unified copy/paste between eeschema *and* pcbnew.


The timestamps are moving to UUIDs as we speak.

The links are reset/updated when you do an Update PCB from Schematic 
and chose the “re-associate by reference” option.  (The 
timestamps/UUIDs encode said “association”.)


Cheers,
Jeff.


On 15 Feb 2020, at 23:40, Brian Piccioni <mailto:br...@documenteddesigns.com>> wrote:


I guess I'd wonder then why provide Copy and Paste/Duplicate if the 
result is not usable?


It seems like a sort of honey pot.

On 2020-02-15 6:34 p.m., Eeli Kaikkonen wrote:




On Sun, Feb 16, 2020 at 1:20 AM Brian Piccioni 
mailto:br...@documenteddesigns.com>> 
wrote:


I think optionally removing the path might be a good idea - or,
simply removing it from duplicated/pasted footprints. Of course
I am probably missing something.

Brian

You can't backannotate something which doesn't have the "path". But 
those footprints can of course be re-annotated.


I don't think it's possible to cleanly copypaste groups of 
footprints to create "duplicated design elements" as you say. Either 
they point to one group of symbols while they should point to 
hierarchical sheet instances (each of which have different path), or 
they don't have corresponding symbols at all.


If you have two footprints with identical "paths" you can reannotate 
from eeshcema (with a warning IIRC) and both footprints will have 
the same refdes. But it doesn't make sense to have two footprints 
with different refdes to point to one symbol because the symbol has 
only one refdes.


Having identical paths in more than one footprints is problematic 
anyways. I have used it but I don't recommend it.


Eeli Kaikkonen

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net 
<mailto:kicad-developers@lists.launchpad.net>

Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] What does /path do in PCBNew files?

[Brian Piccioni]

I guess I'd wonder then why provide Copy and Paste/Duplicate if the 
result is not usable?


It seems like a sort of honey pot.

On 2020-02-15 6:34 p.m., Eeli Kaikkonen wrote:




On Sun, Feb 16, 2020 at 1:20 AM Brian Piccioni 
mailto:br...@documenteddesigns.com>> wrote:


I think optionally removing the path might be a good idea - or,
simply removing it from duplicated/pasted footprints. Of course I
am probably missing something.

Brian

You can't backannotate something which doesn't have the "path". But 
those footprints can of course be re-annotated.


I don't think it's possible to cleanly copypaste groups of footprints 
to create "duplicated design elements" as you say. Either they point 
to one group of symbols while they should point to hierarchical sheet 
instances (each of which have different path), or they don't have 
corresponding symbols at all.


If you have two footprints with identical "paths" you can reannotate 
from eeshcema (with a warning IIRC) and both footprints will have the 
same refdes. But it doesn't make sense to have two footprints with 
different refdes to point to one symbol because the symbol has only 
one refdes.


Having identical paths in more than one footprints is problematic 
anyways. I have used it but I don't recommend it.


Eeli Kaikkonen
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] What does /path do in PCBNew files?

[Brian Piccioni]

Eeli

Thanks for the explanation. I suspect it will need a re-think - or at 
least some modification.


I am almost finished the "to do" list for geographic re-annotation. One 
thing that occurred to me is that the "re-annotate selected" would be 
very useful for duplicating design elements. For example, lets say we 
have 4 output amplifiers with connectors etc.. We can route one then 
copy and paste the other 3, then re-annotate them to correspond to the 
schematic. After all, we have nifty new "back annotation" functions!


Except back-annotation breaks when the /path field is duplicated.

I don't know enough to propose a fix but I can imagine users will have 
problems (and generate bug reports) when they do copy and paste inside 
PCBNew.


I think optionally removing the path might be a good idea - or, simply 
removing it from duplicated/pasted footprints. Of course I am probably 
missing something.


Brian



On 2020-02-15 6:07 p.m., Eeli Kaikkonen wrote:
It's the symbol ID from the schematic. This defines the connection 
between the symbol in the schematic file and the footprint in the 
layout file.


Indeed I have intended to ask about copying this in pcbnew. There's no 
way to change (remove) it in pcbnew. Once a footprint is pasted or 
duplicated it's bind to the same symbol as it's originator footprint. 
As far as I can see there's one use case for this when copying from 
the same board: having several alternative physical components for one 
functional component (symbol). But this isn't obvious nor is it clean IMO.


It's probably useful if the corresponding components are copied from 
another project to both eeschema and pcbnew. But inside one project 
this may be more confusing than useful. Maybe it should be handled 
like copying/pasting symbols and reference designators is handled now 
in 5.99: with Paste Special options, trying to find the best 
alternative for the default paste.


And/or there should be a way to reset this field. The footprints added 
by the "Add a footprint" function don't have "path".



On Sun, Feb 16, 2020 at 12:30 AM Brian Piccioni 
mailto:br...@documenteddesigns.com>> wrote:


Hello

In the "Kicad File Formats" PDF (and in KicadPCB files) there is
(path /5127A011)  where the number after the slash usually
changes. I don't see any where this field is described in the
documentation.

It seems that if I copy and past a symbol in PCBNew the "(path /"
field is duplicated so I end up with two components with the same
"(path /" causes, for example "Error: Pcb footprints R100 and R8
linked to same symbol" error on back annotation.

This, in turn, causes problems with geographic reannotation.

So, can somebody explain what (path / is?

Thanks


Brian Piccioni

___
Mailing list: https://launchpad.net/~kicad-developers
Post to     : kicad-developers@lists.launchpad.net
<mailto:kicad-developers@lists.launchpad.net>
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] What does /path do in PCBNew files?

[Brian Piccioni]

Hello

In the "Kicad File Formats" PDF (and in KicadPCB files) there is (path 
/5127A011)  where the number after the slash usually changes. I don't 
see any where this field is described in the documentation.


It seems that if I copy and past a symbol in PCBNew the "(path /" field 
is duplicated so I end up with two components with the same "(path /" 
causes, for example "Error: Pcb footprints R100 and R8 linked to same 
symbol" error on back annotation.


This, in turn, causes problems with geographic reannotation.

So, can somebody explain what (path / is?

Thanks


Brian Piccioni

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Cryptic characters in source

[Brian Piccioni]

Perhaps I misunderstand but I don't see anything (screen grab from 
notepad++ on Windows 10)


On 2020-02-08 4:32 p.m., ja...@veith.net wrote:
My editor shows non ascii cryptic characters in master cpp source what 
I cannot see in the browser. Here it is underscore M and I tried using 
Emacs what shows escape M sequences. Compare attached screendump. Much 
more of that stuff lives in _FRAME::TW_Init. Although for line 39 it 
is between = and EOL the GCC parser does not complain about.

Can anybody confirm this ?


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Repeat request for help from icon maintainer.

[Brian Piccioni]

JP

Thank you so much for your help!

Removing the Msys2 versions of inkscape and then installing the windows 
package and adjusting my path to


    export PATH=$PATH:"/c/Program Files/Inkscape"

and then commenting out line 33 in zutil.h, recompiling and replacing 
pngcrush seemed to work.


I am providing details in case others have this challenge.

I am now waiting for the compile to run but it seems happy.

Thanks again!

Brian

On 2020-02-04 12:27 p.m., jp charras wrote:

Le 04/02/2020 à 17:32, Brian Piccioni a écrit :

JP

Thanks for this.

Unfortunately, inkscape and pngcrush seem to be a work in process on Msys.

If I install the package

     $ pacman -S mingw-w64-x86_64-inkscape

and run inkscape I get the error

     $ inkscape
     C:/msys64/mingw64/bin/inkscape.exe: error while loading shared
libraries: libpoppler-89.dll: cannot open shared object file: No such
file or directory

If I build inkscape in MSYS and run make install I get

     [  0%] Built target potrace
     make[2]: Entering directory '/home/bjpic/debug'
     [  0%] Creating 48 pixel tall
C:/msys64/home/bjpic/debug/bitmaps_png/tmp/wizard_add_fplib_icon.png
     Unknown option --without-gui
     [  0%] Creating 16 pixel tall
C:/msys64/home/bjpic/debug/bitmaps_png/tmp/folder.png
     Unknown option --without-gui
     [  0%] Creating cleaned file
C:/msys64/home/bjpic/kicad/bitmaps_png/png_16/folder.png

running inkscape --without-gui causes the same error.

Similarly, installing the pngcrush package in msys2 pacman -S
mingw-w64-x86_64-pngcrush results in the warning

$ pngcrush
Warning: versions are different between png.h and png.c
   png.h version: 1.6.34
   png.c version: 1.6.37

Making pngcrush under msys2 fails with a forced error.

In general it seems that many related utilities under Msys2 are a dogs
breakfasts.

Perhaps for the moment it would be best if I simply made my bitmaps
manually.

Brian


I have no issues with inkscape and pngcrush.
However:
- Inkscape is installed from binaries coming from Inkscape site.
- pngcrush was built on msys2 by me from pngcrush sources.
This is a very small program and it is easy to build on msys2.
However, to build it, remove (or comment) the line 33 in zutil.h
"typedef long ptrdiff_t;  /* guess -- will be caught if guess is wrong */"
to avoid a conflict with a mingw included file.

the first useful line of my script running cmake is:
export PATH=$WXMSW:$PATH:/d/inkscape:/d/pngcrush

You will have to remove inkscape from msys2.

Attached, my msys2 script to run cmake.

Good luck...


On 2020-02-04 9:34 a.m., jp charras wrote:

Le 04/02/2020 à 15:06, Brian Piccioni a écrit :

Hello

I emailed earlier because when I follow the directions to create a new
icon under MSYS2 it fails.

This means that either

1) the directions are wrong or
2) I am following them incorrectly.

Perhaps an icon maintainer can get in contact with me and work through
this?

I basically need to clone the icons annotate_right_down and
annotate_down_right rotated 90, 180, and 270 degrees. Not complicated.

thanks


Brian

Hi Brian,

To build the .cpp files the option MAINTAIN_PNGS must be set to ON in
makefiles.

So:
1 - To avoid cache issues, delete your current CMakeCache.txt file in
your build directory.
2 - Run cmake as before, with option -DMAINTAIN_PNGS=ON to recreated the
makefiles

After that you should be able to rebuild/create the .cpp bitmap files.


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Repeat request for help from icon maintainer.

[Brian Piccioni]

JP

Thanks for this.

Unfortunately, inkscape and pngcrush seem to be a work in process on Msys.

If I install the package

    $ pacman -S mingw-w64-x86_64-inkscape

and run inkscape I get the error

    $ inkscape
    C:/msys64/mingw64/bin/inkscape.exe: error while loading shared 
libraries: libpoppler-89.dll: cannot open shared object file: No such 
file or directory


If I build inkscape in MSYS and run make install I get

    [  0%] Built target potrace
    make[2]: Entering directory '/home/bjpic/debug'
    [  0%] Creating 48 pixel tall 
C:/msys64/home/bjpic/debug/bitmaps_png/tmp/wizard_add_fplib_icon.png

    Unknown option --without-gui
    [  0%] Creating 16 pixel tall 
C:/msys64/home/bjpic/debug/bitmaps_png/tmp/folder.png

    Unknown option --without-gui
    [  0%] Creating cleaned file 
C:/msys64/home/bjpic/kicad/bitmaps_png/png_16/folder.png


running inkscape --without-gui causes the same error.

Similarly, installing the pngcrush package in msys2 pacman -S 
mingw-w64-x86_64-pngcrush results in the warning


$ pngcrush
Warning: versions are different between png.h and png.c
  png.h version: 1.6.34
  png.c version: 1.6.37

Making pngcrush under msys2 fails with a forced error.

In general it seems that many related utilities under Msys2 are a dogs 
breakfasts.


Perhaps for the moment it would be best if I simply made my bitmaps 
manually.


Brian


On 2020-02-04 9:34 a.m., jp charras wrote:

Le 04/02/2020 à 15:06, Brian Piccioni a écrit :

Hello

I emailed earlier because when I follow the directions to create a new
icon under MSYS2 it fails.

This means that either

1) the directions are wrong or
2) I am following them incorrectly.

Perhaps an icon maintainer can get in contact with me and work through
this?

I basically need to clone the icons annotate_right_down and
annotate_down_right rotated 90, 180, and 270 degrees. Not complicated.

thanks


Brian

Hi Brian,

To build the .cpp files the option MAINTAIN_PNGS must be set to ON in
makefiles.

So:
1 - To avoid cache issues, delete your current CMakeCache.txt file in
your build directory.
2 - Run cmake as before, with option -DMAINTAIN_PNGS=ON to recreated the
makefiles

After that you should be able to rebuild/create the .cpp bitmap files.



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Repeat request for help from icon maintainer.

[Brian Piccioni]

Hello

I emailed earlier because when I follow the directions to create a new 
icon under MSYS2 it fails.


This means that either

1) the directions are wrong or
2) I am following them incorrectly.

Perhaps an icon maintainer can get in contact with me and work through this?

I basically need to clone the icons annotate_right_down and 
annotate_down_right rotated 90, 180, and 270 degrees. Not complicated.


thanks


Brian



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] kicad | WIP: Geographical re-annotation (!56)

[Brian Piccioni]

Eeli

I wasn't aware the merge. Gitlab is a nightmare for me and I may have 
closed it accidentally. Ever since I opened my brianadtdocumenteddesigns 
account it would not let me clone kicad master. Eventually I found a 
workaround to let me clone alex's fork but then when I tried to fix my 
geographical annotation it resolutely would not let me do that no matter 
what I tried. So I opened a new gitlab account bjpiccioni and have been 
using that.


I would very much like thoughts/help on the UI in general. I am very bad 
with UIs and was hoping that someone would comment. While I appreciate 
good UIs I don't seem to be able to create them myself.


I like your idea and will work on it.

I will also send out another plea for help specifically for the missing 
icons. I think I can manually create them for debugging purposes but it 
baffles me nobody seems to know how to make them using the recommended 
procedure.


Any additional comments/suggestions are welcomed.


Brian

On 2020-02-04 3:55 a.m., Eeli Kaikkonen wrote:

GitLab

Eeli Kaikkonen  commented:

I'm curious, do all the parties who have been involved in this 
discussion receive notifications even though this merge request has 
been closed?


I use this discussion because the actual comment is on topic, I hope 
Brian doesn't mind reviving this.


You asked about the icons in the mailing list. I can't help with that, 
but I have another thought about the UI WRT the direction.


Here's a screenshot from your old UI: image 



I don't know what kind of changes you have planned, but if you are 
going to use all 8 direction options, it would be better to break up 
into two options: "Start from" and "Direction". Then there would be 4 
options + 2 options:


|Start From: Top left Top right Bottom left Bottom right Direction: 
Horizontal first Vertical first|


And there could be one place for the icon which would show the final 
combination.


This would be IMO much more easy to comprehend than putting all 8 into 
one list.


—
Reply to this email directly or view it on GitLab 
.
You're receiving this email because of your account on gitlab.com. If 
you'd like to receive fewer emails, you can unsubscribe 
 
from this thread or adjust your notification settings.


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Creating new icons

[Brian Piccioni]

I did!

However, while there are two valid directions to annotate a schematic 
there are 8 valid directions to annotate a PCB.


This is because while the schematic is annotated for the designer while 
the PCB is annotated for manufacturing and/or the technician.


My plan is to copy the two directions icons from eeschema but rotated 
0,90,180, and 270 degrees.


If anybody knows how to do that programmatically that would be even better.

Brian

On 2020-02-02 1:01 p.m., Eeli Kaikkonen wrote:



On Sun, Feb 2, 2020 at 7:09 PM Brian Piccioni 
mailto:br...@documenteddesigns.com>> wrote:



Currently I select re-annotation direction by a text box "top to
bottom,
left to right", etc.. It would probably be best if these were icons
associated with radio buttons.


Have you already looked at the Annotate Schematic dialog in eeschema? 
It has similar icons, maybe they are reusable.


Eeli Kaikkonen

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Creating new icons

[Brian Piccioni]

Hello

In light of Alexander's merge of back annotation I am updating my 
re-annotation function. The dialog I created is sub-optimal (I did ask 
for input).


I am working on mingw64/msys2

Currently I select re-annotation direction by a text box "top to bottom, 
left to right", etc.. It would probably be best if these were icons 
associated with radio buttons.


In order to create icons I need to

1) install inkscape
2) install pngcrush
3) set line 53 of cmakelists.txt in bitmaps_png to ON

I have done all of this but I get warnings when I run inkscape or 
pngcrush, even though they do run.


Nonetheless I get an error if I touch annotate_right_down.svg

make[2]: Entering directory '/home/bjpic/debug'
make[2]: Entering directory '/home/bjpic/debug'
make[2]: *** No rule to make target 
'C:/msys64/home/bjpic/kicad/bitmaps_png/cpp_26/annotate_right_down.cpp', 
needed by 
'bitmaps_png/CMakeFiles/bitmaps.dir/cpp_26/annotate_right_down.cpp.obj'. 
Stop.

make[2]: Leaving directory '/home/bjpic/debug'
make[2]: Entering directory '/home/bjpic/debug'
make[1]: *** [CMakeFiles/Makefile2:1533: 
bitmaps_png/CMakeFiles/bitmaps.dir/all] Error 2

make[1]: *** Waiting for unfinished jobs
make[2]: Leaving directory '/home/bjpic/debug'
make[2]: Leaving directory '/home/bjpic/debug'
make[2]: Leaving directory '/home/bjpic/debug'
-- Found Git: C:/msys64/usr/bin/git.exe (found version "2.25.0")
make[2]: Leaving directory '/home/bjpic/debug'
-- Using Git to determine build version string.
make[2]: Leaving directory '/home/bjpic/debug'
[  2%] Built target qa_sexpr
[  3%] Built target kimath
[  4%] Built target s3d_plugin_oce
[  6%] Built target s3d_plugin_vrml
[  7%] Built target kicad2step_lib
-- Not updating C:/msys64/home/bjpic/debug/kicad_build_version.h
make[2]: Leaving directory '/home/bjpic/debug'
[  7%] Built target version_header
make[1]: Leaving directory '/home/bjpic/debug'
make: *** [Makefile:141: all] Error 2

Please suggest how I can proceed.


Thanks

Brian


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Proper way to report bugs on branches

[Brian Piccioni]

Thanks!

I would have never found it because I didn't search for "floated".



On 2020-01-28 9:32 a.m., Seth Hillbrand wrote:
No need.  It has already been reported with reproduction steps here 
https://gitlab.com/kicad/code/kicad/issues/3811


If you find a bug, use the standard bug reporting procedure but only 
report bugs there that reproduce in master.


If you find a bug that doesn't exist in master but does exist in the 
MR, then add a thread to the MR with the reproduction steps.


Thanks-
Seth

On 2020-01-28 08:04, Brian Piccioni wrote:

Jp

Actually, that is the bug: every time I hit F8 one or more of RN3,
RN4, RN5, and RN6 are shown as new components on the PCB. It deletes
the old RNs and put new ones with the same name.

I got RN3, RN4 then RN3, RN4,  RN5 and RN6, then RN3, etc.

Every time I hit F8 the thing rips up those RNs.

This schematic has only had one sheet ever.

I shall recompile the master branch and try and boil down the
schematic to something simple to test.

Brian



On 2020-01-28 3:36 a.m., jp charras wrote:

Le 28/01/2020 à 01:10, Brian Piccioni a écrit :

Hello

I have been using Kicad while working on re-annotation (hopefully
Alexander's merge request will soon be accepted and I can dust off 
mine).


I have been using branches of the current master. I have noticed a few
issues which I think are significant and not related to Alexander's 
work

(or mine).

For example, when I hit F8 in eeSchema to update my PCB it resolutely
demands to update some of my resistor network symbols unless I select
"Update footprint associations by existing references". This seems to
happen no matter how many time I let it update those RNs.

Should I used the standard bug reporting system or is there a special
way to deal with these?

Brian

Components with multi units have one sheet path (unique ID) by unit.
But a footprint has only one sheet path.
So only one sheet path must be picked among candidates.

Looks to me the way the sheet path is chosen has changed between stable
and master version.

This is an annoying change, but not an actual "bug".
However fixing it is a good idea.

My personal opinion is the:
"Update footprint associations by existing references"
should be the default.
and the other option only used after re-annotation (the unique id is 
not

an obvious parameter for users, because it is a "shadowed" parameter).

Once the board is updated, you should not see this issue (of course
using the same eeschema version).



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


Seth Hillbrand
KiCad Services Corporation
https://www.kipro-pcb.com
+1 530 302 5483 | +1 212 603 9372


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Proper way to report bugs on branches

[Brian Piccioni]

Jp

Actually, that is the bug: every time I hit F8 one or more of RN3, RN4, 
RN5, and RN6 are shown as new components on the PCB. It deletes the old 
RNs and put new ones with the same name.


I got RN3, RN4 then RN3, RN4,  RN5 and RN6, then RN3, etc.

Every time I hit F8 the thing rips up those RNs.

This schematic has only had one sheet ever.

I shall recompile the master branch and try and boil down the schematic 
to something simple to test.


Brian



On 2020-01-28 3:36 a.m., jp charras wrote:

Le 28/01/2020 à 01:10, Brian Piccioni a écrit :

Hello

I have been using Kicad while working on re-annotation (hopefully
Alexander's merge request will soon be accepted and I can dust off mine).

I have been using branches of the current master. I have noticed a few
issues which I think are significant and not related to Alexander's work
(or mine).

For example, when I hit F8 in eeSchema to update my PCB it resolutely
demands to update some of my resistor network symbols unless I select
"Update footprint associations by existing references". This seems to
happen no matter how many time I let it update those RNs.

Should I used the standard bug reporting system or is there a special
way to deal with these?

Brian

Components with multi units have one sheet path (unique ID) by unit.
But a footprint has only one sheet path.
So only one sheet path must be picked among candidates.

Looks to me the way the sheet path is chosen has changed between stable
and master version.

This is an annoying change, but not an actual "bug".
However fixing it is a good idea.

My personal opinion is the:
"Update footprint associations by existing references"
should be the default.
and the other option only used after re-annotation (the unique id is not
an obvious parameter for users, because it is a "shadowed" parameter).

Once the board is updated, you should not see this issue (of course
using the same eeschema version).



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Proper way to report bugs on branches

[Brian Piccioni]

I am pretty sure, yes.

So I should recompile the master branch and try reproduce the bugs and 
report as normal?


Another example is one of the bugs is related to buses - if one of a 
list { SCL SCK ~CS RD} all items after and including CS have an over bar.


Brian

On 2020-01-27 7:14 p.m., Jon Evans wrote:
Can you reproduce these same issues on the master branch? Either the 
latest master, or the point on master at which your custom branch 
splits (i.e. the most recent rebase point)
Doing so will absolutely rule out that there is anything about your 
branch related, and also make it easier to figure out what (master) 
commit is the relevant origin point for the bug report.


-Jon

On Mon, Jan 27, 2020 at 7:10 PM Brian Piccioni 
mailto:br...@documenteddesigns.com>> wrote:


Hello

I have been using Kicad while working on re-annotation (hopefully
Alexander's merge request will soon be accepted and I can dust off
mine).

I have been using branches of the current master. I have noticed a
few
issues which I think are significant and not related to
Alexander's work
(or mine).

For example, when I hit F8 in eeSchema to update my PCB it resolutely
demands to update some of my resistor network symbols unless I select
"Update footprint associations by existing references". This seems to
happen no matter how many time I let it update those RNs.

Should I used the standard bug reporting system or is there a special
way to deal with these?

Brian


___
Mailing list: https://launchpad.net/~kicad-developers
Post to     : kicad-developers@lists.launchpad.net
<mailto:kicad-developers@lists.launchpad.net>
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Proper way to report bugs on branches

[Brian Piccioni]

Hello

I have been using Kicad while working on re-annotation (hopefully 
Alexander's merge request will soon be accepted and I can dust off mine).


I have been using branches of the current master. I have noticed a few 
issues which I think are significant and not related to Alexander's work 
(or mine).


For example, when I hit F8 in eeSchema to update my PCB it resolutely 
demands to update some of my resistor network symbols unless I select 
"Update footprint associations by existing references". This seems to 
happen no matter how many time I let it update those RNs.


Should I used the standard bug reporting system or is there a special 
way to deal with these?


Brian


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] What happened to buses in eeschema?

[Brian Piccioni]

Hello

I picked up one of my old designs to update it and ran DRC in eeschema. 
I got a whole bunch of errors regarding buses


ErrType(15): More than one name given to this bus or net
ErrType(19): Invalid connection between bus and net items
ErrType(16): Net is graphically connected to a bus but not a bus member

etc.

Also, adding wire to bus connections ( "/" ) gives me a dot instead of a 
bus entry although the menu icon shows a bus entry. Same for bus to bus.


I am using my own compiled version of eeSchema (see below) but I didn't 
touch anything to do with the editor, bus entries, etc, just re-annotation.


I guess this is some sort of "work in process" but it would be helpful 
to find a reference on how to do buses the new way or go back to the old 
way.


Any suggestions?

Brian


Application: Eeschema
Version: 5.99.0-unknown, release build
Libraries:
    wxWidgets 3.0.4
    libcurl/7.67.0 OpenSSL/1.1.1d (Schannel) zlib/1.2.11 brotli/1.0.7 
libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.1.1) nghttp2/1.39.2
Platform: Windows 8 (build 9200), 64-bit edition, 64 bit, Little endian, 
wxMSW

Build Info:
    Build date: Jan 12 2020 10:51:16
    wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8)
    Boost: 1.71.0
    OpenCASCADE Community Edition: 6.9.1
    Curl: 7.67.0
    Compiler: GCC 9.2.0 with C++ ABI 1013

Build settings:
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_PYTHON3=OFF
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_WXPYTHON_PHOENIX=OFF
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=ON

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Issues with clang-format

[Brian Piccioni]

I know this isn't a "help me program" mailing list but given the number 
of formatting issues which I have caused in my merge requests I figure 
it would be better if I could get this solved.


I am on Msys64 on Windows 10 platform


I followed the instructions 
herehttps://docs.kicad-pcb.org/doxygen/md_Documentation_development_coding-style-policy.htmland 
I get no complaints.


I don't seem to get any messages when I run git commit so I don't know 
if it is trying to check my formatting.


When I run the suggested line

git check-format

I get "no modified files to format" if I run it after git commit

or I get an error message

    Traceback (most recent call last): File 
"C:/msys64/mingw64/bin/git-clang-format", line 579, in main()
        File "C:/msys64/mingw64/bin/git-clang-format", line 154, in 
main cd_to_toplevel()
            File "C:/msys64/mingw64/bin/git-clang-format", line 336, in 
os.chdir(toplevel)
                FileNotFoundError: [WinError 3] The system cannot find 
the path specified: '/home/bjpic/brian_renum/kicad'


If I run it before git commit. I assume the "cannot find the path" error 
is because it is actually trying to do something but I have no idea how 
to fix this.


Every other aspect of git seems to work.

I have managed to fix clang-format in my IDE (I think) but obviously it 
would be better if git did it so I could not forget.


Thanks again.


Brian


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Request for Issue assignments

[Brian Piccioni]

Hello

Since I have found and suggested fixes for two issues, it occurred to me 
my limited skills with Kicad

development might be useful to fixing issues.

I am not good with UI design and probably would have limited value with 
esoteric bugs but I'd like to

offer myself for assignments.

Brian


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] What is the right build target to produce an installation zip.

[Brian Piccioni]

Hello

This is on Windows. I have been using make -install but this copies 
files to the Msys directories.


How do I make a file I can unzip to/install to my Windows programs 
directory?



Thanks



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Geographical reannotation complete and avaiable for test

[Brian Piccioni]

Seth

Thanks!

I will start working on the mysteries of a merge request shortly. I want 
to make sure I have all my ducks in a row so I don't waste anybody's time.


This is the first time I have collaborated on a software project of any 
kind, let alone a big one like Kicad.


Brian

On 2020-01-09 9:39 a.m., Seth Hillbrand wrote:

On 2020-01-09 06:21, Brian Piccioni wrote:

I have been working for several months to incorporate RenumKicadPCB 
functionality inside Kicad. Meanwhile, Alexander Shuklin has done 
most of the heavy lifting by writing back-annotation into Kicad which 
does all of the error checking, etc., necessary for re-annotation to 
work. Without his help I don't think I could have done this.


Geographical re-annotation is under PCBNew/Tools. It should provide 
the same functionality as RenumKicadPCB but from within Kicad. I am 
hopeful I can submit a merge request which will be accepted so it 
will become part of the distribution. Of course, given my modest c++ 
skills I suspect that will not go smoothly!


I have tested the code with all the projects I used to test 
RenumKicadPCB and it appears to work. Besides renumbering correctly, 
it seems to detect project errors such as modules in the PCB which 
are not in the schematic, etc.


I would be grateful if people who are interested in this 
functionality would help test it and let me know if they have any 
problems or suggestions.


The source code is at

https://gitlab.com/BrianAtDocumentedDesigns/kicad/commits/reannotate

Thanks

Brian


Hi Brian-

This sounds like great news.  If you create a MR on GitLab we will 
better be able to look it over.  You can prefix it with "WIP:" to mark 
it work in progress.


-Seth


Seth Hillbrand
KiCad Services Corporation
https://www.kipro-pcb.com
+1 530 302 5483 | +1 212 603 9372


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Geographical reannotation complete and avaiable for test

[Brian Piccioni]

I have been working for several months to incorporate RenumKicadPCB 
functionality inside Kicad. Meanwhile, Alexander Shuklin has done most 
of the heavy lifting by writing back-annotation into Kicad which does 
all of the error checking, etc., necessary for re-annotation to work. 
Without his help I don’t think I could have done this.


Geographical re-annotation is under PCBNew/Tools. It should provide the 
same functionality as RenumKicadPCB but from within Kicad. I am hopeful 
I can submit a merge request which will be accepted so it will become 
part of the distribution. Of course, given my modest c++ skills I 
suspect that will not go smoothly!


I have tested the code with all the projects I used to test 
RenumKicadPCB and it appears to work. Besides renumbering correctly, it 
seems to detect project errors such as modules in the PCB which are not 
in the schematic, etc.


I would be grateful if people who are interested in this functionality 
would help test it and let me know if they have any problems or suggestions.


The source code is at

https://gitlab.com/BrianAtDocumentedDesigns/kicad/commits/reannotate



Thanks


Brian

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] How do I refresh PCB or Schematic window

[Brian Piccioni]

Hello & thanks for the help.

I open a dialog in PCBNew to run my geographical reannotation code and 
all seems to work, however,
I can't figure out how to get the PCBNew or eeSchema displays to refresh 
to show the result.  I can
zoom in/zoom out manually and the new values appear but I would the 
refresh to automatically.


I have tried

m_frame->GetToolManager()->RunAction(ACTIONS::zoomRedraw, true);
    m_frame->HardRedraw();
    m_frame->RefreshCanvas();
    m_frame->GetCanvas()->ForceRefresh();
    m_frame->GetCanvas()->Refresh();

And none seem to work.

Any advice would be appreciated.

Brian


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Advice on merge request

[Brian Piccioni]

Eeli

I have to re-create my fork based on Alexander's Gitlab fork because 
mine is based on his Github fork, which is a generation behind his 
Gitlab fork (isn't migrations wonderful?).


Then I have to run it through a style checker. Once I do that (probably 
a few days, I'll push it out and let everybody know).


Thanks for the input

Brian

On 2020-01-04 4:48 p.m., Eeli Kaikkonen wrote:
I have already added Alexander's fork as a "remote" for my local clone 
of kicad. When I'm back home, I can add yours. You have already forked 
from Alexander - if you have a local branch based on Alexander's 
"backannotate" which you want to publish for testing, just push it to 
your remote, i.e. to your gitlab fork. Then I can see it and fetch, 
compile and test it, just like I did for Alexander's backannotate. Jon 
told you what happens after Alexander's is merged to the kicad master 
(I don't have experience to give you advice about that).


I hope everyone - including the lead developers - follow this workflow 
when they want their code tested: add a clearly named branch to their 
gitlab fork of kicad. It can be found easily by following the "Fork" 
number link from the official kicad repo and won't get lost in a 
mailing list or something like that.


Merge requests are even easier to find. You can add "WIP:" to the name 
of a merge request - it means "work in progress" and prevents merging 
before you remove "WIP:" from the name, so you can work on your merge 
request and get feedback before it's ready to be merged. But I suppose 
a WIP merge request is recommended only for code which is actually 
expected to be actually merged later, not for all experiments.


Eeli Kaikkonen


On Sat, Jan 4, 2020 at 7:00 PM Jon Evans <mailto:j...@craftyjon.com>> wrote:


I see no problem directing people to your fork/testing branch to 
compile and test on their own.



On Sat, Jan 4, 2020 at 11:43 AM Brian Piccioni
mailto:br...@documenteddesigns.com>>
wrote:

Hello

I have been working on Geographical reannotation. It uses the
code
Alexander Shuklin created for back annotation. I understand
Alexander's
merge request has been pending (yes, I know it is holidays)
but now I
don't know how to proceed because my code depends on his code.

Any suggestions would be welcomed.

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Advice on merge request

[Brian Piccioni]

Hello

I have been working on Geographical reannotation. It uses the code 
Alexander Shuklin created for back annotation. I understand Alexander's 
merge request has been pending (yes, I know it is holidays) but now I 
don't know how to proceed because my code depends on his code.


Any suggestions would be welcomed.

Also, I have a user base of people who have been using my standalone 
RenumKicadPCB utility. I would like to direct them to my fork and/or 
pre-compiled Windows exes so they can help test it. It turns out there 
are lots of ways a project can be made with reference designation issues 
in the schematic and/or PCB so I would like to be sure I catch them all. 
I would, of course, flag that this is not an official Kicad release, etc..


Any objections/suggestions?

thanks

Brian Piccioni


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Issues with Github/Gitlab migration

[Brian Piccioni]

Hello

I thought I would give a heads up to anybody else having this issue:

I was provided with a Gitlab account which used the same login, etc., at 
my Github account. Although the account allowed me to examine things 
like Kicad source I could not clone or fork any repository: either it 
would simply fail after crunching away for a few minutes (if cloning) or 
claim the fork already exists (if forking). I searched for a while for a 
fix but found none so I ended up deleting the Gitlab account and 
re-creating it. This seemed to fix the problem.


So if anybody else has trouble with their new Gitlab account after the 
migration they might try that.



Brian Piccioni


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Back annotate references from PCB

[Brian Piccioni]

As a complete amateur user I change footprints in layout all the time in order to experiment with spacing, how things look, modfy footprints, etc.. Sometimes you want to make a change to a library part, flag that part as a new part (I.e. BriansSOIC8), then update all SOIC8 in the layout.  The way I see it (and, again, as an amateur) is that making a change in the PCB then having to manually update the schematic is fraught with potential issues. Since we *can* change the footprint in the PCB it should be as easy as possible to then update the schematic with no error. Nobody would be forcing anybody to change their workflow: just making whatever method works best work better. Brian From: Jon EvansSent: December 1, 2019 3:06 PMTo: Andy PetersCc: KiCad DevelopersSubject: Re: [Kicad-developers] Back annotate references from PCB From another professional user, I have to disagree. There are at least two cases I can think of where changing the footprint during layout is important: 1) In my experience, it's common to keep multiple variants of IPC standard SMD footprints, especially for passives. By default, we specify the "medium density" variant of an 0402 resistor or capacitor, but in some cases (critical controlled impedance, small BGA decoupling, etc) we may decide during layout that it is best to switch to the "high density" (minimal pad size) version of the 0402. 2) similarly, we might have a design with 0402 passives that we determine during layout needs to switch to 0201 in some cases to make proper layout possible. In this case, it's indeed an entirely different part, not just a variant footprint for the same part, but the decision is made at layout time and back-annotated onto the schematic (which will then drive the BOM).  Neither of these workflows is particularly easy in KiCad today, but I'm mostly talking about my experience with commercial tools here.  This isn't necessarily me saying that these workflows need to be supported by this current back-annotation effort (I think they also depend on several other large future changes), just saying they are valid in my opinion.  -Jon On Sun, Dec 1, 2019, 14:46 Andy Peters  wrote:> On Dec 1, 2019, at 6:59 AM, Vesa Solonen  wrote:> > Eeli Kaikkonen kirjoitti 1.12.2019 klo 0.08:> >> BTW, about the possibility of changing the footprint - I have always found>> being able to change footprints in pcbnew strange because then it's out of>> sync with the schematic and it has to be changed in the schematic manually>> and updated to layout anyways. Being able to update it from the layout to>> the schematic looks like an obvious missing feature.> > I would consider it a missing feature that the schematic-layout path is> anything but completely bilateral. Everything should be editable and> propagated both ways and question remains does it even make sense to> have different files. If a footprint is added or gate/pin swapped on the> PCB side the changes should show as rubber bands on the schematic, just> like it works from update PCB form schematic. Proper back annotation is> a good middle target, but having complete seamless bilateral data and> action model is way more usable albeit complex.I want to add the perspective of a professional user. We don’t change footprints in the layout editor. Why? Because NE5532D in SOIC-8 is not the same part as NE5532P in PDIP-8. Going backwards in this manner blows up the BOM, unless you can work out some way of back-annotating a different part number for each instance of this device without making mistakes. The footprints in pcbnew have no knowledge of a part number, so there is no way of changing that in layout and bringing it back to schematic.(I assume that most people use the schematic as the “master source,” and BOMs and such are generated from it, not layout.)The "house part number” decouples a thing on your schematic from what you order. There are a dozen resistor manufacturers, so rather than putting “manufacturer=Panasonic” and “base part number=ERJ-“ in the symbol, you can just put a house part number in a PN field and then a downstream database can map it to what your purchasing person can order.Anyway, it’s a lot easier to update the schematic with the new part and then forward-annotate, and this keeps both schematic and layout in sync.Pin-swapping and gate-swapping are much more important. The pin swapping makes for an interesting problem, which is making sure the resulting schematic isn’t a mess. Most likely an informal (or required) “rule” would be that you draw a net from each pin that can be swapped and you give them net labels, but you don’t draw that net to any other pin.Thanks to everyone involved in adding the back-annotation feature!-a___Mailing list: https://launchpad.net/~kicad-developersPost to     : kicad-developers@lists.launchpad.netUnsubscribe : https://launchpad.net/~kicad-developersMore help   : 

Re: [Kicad-developers] [PATCH] Fixes for Visual Studio / vcpkg build

[Brian Piccioni]

Jon Thanks so much! I am busy working with Alexander on renumbering so it may take me a few days to see if I can get it to work. Brian From: Jon EvansSent: November 29, 2019 9:19 PMTo: Brian PiccioniCc: KiCad DevelopersSubject: Re: [Kicad-developers] [PATCH] Fixes for Visual Studio / vcpkg build Hi Brian, I will try to write a better guide, especially if I can get a full (all options) KiCad build going rather than a minimal one. In the meantime, I'm attaching my CMakeSettings.json from VS2019 in case it's helpful.It has a hard-coded toolchain path that you'll have to check/update. I installed all the dependencies that were available in vcpkg, and then disabled whatever was left (ngspice, OCE, and python stuff)Then I set up that CMakeSettings and basically things work :) By the way, I pushed my patches from my earlier email, let me know if anyone has an issue with the change to the CMake script. Best,Jon On Sun, Nov 24, 2019 at 6:56 PM Brian Piccioni <br...@documenteddesigns.com> wrote:Jon Despite MSVC Community being from MS, I see some advantages in using it, namely that it is basically a one-package solution: no msys2, no loads of other tools that have to be updated, etc..  My lack of cmake-foo meant I hit a roadblock when trying to build an MSVC recipe. One time I got so far as to have it crap out on SSL or something like that but now I’m stuck much earlier. In any event I’m more than happy to experiment with whatever you’ve got, especially if you can provide some guidance. Brian From: Jon EvansSent: November 24, 2019 12:41 PMTo: KiCad DevelopersSubject: [Kicad-developers] [PATCH] Fixes for Visual Studio / vcpkg build Hi all, I got a build working using Visual Studio 2019 and vcpkg.Attached are three patches I needed to make so far.I'd appreciate some double-checking on these since cmake and wxwidgets can be a bit perilous. Thanks,-Jon  

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] Fixes for Visual Studio / vcpkg build

[Brian Piccioni]

Jon Despite MSVC Community being from MS, I see some advantages in using it, namely that it is basically a one-package solution: no msys2, no loads of other tools that have to be updated, etc..  My lack of cmake-foo meant I hit a roadblock when trying to build an MSVC recipe. One time I got so far as to have it crap out on SSL or something like that but now I’m stuck much earlier. In any event I’m more than happy to experiment with whatever you’ve got, especially if you can provide some guidance. Brian From: Jon EvansSent: November 24, 2019 12:41 PMTo: KiCad DevelopersSubject: [Kicad-developers] [PATCH] Fixes for Visual Studio / vcpkg build Hi all, I got a build working using Visual Studio 2019 and vcpkg.Attached are three patches I needed to make so far.I'd appreciate some double-checking on these since cmake and wxwidgets can be a bit perilous. Thanks,-Jon 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Back annotate references from PCB

[Brian Piccioni]

It has occurred to me (Alexander please chime in) that once back annotation has been solved subject to all the issues raised by Wayne and others that it would be a general solution. Of course, this would end up being a sizeable change to Kicad since the various edit functions, etc., who have to be modified to incorporate the feature. Like you I often fiddle with different packages and values and I typically switch to eeSchema, make the change, then hit F8 to update the PCB. It seems to me it would be easier for the appropriate changes to simply be reflected back to the schematic. Brian From: Eeli KaikkonenSent: November 23, 2019 12:56 PMTo: kicad-developersSubject: Re: [Kicad-developers] Back annotate references from PCB   la 23. marrask. 2019 klo 14.52 Brian Piccioni (br...@documenteddesigns.com) kirjoitti:By having a single integrated tool analogous to “Update PCB From Schematic” can ensure coherency.Can this do other kinds of changes than just annotation? I'm thinking of changing the footprint or value. For example I could use Change Footprint feature in pcbnew and propagate that change to eeschema. That's not so difficult to do in eeshcema and update the board, but often it would feel much more natural to e.g. test if 0402 R package would be physically better for some situation than 0603 and then update the shcematic based on the board if it fits. Eeli Kaikkonen 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Back annotate references from PCB

[Brian Piccioni]

Indeed. I’ve had geographical annotation in c++ working for some time now. Having different commands in PCBNew and eeSchema could lead to all sorts of nightmares. During testing I found myself with “half done” projects where I had inadvertently got the annotation on the PCB and schematics out of synch. This is a complete nightmare to fix even on a small board. In fact the reason I started the work was because geographic annotation is a huge amount of work manually and back annotation is not just a lot of work but really easy to screw up. By having a single integrated tool analogous to “Update PCB From Schematic” can ensure coherency. From: Alexander ShuklinSent: November 23, 2019 5:44 AMTo: Dino GhilardiCc: kicad-developersSubject: Re: [Kicad-developers] Back annotate references from PCB Well,I cannot make back annotation in python, it has to be c++. Actuallythat's why I jumped on that problem. Because once it's done you canuse python for geometrical annotation. Actually I've seen pythonscript to do that, but it parses sch file like plain text, which isbad.Python scripts can do powerful job, and as I see, some very uncommonstuff better to have as python plugins, and something general instandard GUI. I would say that geometrical annotation is more or lesscommon stuff, and I would like to see it integrated in KiCad itself.But I'm not the person who supposed to decide that. Anyway, Brianalready busy with doing that in C++, so I believe that's alright.If there will be some dialog with just common geometrical annotation,you still can use python scripts to do some specific one. On Sat, 23 Nov 2019 at 13:30, Dino Ghilardi  wrote:> > On 23/11/19 10:05, Alexander Shuklin wrote:> > Hi Dino,> > I would say "back annotation" and "geographical annotation" are just> > different things. We with Brian plan to implement both of them.> > Basically when you want to get references from board and apply them to> > corresponding schematic, that back annotation. If you re-annotate> > footprints in PCB according it's position that's geographical> > annotation. I think we will do geographical annotation, which will> > call back annotation straight away.> > Sometimes there's a reason to have back-annotation without> > geographical annotation: once I was asked by our designer "to rename> > that, that and that one connector", for it would correspond his wires> > numbers and documentation. Of course you can still do it manually, but> > if back annotation will be implemented, why not to let user call it> > alone?> >> > Good point. Having two tools at the price of one would be better than> have one tool only (and having back annotation function exported to> python would open the door to user's personal custom back-annotate scripts).> By the way: How about implementing back annotation in kicad itself and> the "geographical annotation" as a python action-plugin (that calls back> annotation on all selected components)? That would enable users to> create their custom back-annotation scripts with different> "unconventional geometries" easily, just modifying the original script> source.> Drawback: I don't know which of the two  methods ("all in c++" or "core> functions in c++ and higher level as a script") will be easier to> implement/debug.> > Cheers,> Dino.> > > > > > >  ___Mailing list: https://launchpad.net/~kicad-developersPost to : kicad-developers@lists.launchpad.netUnsubscribe : https://launchpad.net/~kicad-developersMore help   : https://help.launchpad.net/ListHelp 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Building Kicad on Windows 10/Eclipse/Msys2

[Brian Piccioni]

Eeli and Carsten Thanks for the additional info.  The reason I was working of the git information was in response to Simon earlier in this thread who suggested it. If git was the way to go I wanted to include it because people like me find that there is typically plenty of instructions regarding the use of developmentTools on things like Linux but very little on Windows/msys. Moreover, accomplished developers know this stuff implicitly whereas the rest of us do not. Same goes for things like cmake, etc.. Brian From: Eeli KaikkonenSent: November 23, 2019 4:35 AMTo: Carsten SchoenertCc: KiCad DevelopersSubject: Re: [Kicad-developers] Building Kicad on Windows 10/Eclipse/Msys2   la 23. marrask. 2019 klo 11.11 Carsten Schoenert (c.schoen...@t-online.de) kirjoitti:Hello Eli,Am 23.11.19 um 10:03 schrieb Eeli Kaikkonen:> BTW, it's unnecessarily verbose to say "git pull origin master". Just> "git pull" is enough when you are in the local master branch.no it's not.Your statement is only true if the user hasn't added one ore moreremotes. If you have only one remote configured git tries to be smartand is substitute the rest for the command by the obviously logical value.So, if you want to be safe than the full command line is correct. Oh yeah. I took a shortcut and thought about my normal situation when I have checked out a branch (master), although I added " when you are in the local master branch". Anyways it's best to give as simple instructions for getting the source code as possible and leave everything else for homework for the user. Eeli (with 2 e's) 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Building Kicad on Windows 10/Eclipse/Msys2

[Brian Piccioni]

Can Simon or somebody who understands such things verify that the following is correct so I can update my recipe? Thanks == In Mingw64 git clone https://github.com/KiCad/kicad-source-mirror.git This will create a local repository directory called kicad-source-mirror At any time you can update the repository by cd kicad-source-mirrorgit pull origin master  Note that this will leave files which are in kicad-source-mirror but not in the kicad source repository unaffected.*** However *** they will over write your versions of those files! So if you edit cmakelists.txt or any other Kicad source file those edits will be lost.   From: Simon RichterSent: November 22, 2019 6:46 AMTo: kicad-developers@lists.launchpad.netSubject: Re: [Kicad-developers] Building Kicad on Windows 10/Eclipse/Msys2 Hi, On Thu, Nov 21, 2019 at 09:30:48PM -0500, Brian Piccioni wrote: > Download the Kicad source files from https://github.com/KiCad/kicad-source-mirror> Untar or unzip into /home/kicad-source-mirror-master This probably should be "use git to get the source tree", otherwise I thinkthis might be a valuable addition to the website.    Simon ___Mailing list: https://launchpad.net/~kicad-developersPost to : kicad-developers@lists.launchpad.netUnsubscribe : https://launchpad.net/~kicad-developersMore help   : https://help.launchpad.net/ListHelp 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Back annotate references from PCB

[Brian Piccioni]

 you back annotate that there is a one to one>>>> correlation between board footprint sheet paths and schematic symbol>>>> sheet paths.>>>> >>>> Cheers,>>>> >>>> Wayne>>>> >>>> On 11/22/19 1:18 AM, Alexander Shuklin wrote:>>>>> Hi Wayne,>>>>> thanks for answer.>>>>> Hopefully I will show you commit soon, so team could look, check and>>>>> suggest something about that. I'm aware about differences between>>>>> PCBnew and eeschema and just now I'm writing algorithm that will check>>>>> it.>>>>> Do you mean that some schematic file(.sch) can be used in more than>>>>> one projects? So, I don't plan to change the unique IDs and those>>>>> components will still be linked to each other, but if references will>>>>> be changed it will make a mess in another project.>>>>> I have 3 ideas how I can deal with that:>>>>> 1) create a dialog, which will say something like "please make sure,>>>>> that your schematic files are not shared between different projects">>>>> 2) I can go by recently opened projects, parse schematics in each of>>>>> them and look if any schematic uses sheet, which already in use in>>>>> current project. I'm now sure, but I would presume, that it will be>>>>> quite slow.>>>>> 3) To hold information in what project this particular schematics was>>>>> used. So that's should be saved in .sch file then. But I don't think>>>>> that information will be very valuable.>>>>> >>>>> >>>>> On Thu, 21 Nov 2019 at 00:07, Wayne Stambaugh  wrote:>>>>>> >>>>>> On 11/7/19 5:06 AM, Alexander Shuklin wrote:>>>>>>> Hi,>>>>>>> is it alright to answer anybody in one letter?>>>>>>> First of all, don't take amiss if I keep silence for a day, as I have>>>>>>> 2 little children and at the best case I have couple of hours a day on>>>>>>> my own.>>>>>>> >>>>>>> On Wed, 6 Nov 2019 at 16:27, Wayne Stambaugh  wrote:>>>>>>>> Complex schematic hierarchies (using the same schematic more than once in a design) always trips up new developers.>>>>>>> Can you please explain a bit more? I know that you can use>>>>>>> hierarchical sheets, so there will be more than one sch files in the>>>>>>> schematic. And there's also "multi-symbols" which have few eeschema>>>>>>> symbols but one footprint. I'm not quite understand what means "using>>>>>>> the same schematic more than once in a design", as every symbol has>>>>>>> unique ID. Is it something else I'm not aware of?>>>>>> >>>>>> Yes, every symbol has a unique path ID but that doesn't mean that the>>>>>> board and the schematic will always be in sync so this is where issues>>>>>> come into play.  There also can be unique IDs from other projects>>>>>> because schematics can be shared between projects so you have to be>>>>>> careful not to break all of these cases.>>>>>> >>>>>>>> You'll want to take a close look at KIWAY::ExpressMail() and KIWAY_PLAYER::KiwayMailIn()>>>>>>> Ok, I'll look at that. I think I've seen that in footprints back annotation.>>>>>>>> This is unfortunate.  Being able to work directly with on of the lead developers would have made this task a lot easier to understand.  You are always free to reach out for help on this mailing list.>>>>>>> Thanks for that. Actually now i think to join FOSDEM, but I need visa>>>>>>> and I'm not sure yet.>>>>>>>> Asking first prevents you from working on something that someone else may already be working on and writing code that would be immediately rejected>>>>>>> Actually I already made that mistake, when made board statistics>>>>>>> dialog. It was accepted, but I felt myself really stupid.>>>>>>>> Good luck and thank you for your interest in contributing to KiCad.>>>>>>> Thanks! I will try hard to match coding and git polices.>>>>>>> >>>>>>> On Wed, 6 Nov 2019 at 17:24, Jon Evans  wrote:>>>>>>>> Eeschema now keeps its internal net state up to date 

Re: [Kicad-developers] Building Kicad on Windows 10/Eclipse/Msys2

[Brian Piccioni]

Simon  I have never figured out how to use git to fetch sources. If you can direct me to something like a Linux command line example I would appreciate it otherwise I’ll set it as a background task. Brian From: Simon RichterSent: November 22, 2019 6:46 AMTo: kicad-developers@lists.launchpad.netSubject: Re: [Kicad-developers] Building Kicad on Windows 10/Eclipse/Msys2 Hi, On Thu, Nov 21, 2019 at 09:30:48PM -0500, Brian Piccioni wrote: > Download the Kicad source files from https://github.com/KiCad/kicad-source-mirror> Untar or unzip into /home/kicad-source-mirror-master This probably should be "use git to get the source tree", otherwise I thinkthis might be a valuable addition to the website.    Simon ___Mailing list: https://launchpad.net/~kicad-developersPost to : kicad-developers@lists.launchpad.netUnsubscribe : https://launchpad.net/~kicad-developersMore help   : https://help.launchpad.net/ListHelp 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Building Kicad on Windows 10/Eclipse/Msys2

[Brian Piccioni]

Based on feedback received after I published a recipe for building Kicad with QT Creator, I managed to figure out how to build it on Windows 10 with Eclipse on Msys2.  I have posted that recipe here documenteddesigns.com/2019/11/22/building-kicad-on-windows-10-with-eclipse-msys2/ but, for posterity, repeat it below. I came very close to figuring out a build on Microsoft Visual Studio Community Edition but I’ll put that aside for the moment. MSVC is my preferred environment because it is pretty much all bundled.   Here we go. Msys2 InstallationInstall Msys2 (Download Msys2 http://repo.msys2.org/distrib/x86_64/msys2-x86_64-20161025.exe )Open a Mingw64 terminal ( msys64/mingw64.exe ) as this only seems to work if you open a mingw64 window.pacman -SyuuAnswer yes to remove conflicts. Close the window via task manager when done.pacman -Syuu This takes a long time. Close the window via task manager when done.pacman -Syuu To make sure all is up to datecopy and paste these lines into Mingw64pacman -S base-devel \git \mingw-w64-x86_64-cmake \mingw-w64-x86_64-doxygen \mingw-w64-x86_64-gcc \mingw-w64-x86_64-python2 \mingw-w64-x86_64-pkg-config \mingw-w64-x86_64-swig \mingw-w64-x86_64-boost \mingw-w64-x86_64-cairo \mingw-w64-x86_64-glew \mingw-w64-x86_64-curl \mingw-w64-x86_64-wxPython \mingw-w64-x86_64-wxWidgets \mingw-w64-x86_64-toolchain \mingw-w64-x86_64-glm \mingw-w64-x86_64-oce \mingw-w64-x86_64-ngspice \mingw-w64-i686-toolchain mingw-w64-x86_64-toolchainInstall EclipseIn Windows install Eclipse CDT for Windows 64 bit see https://www.eclipse.org/downloads/packages/release/2019-09/r/eclipse-ide-cc-developersYou need to edit the eclipse.ini file and change the line -Xmx1024mto-Xmx2048m Or -Xmx4096m This increases the heap for Java so you don't get out of memory errors.Save the eclipse.ini and load eclipse to see if it works.Download and install Kicad Source FilesIn the mingw64 terminal and sure you can run mingw32-make.exe. If not, update the dos/windows path until you can.Note: this assumes you want the development build. If you want a release build, download that, for example kicad-5.1.4.tar.xz and use that name (kicad-5.1.4.tar.xz) insteead of kicad-source-mirror-master.Download the Kicad source files from https://github.com/KiCad/kicad-source-mirror Untar or unzip into /home/kicad-source-mirror-masterCreate a directory such as eclipse-kicad. This will be your build directory.cd /home/kicad-source-mirror-master/eclipse-kicadCopy and paste these lines into Mingw64cmake -DCMAKE_BUILD_TYPE=Debug \-G "Eclipse CDT4 - Unix Makefiles" \-DCMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT=TRUE \-DCMAKE_PREFIX_PATH=C:/msys64/mingw64 \-DCMAKE_INSTALL_PREFIX=C:/msys64/mingw64 \-DDEFAULT_INSTALL_PATH=C:/msys64/mingw64 \-DMSYS=TRUE \../kicad-source-mirror-masterThis takes a few minutes but you only do it once.Note that the -DCMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT=TRUE switch creates a link between the build and source directories for eclipse. This allows for error highlighting, etc..You can test the build with make -j install (Note: the -j means use as many cores as you can and reduces compile time on my system by 70%). This process may take hours: on my gaming laptop it takes about 30 minutes if I use the -j option.In EclipseFile->Import General->Existing Projects into Workspace Select Root Directory as/home/kicad-source-mirror-master/eclipse-kicadWait for the indexing to complete (this will take some time)select debug configuration (at the top near the red square)Right click on project root select Build Targets go to the bottom and select Install. First time, edit and set make to C:\msys64\usr\bin\make.exe -j then click build.To rebuild select the project root and hit F9. Note that it you don't select F9 or Build Targets Install it will not copy the project in the appropriate bin directory.Note that you can access the source files in Eclipse by clicking [Source Directory] in the Eclipse project and you can rebuild by clicking the (*) Build Targets group.I have not yet figured out how to integrate the source, build, and debug functions, however I can use the Eclise standalone debugger (see https://wiki.eclipse.org/CDT/StandaloneDebugger ) to debug pretty much anyexecutable which has been compile with debug info as long as I also have the source files.I will update this with any corrections or if, as, and when, I figure out integrated debugging.

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Recipe for building Kicad on QT-Creator on Msys2 (Windows)

[Brian Piccioni]

Thanks – I’ll have a look! From: Nick ØstergaardSent: November 18, 2019 2:29 PMTo: Dmitry RezvanovCc: KiCad DevelopersSubject: Re: [Kicad-developers] Recipe for building Kicad on QT-Creator on Msys2 (Windows) FWIW there are some tips on using eclipse athttps://gist.github.com/johnbeard/895bad60e4716f7f9c77 On Mon, 18 Nov 2019 at 14:21, Dmitry Rezvanov  wrote:> > BTW, I'm programming and debugging Kicad in Eclipse.> If necessary, I can create instruction for tuning.> > > ___> Mailing list: https://launchpad.net/~kicad-developers> Post to : kicad-developers@lists.launchpad.net> Unsubscribe : https://launchpad.net/~kicad-developers> More help   : https://help.launchpad.net/ListHelp ___Mailing list: https://launchpad.net/~kicad-developersPost to : kicad-developers@lists.launchpad.netUnsubscribe : https://launchpad.net/~kicad-developersMore help   : https://help.launchpad.net/ListHelp 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Recipe for building Kicad on QT-Creator on Msys2 (Windows)

[Brian Piccioni]

I would very much appreciate that and I think many devs would as well. Some of us are not as experienced as others ... From: Dmitry RezvanovSent: November 18, 2019 8:22 AMTo: kicad-developers@lists.launchpad.netSubject: Re: [Kicad-developers] Recipe for building Kicad on QT-Creator on Msys2 (Windows) BTW, I'm programming and debugging Kicad in Eclipse.If necessary, I can create instruction for tuning.  ___Mailing list: https://launchpad.net/~kicad-developersPost to : kicad-developers@lists.launchpad.netUnsubscribe : https://launchpad.net/~kicad-developersMore help   : https://help.launchpad.net/ListHelp 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Recipe for building Kicad on QT-Creator on Msys2 (Windows)

[Brian Piccioni]

I would very much appreciate that and I think the community would as well!  From: Dmitry RezvanovSent: November 18, 2019 8:22 AMTo: kicad-developers@lists.launchpad.netSubject: Re: [Kicad-developers] Recipe for building Kicad on QT-Creator on Msys2 (Windows) BTW, I'm programming and debugging Kicad in Eclipse.If necessary, I can create instruction for tuning.  ___Mailing list: https://launchpad.net/~kicad-developersPost to : kicad-developers@lists.launchpad.netUnsubscribe : https://launchpad.net/~kicad-developersMore help   : https://help.launchpad.net/ListHelp 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Recipe for building Kicad on QT-Creator on Msys2 (Windows)

[Brian Piccioni]

Mario Sure! https://documenteddesigns.com/2019/11/17/building-kicad-with-qt-creator-on-windows-msys2/ BTW I will probably revise because I forgot a few easy details and want it to be complete. Brian From: Mário LuzeiroSent: November 18, 2019 8:10 AMTo: Brian Piccioni; kicad-developers@lists.launchpad.netSubject: Re: [Kicad-developers] Recipe for building Kicad on QT-Creator on Msys2 (Windows) Hi Brian, it looks your wordpress URL is not OK.Also, your text was clipped from the mailling list online history:https://lists.launchpad.net/kicad-developers/msg42635.html probably because your are pointing to a .exe file :/ Could you send again the correct URL for the documented procedure you did? Mario Luzeiro From: Kicad-developers  on behalf of Brian Piccioni Sent: 17 November 2019 15:04To: kicad-developers@lists.launchpad.netSubject: [Kicad-developers] Recipe for building Kicad on QT-Creator on Msys2    (Windows) In case anybody is interested I managed to use the QT-Creator IDE to build Kicad on Windows. I documented the procedure here https://wordpress.com/post/documenteddesigns.com/483. But for posterity (and to make it easier to find) I’ve included it below.  Note that this only seems to work with the Msys2 version of QT-Creator, not the Windows version of QT-Creator even if Msys2 is installed. Unfortunately this took a day and a half to figure out. I almost succeed with the QT-Creator on Windows (I actually got about 33% through the compile) but, as I mentioned I forgot to document what I done. First install Msys2 (see http://repo.msys2.org/distrib/x86_64/msys2-x86_64-20161025.exe ) Everything below is from a mingw64 terminal window. It does not seem to work if you pick from the Msys2 pop-up. I show 64 bit development because that is what is recommended. Similar steps would apply to a 32 bit development environment. There may be redundant or unnecessary steps in this recipe. I completely deleted Msys2 a few times and re-ran this procedure but there are only so many hours in a day. From the Mingw64 terminal (comments marked by //) pacman -Syuu //Answer yes to remove conflicts close the window via task manager when done pacman -Syuu //Takes a long time close the window via task manager when done pacman -Syuu //To make sure all is up to date Copy and paste the following lines into your Mingw64 terminal (all the way from pacman -S to the blank line) pacman -S base-devel \git \mingw-w64-x86_64-cmake \mingw-w64-x86_64-doxygen \mingw-w64-x86_64-gcc \mingw-w64-x86_64-python2 \mingw-w64-x86_64-pkg-config \mingw-w64-x86_64-swig \mingw-w64-x86_64-boost \mingw-w64-x86_64-cairo \mingw-w64-x86_64-glew \mingw-w64-x86_64-curl \mingw-w64-x86_64-wxPython \mingw-w64-x86_64-wxWidgets \mingw-w64-x86_64-toolchain \mingw-w64-x86_64-glm \mingw-w64-x86_64-oce \mingw-w64-x86_64-ngspicemercurial \cvs \p7zip \ruby \mingw-w64-i686-toolchain mingw-w64-x86_64-toolchain Now copy these lines one at a time (it may be possible to combine these with the above) pacman -S mingw-w64-i686-qt-creator mingw-w64-x86_64-qt-creatorpacman -S mingw-w64-x86_64-clangpacman -Syuu Run qtcreator to make sure it works then exit qtcreator. qtcreator Download source files eg kicad-5.1.4.tar.xz into a suitable location such as /home source files can be found at http://kicad-pcb.org/download/source/ then tar -xaf kicad-5.1.4.tar.xz Run qtcreator from the ming64 terminal (for some reason, it doesn’t work if you pin it to the taskbar) qtcreator Select Open File or Project and open the Kicad source directory. Wait for it to parse Note that QT will make its own build directory. This doesn’t seem to matter. Select Build, rebuild project. On my laptop it takes about 2 hours to build.   

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Recipe for building Kicad on QT-Creator on Msys2 (Windows)

[Brian Piccioni]

In case anybody is interested I managed to use the QT-Creator IDE to build Kicad on Windows. I documented the procedure here https://wordpress.com/post/documenteddesigns.com/483. But for posterity (and to make it easier to find) I’ve included it below. Note that this only seems to work with the Msys2 version of QT-Creator, not the Windows version of QT-Creator even if Msys2 is installed. Unfortunately this took a day and a half to figure out. I almost succeed with the QT-Creator on Windows (I actually got about 33% through the compile) but, as I mentioned I forgot to document what I done.First install Msys2 (see http://repo.msys2.org/distrib/x86_64/msys2-x86_64-20161025.exe )Everything below is from a mingw64 terminal window. It does not seem to work if you pick from the Msys2 pop-up. I show 64 bit development because that is what is recommended. Similar steps would apply to a 32 bit development environment.There may be redundant or unnecessary steps in this recipe. I completely deleted Msys2 a few times and re-ran this procedure but there are only so many hours in a day.From the Mingw64 terminal (comments marked by //)pacman -Syuu //Answer yes to remove conflicts close the window via task manager when donepacman -Syuu //Takes a long time close the window via task manager when donepacman -Syuu //To make sure all is up to dateCopy and paste the following lines into your Mingw64 terminal (all the way from pacman -S to the blank line)pacman -S base-devel \git \mingw-w64-x86_64-cmake \mingw-w64-x86_64-doxygen \mingw-w64-x86_64-gcc \mingw-w64-x86_64-python2 \mingw-w64-x86_64-pkg-config \mingw-w64-x86_64-swig \mingw-w64-x86_64-boost \mingw-w64-x86_64-cairo \mingw-w64-x86_64-glew \mingw-w64-x86_64-curl \mingw-w64-x86_64-wxPython \mingw-w64-x86_64-wxWidgets \mingw-w64-x86_64-toolchain \mingw-w64-x86_64-glm \mingw-w64-x86_64-oce \mingw-w64-x86_64-ngspicemercurial \cvs \p7zip \ruby \mingw-w64-i686-toolchain mingw-w64-x86_64-toolchainNow copy these lines one at a time (it may be possible to combine these with the above)pacman -S mingw-w64-i686-qt-creator mingw-w64-x86_64-qt-creatorpacman -S mingw-w64-x86_64-clangpacman -SyuuRun qtcreator to make sure it works then exit qtcreator.qtcreatorDownload source files eg kicad-5.1.4.tar.xz into a suitable location such as /home source files can be found at http://kicad-pcb.org/download/source/ thentar -xaf kicad-5.1.4.tar.xzRun qtcreator from the ming64 terminal (for some reason, it doesn’t work if you pin it to the taskbar)qtcreatorSelect Open File or Project and open the Kicad source directory. Wait for it to parseNote that QT will make its own build directory. This doesn’t seem to matter.Select Build, rebuild project. On my laptop it takes about 2 hours to build.  

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp