Re: [Kicad-developers] Lots of compile errors after recent source pull

[Ian McInerney]

Thanks, that is the line I was interested in and it confirms what I was
thinking - we aren't turning them on.

I reported this to upstream GCC on Sunday, and they have confirmed there is
a bug in the compiler where it is printing out the note statements when it
shouldn't (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96063). They have
fixed that for GCC 11, and I am hoping they pull the fix into GCC 10.2. I
will have to guard this warning against the GCC version I guess, but I am
waiting to see their reply about backporting it to 10.2 first.

-Ian

On Wed, Jul 8, 2020 at 1:05 AM  wrote:

> Ian,
>
> Sorry for the delay in getting this information.  I believe this is the
> info you wanted from the "compile_commands.json" file.  If not, I can
> always send you the entire 1.5 MB file.
>
> {
>   "directory": "C:/msys64/home/codelite-kicad-compile-test2/eeschema",
>   "command": "C:/msys64/mingw64/bin/c++.exe  -DDEBUG -DEESCHEMA
> -DGLM_FORCE_CTOR_INIT -DHAVE_STDINT_H -DKICAD_CONFIG_DIR=kicad
> -DKICAD_SPICE -DKICAD_USE_OCE -DUNICODE -DWXUSINGDLL -DWX_COMPATIBILITY
> -D_FILE_OFFSET_BITS=64 -D_UNICODE -D_USE_MATH_DEFINES
> -D__USE_MINGW_ANSI_STDIO=1 -D__WXMSW__
> @CMakeFiles/eeschema_kiface_objects.dir/includes_CXX.rsp  -fpermissive
> -Wall -Wsuggest-override -Wduplicated-branches -Wduplicated-cond
> -Werror=vla -Wimplicit-fallthrough=5 -Werror=return-type -Wshadow
> -Wsign-compare -Wmissing-field-initializers -Wempty-body -Wreorder
> -Wmismatched-tags -g3 -ggdb3 -fvisibility=hidden
> -fno-keep-inline-dllexport   -std=gnu++14 -o
> CMakeFiles/eeschema_kiface_objects.dir/dialogs/dialog_annotate.cpp.obj -c
> C:/msys64/home/kicad-compile-test2/kicad/eeschema/dialogs/dialog_annotate.cpp",
>   "file":
> "C:/msys64/home/kicad-compile-test2/kicad/eeschema/dialogs/dialog_annotate.cpp"
> }
>
>
>
>
> -Original Message-
> From: Ian McInerney 
> To: pjmo...@csi.com
> Cc: ian.s.mciner...@ieee.org ;
> kicad-developers@lists.launchpad.net  >
> Sent: Sun, Jul 5, 2020 4:52 am
> Subject: Re: [Kicad-developers] Lots of compile errors after recent source
> pull
>
> Yea, unfortunately the Windows headers love to have unscoped defines that
> are very common words, meaning anytime we try to use those we get conflicts
> (it is really annoying). JP fixed it yesterday in
> https://gitlab.com/kicad/code/kicad/-/commit/9e669db5b4bdeff7f057614a6c93067f7a8c7024.
>
>
> As for the warnings, can you please provide the command that is being used
> to compile one of the files that has the mismatched-tag warnings? You can
> find them by setting `-DCMAKE_EXPORT_COMPILE_COMMANDS=ON` in your CMake
> config, then looking inside compile_commands.json in the build directory
> for the filename. I would like to track down why your mingw build is
> warning in system headers when it shouldn't. In the meantime, I have
> reported the mismatched tags to libstdc++ upstream, so hopefully they can
> clean them up.
>
> -Ian
>
> On Sun, Jul 5, 2020 at 6:12 AM  wrote:
>
> Very hard to find the errors among the epic amount of long warning
> messages.  The full make would go a long time, then fail.  I'd start it
> again, it would go for some time, then fail again. Lather. Rinse.
> Repeat.
>
> Finally saw these error messages:
>
> C:/msys64/mingw64/include/c++/10.1.0/system_error:278:10: note:
> 'std::error_condition' defined as 'struct' here
>   278 |   struct error_condition
>   |  ^~~
> In file included from
> C:/msys64/mingw64/x86_64-w64-mingw32/include/windows.h:71,
>  from C:/msys64/mingw64/include/wx-3.0/wx/msw/wrapwin.h:65,
>  from C:/msys64/mingw64/include/wx-3.0/wx/msw/init.h:19,
>  from C:/msys64/mingw64/include/wx-3.0/wx/init.h:58,
>  from C:/msys64/mingw64/include/wx-3.0/wx/app.h:23,
>  from C:/msys64/mingw64/include/wx-3.0/wx/wx.h:25,
>  from
> C:/msys64/home/kicad-master/kicad/include/fctsys.h:28,
>  from
> C:/msys64/home/kicad-master/kicad/eeschema/dialogs/dialog_annotate.cpp:31:
> C:/msys64/home/kicad-master/kicad/eeschema/erc_settings.h:70:5: error:
> expected identifier before numeric constant
>70 | ERROR,
>   | ^
> C:/msys64/home/kicad-master/kicad/eeschema/erc_settings.h:70:5: error:
> expected '}' before numeric constant
> In file included from
> C:/msys64/home/kicad-master/kicad/eeschema/sch_edit_frame.h:40,
>  from
> C:/msys64/home/kicad-master/kicad/eeschema/dialogs/dialog_annotate.cpp:32:
> C:/msys64/home/kicad-master/kicad/eeschema/erc_settings.h:67:1: note: to
> match this '{'
>67 | {
>   | ^
> In file included from
> C:/msys64/mingw64/x86_64-w64-mingw32/include/windows.h:71,
>  from C:/msys64/mingw64/include/wx-3.0/wx/msw/wrapwin.h:65,
>  from C:/msys64/mingw64/include/wx-3.0/wx/msw/init.h:19,
>  from C:/msys64/mingw64/include/wx-3.0/wx/init.h:58,
>  from 

Re: [Kicad-developers] Lots of compile errors after recent source pull

[pjmonty]

 Ian,
Sorry for the delay in getting this information.  I believe this is the info 
you wanted from the "compile_commands.json" file.  If not, I can always send 
you the entire 1.5 MB file.

{
  "directory": "C:/msys64/home/codelite-kicad-compile-test2/eeschema",
  "command": "C:/msys64/mingw64/bin/c++.exe  -DDEBUG -DEESCHEMA 
-DGLM_FORCE_CTOR_INIT -DHAVE_STDINT_H -DKICAD_CONFIG_DIR=kicad -DKICAD_SPICE 
-DKICAD_USE_OCE -DUNICODE -DWXUSINGDLL -DWX_COMPATIBILITY 
-D_FILE_OFFSET_BITS=64 -D_UNICODE -D_USE_MATH_DEFINES 
-D__USE_MINGW_ANSI_STDIO=1 -D__WXMSW__ 
@CMakeFiles/eeschema_kiface_objects.dir/includes_CXX.rsp  -fpermissive -Wall 
-Wsuggest-override -Wduplicated-branches -Wduplicated-cond -Werror=vla 
-Wimplicit-fallthrough=5 -Werror=return-type -Wshadow -Wsign-compare 
-Wmissing-field-initializers -Wempty-body -Wreorder -Wmismatched-tags -g3 
-ggdb3 -fvisibility=hidden -fno-keep-inline-dllexport   -std=gnu++14 -o 
CMakeFiles/eeschema_kiface_objects.dir/dialogs/dialog_annotate.cpp.obj -c 
C:/msys64/home/kicad-compile-test2/kicad/eeschema/dialogs/dialog_annotate.cpp",
  "file": 
"C:/msys64/home/kicad-compile-test2/kicad/eeschema/dialogs/dialog_annotate.cpp"
}

 
 
-Original Message-
From: Ian McInerney 
To: pjmo...@csi.com
Cc: ian.s.mciner...@ieee.org ; 
kicad-developers@lists.launchpad.net 
Sent: Sun, Jul 5, 2020 4:52 am
Subject: Re: [Kicad-developers] Lots of compile errors after recent source pull

Yea, unfortunately the Windows headers love to have unscoped defines that are 
very common words, meaning anytime we try to use those we get conflicts (it is 
really annoying). JP fixed it yesterday in 
https://gitlab.com/kicad/code/kicad/-/commit/9e669db5b4bdeff7f057614a6c93067f7a8c7024.
As for the warnings, can you please provide the command that is being used to 
compile one of the files that has the mismatched-tag warnings? You can find 
them by setting `-DCMAKE_EXPORT_COMPILE_COMMANDS=ON` in your CMake config, then 
looking inside compile_commands.json in the build directory for the filename. I 
would like to track down why your mingw build is warning in system headers when 
it shouldn't. In the meantime, I have reported the mismatched tags to libstdc++ 
upstream, so hopefully they can clean them up.
-Ian
On Sun, Jul 5, 2020 at 6:12 AM  wrote:

 Very hard to find the errors among the epic amount of long warning messages.  
The full make would go a long time, then fail.  I'd start it again, it would go 
for some time, then fail again. Lather. Rinse. 
Repeat.  

Finally saw these error messages:
C:/msys64/mingw64/include/c++/10.1.0/system_error:278:10: note: 
'std::error_condition' defined as 'struct' here
  278 |   struct error_condition
  |  ^~~
In file included from C:/msys64/mingw64/x86_64-w64-mingw32/include/windows.h:71,
 from C:/msys64/mingw64/include/wx-3.0/wx/msw/wrapwin.h:65,
 from C:/msys64/mingw64/include/wx-3.0/wx/msw/init.h:19,
 from C:/msys64/mingw64/include/wx-3.0/wx/init.h:58,
 from C:/msys64/mingw64/include/wx-3.0/wx/app.h:23,
 from C:/msys64/mingw64/include/wx-3.0/wx/wx.h:25,
 from C:/msys64/home/kicad-master/kicad/include/fctsys.h:28,
 from 
C:/msys64/home/kicad-master/kicad/eeschema/dialogs/dialog_annotate.cpp:31:
C:/msys64/home/kicad-master/kicad/eeschema/erc_settings.h:70:5: error: expected 
identifier before numeric constant
   70 | ERROR,
  | ^
C:/msys64/home/kicad-master/kicad/eeschema/erc_settings.h:70:5: error: expected 
'}' before numeric constant
In file included from 
C:/msys64/home/kicad-master/kicad/eeschema/sch_edit_frame.h:40,
 from 
C:/msys64/home/kicad-master/kicad/eeschema/dialogs/dialog_annotate.cpp:32:
C:/msys64/home/kicad-master/kicad/eeschema/erc_settings.h:67:1: note: to match 
this '{'
   67 | {
  | ^
In file included from C:/msys64/mingw64/x86_64-w64-mingw32/include/windows.h:71,
 from C:/msys64/mingw64/include/wx-3.0/wx/msw/wrapwin.h:65,
 from C:/msys64/mingw64/include/wx-3.0/wx/msw/init.h:19,
 from C:/msys64/mingw64/include/wx-3.0/wx/init.h:58,
 from C:/msys64/mingw64/include/wx-3.0/wx/app.h:23,
 from C:/msys64/mingw64/include/wx-3.0/wx/wx.h:25,
 from C:/msys64/home/kicad-master/kicad/include/fctsys.h:28,
 from 
C:/msys64/home/kicad-master/kicad/eeschema/dialogs/dialog_annotate.cpp:31:
C:/msys64/home/kicad-master/kicad/eeschema/erc_settings.h:70:5: error: expected 
unqualified-id before numeric constant
   70 | ERROR,
  | ^
In file included from 
C:/msys64/home/kicad-master/kicad/eeschema/sch_edit_frame.h:40,
 from 
C:/msys64/home/kicad-master/kicad/eeschema/dialogs/dialog_annotate.cpp:32:
C:/msys64/home/kicad-master/kicad/eeschema/erc_settings.h:72:1: error: expected 
declaration before '}' token
   72 | };
  | ^

 
 
-Original 

Re: [Kicad-developers] Critical path item / request for help

[Wayne Stambaugh]

I wish I could say I was surprised.

On 7/7/20 4:34 PM, Mark Roszko wrote:
> vcpkg has a python3 build .. in fact, people actually complain vcpkg
> wants to use its own python copy as a dependency for other libraries
> like boost-python instead of system python (lol)
> 
> On Tue, Jul 7, 2020 at 2:42 PM Wayne Stambaugh  > wrote:
> 
> This could be the straw that breaks the msvc camel's back.  If we are
> tied to the installed Python on windows, the amount of effort required
> to package KiCad on windows increases significantly.  Shipping KiCad
> without Python on windows is not acceptable.
> 
> On 7/7/20 2:36 PM, Jon Evans wrote:
> > I am not sure there is much history of vcpkg and Python working
> > together, so this might be breaking new ground.  It is nominally a
> > package manager for C++ libraries, after all.
> >
> > On Tue, Jul 7, 2020 at 12:51 PM Wayne Stambaugh
> mailto:stambau...@gmail.com>> wrote:
> >>
> >> The wxPython Phoenix build system is ugly.  Before the Phoenix
> work, it
> >> used to respect the Python distutils configuration.  Now it just
> steps
> >> all over the Python distutils settings on windows and assumes
> that the
> >> only build platform used on windows is msvc.
> >>
> >> I have experience using Python distutils to build Python
> libraries so I
> >> can help with this although it's been a while so I'm a bit
> rusty.  I've
> >> never been a big fan of distutils.  It always seemed like a
> solution in
> >> search of a problem to me.  There are so many config/build tools
> that do
> >> the same thing far less painfully.
> >>
> >> One problem I see is that Python distutils is very much tied to the
> >> current Python version installed.  I don't know how vcpkg handles
> >> Python.  Do they use the installed Python or is it packaged as a
> stand
> >> alone port inside vcpkg?  If they use the installed Python, this
> >> significantly complicates things as we will have to provide a
> build for
> >> every supported version of Python that could be installed on someones
> >> system.  There is a big advantage with the current way we handle
> Python
> >> on windows.
> >>
> >> On 7/7/20 8:59 AM, Jon Evans wrote:
> >>> Yes, wxWidgets I can now use straight from vcpkg.
> >>>
> >>> I took a look at wxPython phoenix and the build system
> is...something else.
> >>> Is anyone more experienced with Python build systems?
> >>> It seems like the happy path for vcpkg is for projects that use
> cmake.
> >>> This hybrid of Python and C++ with custom build system in Python
> looks
> >>> like a headache to integrate.
> >>>
> >>> I have not looked at SWIG yet.  OCC it seems like is in progress (we
> >>> are less worried about that one)
> >>>
> >>> -Jon
> >>>
> >>> On Tue, Jul 7, 2020 at 7:31 AM Mark Roszko
> mailto:mark.ros...@gmail.com>> wrote:
> 
>  Nope, I'm building straight out of vcpkg now.
>  Jon Evans posted the patches to kicad's findwxwidgets back in
> November fyi.
> 
>  On Tue, Jul 7, 2020 at 5:39 AM Nick Østergaard
> mailto:oe.n...@gmail.com>> wrote:
> >
> > Hi Mark
> >
> > I still need to patch FindwxWidgets.cmake, using this version:
> > https://gist.github.com/nickoe/d3c224a2587eff8ea959bc383a993520
> >
> > See there two vcpkg issues:
> > https://github.com/microsoft/vcpkg/issues/1843
> > https://github.com/microsoft/vcpkg/issues/4756
> >
> > I thought you were using a selfbuilt version of wxwidgets.
> Have you
> > started to use it directly from vcpkg?
> >
> > I use:
> >
> > cmake ^
> >   
>  -DCMAKE_TOOLCHAIN_FILE=%WORKSPACE%\vcpkg\scripts\buildsystems\vcpkg.cmake
> ^
> >     -DCMAKE_INSTALL_PREFIX:PATH=%WORKSPACE%\install
> > -DCMAKE_PDB_OUTPUT_DIRECTORY:PATH=%WORKSPACE%\_pdb ^
> >     -DCMAKE_RUNTIME_OUTPUT_DIRECTORY:PATH=%WORKSPACE%\_bin ^
> >     -DKICAD_SPICE=OFF ^
> >     -DKICAD_USE_OCE=OFF ^
> >     -DKICAD_SCRIPTING=OFF ^
> >     -DKICAD_SCRIPTING_MODULES=OFF ^
> >     -DKICAD_SCRIPTING_WXPYTHON=OFF ^
> >     ..\src
> >
> > cmake --build . --config %build% --target install -- /M
> >
> > Recently I started to get this error at install time:
> >
> > 23:48:21 -- Found OpenGL: opengl32
> > 23:48:21 CMake Error at C:/Program
> >
> 
> Files/CMake/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:164
> > (message):
> > 23:48:21   Could NOT find GLEW (missing: GLEW_INCLUDE_DIR
> GLEW_LIBRARY)
> > 23:48:21 Call Stack (most recent call first):
>   

Re: [Kicad-developers] Critical path item / request for help

[Mark Roszko]

vcpkg has a python3 build .. in fact, people actually complain vcpkg
wants to use its own python copy as a dependency for other libraries like
boost-python instead of system python (lol)

On Tue, Jul 7, 2020 at 2:42 PM Wayne Stambaugh  wrote:

> This could be the straw that breaks the msvc camel's back.  If we are
> tied to the installed Python on windows, the amount of effort required
> to package KiCad on windows increases significantly.  Shipping KiCad
> without Python on windows is not acceptable.
>
> On 7/7/20 2:36 PM, Jon Evans wrote:
> > I am not sure there is much history of vcpkg and Python working
> > together, so this might be breaking new ground.  It is nominally a
> > package manager for C++ libraries, after all.
> >
> > On Tue, Jul 7, 2020 at 12:51 PM Wayne Stambaugh 
> wrote:
> >>
> >> The wxPython Phoenix build system is ugly.  Before the Phoenix work, it
> >> used to respect the Python distutils configuration.  Now it just steps
> >> all over the Python distutils settings on windows and assumes that the
> >> only build platform used on windows is msvc.
> >>
> >> I have experience using Python distutils to build Python libraries so I
> >> can help with this although it's been a while so I'm a bit rusty.  I've
> >> never been a big fan of distutils.  It always seemed like a solution in
> >> search of a problem to me.  There are so many config/build tools that do
> >> the same thing far less painfully.
> >>
> >> One problem I see is that Python distutils is very much tied to the
> >> current Python version installed.  I don't know how vcpkg handles
> >> Python.  Do they use the installed Python or is it packaged as a stand
> >> alone port inside vcpkg?  If they use the installed Python, this
> >> significantly complicates things as we will have to provide a build for
> >> every supported version of Python that could be installed on someones
> >> system.  There is a big advantage with the current way we handle Python
> >> on windows.
> >>
> >> On 7/7/20 8:59 AM, Jon Evans wrote:
> >>> Yes, wxWidgets I can now use straight from vcpkg.
> >>>
> >>> I took a look at wxPython phoenix and the build system is...something
> else.
> >>> Is anyone more experienced with Python build systems?
> >>> It seems like the happy path for vcpkg is for projects that use cmake.
> >>> This hybrid of Python and C++ with custom build system in Python looks
> >>> like a headache to integrate.
> >>>
> >>> I have not looked at SWIG yet.  OCC it seems like is in progress (we
> >>> are less worried about that one)
> >>>
> >>> -Jon
> >>>
> >>> On Tue, Jul 7, 2020 at 7:31 AM Mark Roszko 
> wrote:
> 
>  Nope, I'm building straight out of vcpkg now.
>  Jon Evans posted the patches to kicad's findwxwidgets back in
> November fyi.
> 
>  On Tue, Jul 7, 2020 at 5:39 AM Nick Østergaard 
> wrote:
> >
> > Hi Mark
> >
> > I still need to patch FindwxWidgets.cmake, using this version:
> > https://gist.github.com/nickoe/d3c224a2587eff8ea959bc383a993520
> >
> > See there two vcpkg issues:
> > https://github.com/microsoft/vcpkg/issues/1843
> > https://github.com/microsoft/vcpkg/issues/4756
> >
> > I thought you were using a selfbuilt version of wxwidgets. Have you
> > started to use it directly from vcpkg?
> >
> > I use:
> >
> > cmake ^
> >
>  -DCMAKE_TOOLCHAIN_FILE=%WORKSPACE%\vcpkg\scripts\buildsystems\vcpkg.cmake ^
> > -DCMAKE_INSTALL_PREFIX:PATH=%WORKSPACE%\install
> > -DCMAKE_PDB_OUTPUT_DIRECTORY:PATH=%WORKSPACE%\_pdb ^
> > -DCMAKE_RUNTIME_OUTPUT_DIRECTORY:PATH=%WORKSPACE%\_bin ^
> > -DKICAD_SPICE=OFF ^
> > -DKICAD_USE_OCE=OFF ^
> > -DKICAD_SCRIPTING=OFF ^
> > -DKICAD_SCRIPTING_MODULES=OFF ^
> > -DKICAD_SCRIPTING_WXPYTHON=OFF ^
> > ..\src
> >
> > cmake --build . --config %build% --target install -- /M
> >
> > Recently I started to get this error at install time:
> >
> > 23:48:21 -- Found OpenGL: opengl32
> > 23:48:21 CMake Error at C:/Program
> >
> Files/CMake/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:164
> > (message):
> > 23:48:21   Could NOT find GLEW (missing: GLEW_INCLUDE_DIR
> GLEW_LIBRARY)
> > 23:48:21 Call Stack (most recent call first):
> > 23:48:21   C:/Program
> >
> Files/CMake/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:445
> > (_FPHSA_FAILURE_MESSAGE)
> > 23:48:21   CMakeModules/FindGLEW.cmake:38
> (find_package_handle_standard_args)
> > 23:48:21
>  
> C:/Jenkins/workspace/windows-kicad-msvc-vcpkg/build/release/cpu/x86/label/msvc/vcpkg/scripts/buildsystems/vcpkg.cmake:405
> > (_find_package)
> > 23:48:21   CMakeLists.txt:586 (find_package)
> >
> > On Tue, 7 Jul 2020 at 01:49, Mark Roszko 
> wrote:
> >>
> >> 1. cmake scripts already work with wxwidgets, that was already done
> awhile back. I've been building with MSVC for awhile
> >>
> 

Re: [Kicad-developers] Critical path item / request for help

[Jon Evans]

It is not necessarily a requirement that we get wxPython integrated
into vcpkg; that is just one path.  If wxPython can build with MSVC
and we can point the MSVC build of KiCad at the result, that might be
enough.

On Tue, Jul 7, 2020 at 2:41 PM Wayne Stambaugh  wrote:
>
> This could be the straw that breaks the msvc camel's back.  If we are
> tied to the installed Python on windows, the amount of effort required
> to package KiCad on windows increases significantly.  Shipping KiCad
> without Python on windows is not acceptable.
>
> On 7/7/20 2:36 PM, Jon Evans wrote:
> > I am not sure there is much history of vcpkg and Python working
> > together, so this might be breaking new ground.  It is nominally a
> > package manager for C++ libraries, after all.
> >
> > On Tue, Jul 7, 2020 at 12:51 PM Wayne Stambaugh  
> > wrote:
> >>
> >> The wxPython Phoenix build system is ugly.  Before the Phoenix work, it
> >> used to respect the Python distutils configuration.  Now it just steps
> >> all over the Python distutils settings on windows and assumes that the
> >> only build platform used on windows is msvc.
> >>
> >> I have experience using Python distutils to build Python libraries so I
> >> can help with this although it's been a while so I'm a bit rusty.  I've
> >> never been a big fan of distutils.  It always seemed like a solution in
> >> search of a problem to me.  There are so many config/build tools that do
> >> the same thing far less painfully.
> >>
> >> One problem I see is that Python distutils is very much tied to the
> >> current Python version installed.  I don't know how vcpkg handles
> >> Python.  Do they use the installed Python or is it packaged as a stand
> >> alone port inside vcpkg?  If they use the installed Python, this
> >> significantly complicates things as we will have to provide a build for
> >> every supported version of Python that could be installed on someones
> >> system.  There is a big advantage with the current way we handle Python
> >> on windows.
> >>
> >> On 7/7/20 8:59 AM, Jon Evans wrote:
> >>> Yes, wxWidgets I can now use straight from vcpkg.
> >>>
> >>> I took a look at wxPython phoenix and the build system is...something 
> >>> else.
> >>> Is anyone more experienced with Python build systems?
> >>> It seems like the happy path for vcpkg is for projects that use cmake.
> >>> This hybrid of Python and C++ with custom build system in Python looks
> >>> like a headache to integrate.
> >>>
> >>> I have not looked at SWIG yet.  OCC it seems like is in progress (we
> >>> are less worried about that one)
> >>>
> >>> -Jon
> >>>
> >>> On Tue, Jul 7, 2020 at 7:31 AM Mark Roszko  wrote:
> 
>  Nope, I'm building straight out of vcpkg now.
>  Jon Evans posted the patches to kicad's findwxwidgets back in November 
>  fyi.
> 
>  On Tue, Jul 7, 2020 at 5:39 AM Nick Østergaard  wrote:
> >
> > Hi Mark
> >
> > I still need to patch FindwxWidgets.cmake, using this version:
> > https://gist.github.com/nickoe/d3c224a2587eff8ea959bc383a993520
> >
> > See there two vcpkg issues:
> > https://github.com/microsoft/vcpkg/issues/1843
> > https://github.com/microsoft/vcpkg/issues/4756
> >
> > I thought you were using a selfbuilt version of wxwidgets. Have you
> > started to use it directly from vcpkg?
> >
> > I use:
> >
> > cmake ^
> > 
> > -DCMAKE_TOOLCHAIN_FILE=%WORKSPACE%\vcpkg\scripts\buildsystems\vcpkg.cmake
> >  ^
> > -DCMAKE_INSTALL_PREFIX:PATH=%WORKSPACE%\install
> > -DCMAKE_PDB_OUTPUT_DIRECTORY:PATH=%WORKSPACE%\_pdb ^
> > -DCMAKE_RUNTIME_OUTPUT_DIRECTORY:PATH=%WORKSPACE%\_bin ^
> > -DKICAD_SPICE=OFF ^
> > -DKICAD_USE_OCE=OFF ^
> > -DKICAD_SCRIPTING=OFF ^
> > -DKICAD_SCRIPTING_MODULES=OFF ^
> > -DKICAD_SCRIPTING_WXPYTHON=OFF ^
> > ..\src
> >
> > cmake --build . --config %build% --target install -- /M
> >
> > Recently I started to get this error at install time:
> >
> > 23:48:21 -- Found OpenGL: opengl32
> > 23:48:21 CMake Error at C:/Program
> > Files/CMake/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:164
> > (message):
> > 23:48:21   Could NOT find GLEW (missing: GLEW_INCLUDE_DIR GLEW_LIBRARY)
> > 23:48:21 Call Stack (most recent call first):
> > 23:48:21   C:/Program
> > Files/CMake/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:445
> > (_FPHSA_FAILURE_MESSAGE)
> > 23:48:21   CMakeModules/FindGLEW.cmake:38 
> > (find_package_handle_standard_args)
> > 23:48:21   
> > C:/Jenkins/workspace/windows-kicad-msvc-vcpkg/build/release/cpu/x86/label/msvc/vcpkg/scripts/buildsystems/vcpkg.cmake:405
> > (_find_package)
> > 23:48:21   CMakeLists.txt:586 (find_package)
> >
> > On Tue, 7 Jul 2020 at 01:49, Mark Roszko  wrote:
> >>
> >> 1. cmake scripts already work with wxwidgets, that was already done 
> >> 

Re: [Kicad-developers] Critical path item / request for help

[Wayne Stambaugh]

This could be the straw that breaks the msvc camel's back.  If we are
tied to the installed Python on windows, the amount of effort required
to package KiCad on windows increases significantly.  Shipping KiCad
without Python on windows is not acceptable.

On 7/7/20 2:36 PM, Jon Evans wrote:
> I am not sure there is much history of vcpkg and Python working
> together, so this might be breaking new ground.  It is nominally a
> package manager for C++ libraries, after all.
> 
> On Tue, Jul 7, 2020 at 12:51 PM Wayne Stambaugh  wrote:
>>
>> The wxPython Phoenix build system is ugly.  Before the Phoenix work, it
>> used to respect the Python distutils configuration.  Now it just steps
>> all over the Python distutils settings on windows and assumes that the
>> only build platform used on windows is msvc.
>>
>> I have experience using Python distutils to build Python libraries so I
>> can help with this although it's been a while so I'm a bit rusty.  I've
>> never been a big fan of distutils.  It always seemed like a solution in
>> search of a problem to me.  There are so many config/build tools that do
>> the same thing far less painfully.
>>
>> One problem I see is that Python distutils is very much tied to the
>> current Python version installed.  I don't know how vcpkg handles
>> Python.  Do they use the installed Python or is it packaged as a stand
>> alone port inside vcpkg?  If they use the installed Python, this
>> significantly complicates things as we will have to provide a build for
>> every supported version of Python that could be installed on someones
>> system.  There is a big advantage with the current way we handle Python
>> on windows.
>>
>> On 7/7/20 8:59 AM, Jon Evans wrote:
>>> Yes, wxWidgets I can now use straight from vcpkg.
>>>
>>> I took a look at wxPython phoenix and the build system is...something else.
>>> Is anyone more experienced with Python build systems?
>>> It seems like the happy path for vcpkg is for projects that use cmake.
>>> This hybrid of Python and C++ with custom build system in Python looks
>>> like a headache to integrate.
>>>
>>> I have not looked at SWIG yet.  OCC it seems like is in progress (we
>>> are less worried about that one)
>>>
>>> -Jon
>>>
>>> On Tue, Jul 7, 2020 at 7:31 AM Mark Roszko  wrote:

 Nope, I'm building straight out of vcpkg now.
 Jon Evans posted the patches to kicad's findwxwidgets back in November fyi.

 On Tue, Jul 7, 2020 at 5:39 AM Nick Østergaard  wrote:
>
> Hi Mark
>
> I still need to patch FindwxWidgets.cmake, using this version:
> https://gist.github.com/nickoe/d3c224a2587eff8ea959bc383a993520
>
> See there two vcpkg issues:
> https://github.com/microsoft/vcpkg/issues/1843
> https://github.com/microsoft/vcpkg/issues/4756
>
> I thought you were using a selfbuilt version of wxwidgets. Have you
> started to use it directly from vcpkg?
>
> I use:
>
> cmake ^
> 
> -DCMAKE_TOOLCHAIN_FILE=%WORKSPACE%\vcpkg\scripts\buildsystems\vcpkg.cmake 
> ^
> -DCMAKE_INSTALL_PREFIX:PATH=%WORKSPACE%\install
> -DCMAKE_PDB_OUTPUT_DIRECTORY:PATH=%WORKSPACE%\_pdb ^
> -DCMAKE_RUNTIME_OUTPUT_DIRECTORY:PATH=%WORKSPACE%\_bin ^
> -DKICAD_SPICE=OFF ^
> -DKICAD_USE_OCE=OFF ^
> -DKICAD_SCRIPTING=OFF ^
> -DKICAD_SCRIPTING_MODULES=OFF ^
> -DKICAD_SCRIPTING_WXPYTHON=OFF ^
> ..\src
>
> cmake --build . --config %build% --target install -- /M
>
> Recently I started to get this error at install time:
>
> 23:48:21 -- Found OpenGL: opengl32
> 23:48:21 CMake Error at C:/Program
> Files/CMake/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:164
> (message):
> 23:48:21   Could NOT find GLEW (missing: GLEW_INCLUDE_DIR GLEW_LIBRARY)
> 23:48:21 Call Stack (most recent call first):
> 23:48:21   C:/Program
> Files/CMake/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:445
> (_FPHSA_FAILURE_MESSAGE)
> 23:48:21   CMakeModules/FindGLEW.cmake:38 
> (find_package_handle_standard_args)
> 23:48:21   
> C:/Jenkins/workspace/windows-kicad-msvc-vcpkg/build/release/cpu/x86/label/msvc/vcpkg/scripts/buildsystems/vcpkg.cmake:405
> (_find_package)
> 23:48:21   CMakeLists.txt:586 (find_package)
>
> On Tue, 7 Jul 2020 at 01:49, Mark Roszko  wrote:
>>
>> 1. cmake scripts already work with wxwidgets, that was already done 
>> awhile back. I've been building with MSVC for awhile
>>
>>
>>
>> One dependency that'll need "porting" is ngspice.
>> But let me put this out there, does it make sense to leave ngspice to a 
>> higher level distro and not built as part of kicad?
>> We've already had cases of repackaging Windows and macOS just to bump 
>> ngspice versions up.
>> Why not make it standard baseline as part of kicad instead of allowing 
>> versions to be mixed?
>>
>>

Re: [Kicad-developers] Critical path item / request for help

[Jon Evans]

I am not sure there is much history of vcpkg and Python working
together, so this might be breaking new ground.  It is nominally a
package manager for C++ libraries, after all.

On Tue, Jul 7, 2020 at 12:51 PM Wayne Stambaugh  wrote:
>
> The wxPython Phoenix build system is ugly.  Before the Phoenix work, it
> used to respect the Python distutils configuration.  Now it just steps
> all over the Python distutils settings on windows and assumes that the
> only build platform used on windows is msvc.
>
> I have experience using Python distutils to build Python libraries so I
> can help with this although it's been a while so I'm a bit rusty.  I've
> never been a big fan of distutils.  It always seemed like a solution in
> search of a problem to me.  There are so many config/build tools that do
> the same thing far less painfully.
>
> One problem I see is that Python distutils is very much tied to the
> current Python version installed.  I don't know how vcpkg handles
> Python.  Do they use the installed Python or is it packaged as a stand
> alone port inside vcpkg?  If they use the installed Python, this
> significantly complicates things as we will have to provide a build for
> every supported version of Python that could be installed on someones
> system.  There is a big advantage with the current way we handle Python
> on windows.
>
> On 7/7/20 8:59 AM, Jon Evans wrote:
> > Yes, wxWidgets I can now use straight from vcpkg.
> >
> > I took a look at wxPython phoenix and the build system is...something else.
> > Is anyone more experienced with Python build systems?
> > It seems like the happy path for vcpkg is for projects that use cmake.
> > This hybrid of Python and C++ with custom build system in Python looks
> > like a headache to integrate.
> >
> > I have not looked at SWIG yet.  OCC it seems like is in progress (we
> > are less worried about that one)
> >
> > -Jon
> >
> > On Tue, Jul 7, 2020 at 7:31 AM Mark Roszko  wrote:
> >>
> >> Nope, I'm building straight out of vcpkg now.
> >> Jon Evans posted the patches to kicad's findwxwidgets back in November fyi.
> >>
> >> On Tue, Jul 7, 2020 at 5:39 AM Nick Østergaard  wrote:
> >>>
> >>> Hi Mark
> >>>
> >>> I still need to patch FindwxWidgets.cmake, using this version:
> >>> https://gist.github.com/nickoe/d3c224a2587eff8ea959bc383a993520
> >>>
> >>> See there two vcpkg issues:
> >>> https://github.com/microsoft/vcpkg/issues/1843
> >>> https://github.com/microsoft/vcpkg/issues/4756
> >>>
> >>> I thought you were using a selfbuilt version of wxwidgets. Have you
> >>> started to use it directly from vcpkg?
> >>>
> >>> I use:
> >>>
> >>> cmake ^
> >>> 
> >>> -DCMAKE_TOOLCHAIN_FILE=%WORKSPACE%\vcpkg\scripts\buildsystems\vcpkg.cmake 
> >>> ^
> >>> -DCMAKE_INSTALL_PREFIX:PATH=%WORKSPACE%\install
> >>> -DCMAKE_PDB_OUTPUT_DIRECTORY:PATH=%WORKSPACE%\_pdb ^
> >>> -DCMAKE_RUNTIME_OUTPUT_DIRECTORY:PATH=%WORKSPACE%\_bin ^
> >>> -DKICAD_SPICE=OFF ^
> >>> -DKICAD_USE_OCE=OFF ^
> >>> -DKICAD_SCRIPTING=OFF ^
> >>> -DKICAD_SCRIPTING_MODULES=OFF ^
> >>> -DKICAD_SCRIPTING_WXPYTHON=OFF ^
> >>> ..\src
> >>>
> >>> cmake --build . --config %build% --target install -- /M
> >>>
> >>> Recently I started to get this error at install time:
> >>>
> >>> 23:48:21 -- Found OpenGL: opengl32
> >>> 23:48:21 CMake Error at C:/Program
> >>> Files/CMake/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:164
> >>> (message):
> >>> 23:48:21   Could NOT find GLEW (missing: GLEW_INCLUDE_DIR GLEW_LIBRARY)
> >>> 23:48:21 Call Stack (most recent call first):
> >>> 23:48:21   C:/Program
> >>> Files/CMake/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:445
> >>> (_FPHSA_FAILURE_MESSAGE)
> >>> 23:48:21   CMakeModules/FindGLEW.cmake:38 
> >>> (find_package_handle_standard_args)
> >>> 23:48:21   
> >>> C:/Jenkins/workspace/windows-kicad-msvc-vcpkg/build/release/cpu/x86/label/msvc/vcpkg/scripts/buildsystems/vcpkg.cmake:405
> >>> (_find_package)
> >>> 23:48:21   CMakeLists.txt:586 (find_package)
> >>>
> >>> On Tue, 7 Jul 2020 at 01:49, Mark Roszko  wrote:
> 
>  1. cmake scripts already work with wxwidgets, that was already done 
>  awhile back. I've been building with MSVC for awhile
> 
> 
> 
>  One dependency that'll need "porting" is ngspice.
>  But let me put this out there, does it make sense to leave ngspice to a 
>  higher level distro and not built as part of kicad?
>  We've already had cases of repackaging Windows and macOS just to bump 
>  ngspice versions up.
>  Why not make it standard baseline as part of kicad instead of allowing 
>  versions to be mixed?
> 
> 
>  On Mon, Jul 6, 2020 at 3:04 PM Nick Østergaard  wrote:
> >
> > Just a FYI, we have not really solved wxpython phoenix for macos yet,
> > though some progress were made recently.
> >
> > For MSVC there are a number of issues yet to be addressed, this is
> > with the intention of using vcpkg.
> 

Re: [Kicad-developers] Critical path item / request for help

[Wayne Stambaugh]

The wxPython Phoenix build system is ugly.  Before the Phoenix work, it
used to respect the Python distutils configuration.  Now it just steps
all over the Python distutils settings on windows and assumes that the
only build platform used on windows is msvc.

I have experience using Python distutils to build Python libraries so I
can help with this although it's been a while so I'm a bit rusty.  I've
never been a big fan of distutils.  It always seemed like a solution in
search of a problem to me.  There are so many config/build tools that do
the same thing far less painfully.

One problem I see is that Python distutils is very much tied to the
current Python version installed.  I don't know how vcpkg handles
Python.  Do they use the installed Python or is it packaged as a stand
alone port inside vcpkg?  If they use the installed Python, this
significantly complicates things as we will have to provide a build for
every supported version of Python that could be installed on someones
system.  There is a big advantage with the current way we handle Python
on windows.

On 7/7/20 8:59 AM, Jon Evans wrote:
> Yes, wxWidgets I can now use straight from vcpkg.
> 
> I took a look at wxPython phoenix and the build system is...something else.
> Is anyone more experienced with Python build systems?
> It seems like the happy path for vcpkg is for projects that use cmake.
> This hybrid of Python and C++ with custom build system in Python looks
> like a headache to integrate.
> 
> I have not looked at SWIG yet.  OCC it seems like is in progress (we
> are less worried about that one)
> 
> -Jon
> 
> On Tue, Jul 7, 2020 at 7:31 AM Mark Roszko  wrote:
>>
>> Nope, I'm building straight out of vcpkg now.
>> Jon Evans posted the patches to kicad's findwxwidgets back in November fyi.
>>
>> On Tue, Jul 7, 2020 at 5:39 AM Nick Østergaard  wrote:
>>>
>>> Hi Mark
>>>
>>> I still need to patch FindwxWidgets.cmake, using this version:
>>> https://gist.github.com/nickoe/d3c224a2587eff8ea959bc383a993520
>>>
>>> See there two vcpkg issues:
>>> https://github.com/microsoft/vcpkg/issues/1843
>>> https://github.com/microsoft/vcpkg/issues/4756
>>>
>>> I thought you were using a selfbuilt version of wxwidgets. Have you
>>> started to use it directly from vcpkg?
>>>
>>> I use:
>>>
>>> cmake ^
>>> 
>>> -DCMAKE_TOOLCHAIN_FILE=%WORKSPACE%\vcpkg\scripts\buildsystems\vcpkg.cmake ^
>>> -DCMAKE_INSTALL_PREFIX:PATH=%WORKSPACE%\install
>>> -DCMAKE_PDB_OUTPUT_DIRECTORY:PATH=%WORKSPACE%\_pdb ^
>>> -DCMAKE_RUNTIME_OUTPUT_DIRECTORY:PATH=%WORKSPACE%\_bin ^
>>> -DKICAD_SPICE=OFF ^
>>> -DKICAD_USE_OCE=OFF ^
>>> -DKICAD_SCRIPTING=OFF ^
>>> -DKICAD_SCRIPTING_MODULES=OFF ^
>>> -DKICAD_SCRIPTING_WXPYTHON=OFF ^
>>> ..\src
>>>
>>> cmake --build . --config %build% --target install -- /M
>>>
>>> Recently I started to get this error at install time:
>>>
>>> 23:48:21 -- Found OpenGL: opengl32
>>> 23:48:21 CMake Error at C:/Program
>>> Files/CMake/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:164
>>> (message):
>>> 23:48:21   Could NOT find GLEW (missing: GLEW_INCLUDE_DIR GLEW_LIBRARY)
>>> 23:48:21 Call Stack (most recent call first):
>>> 23:48:21   C:/Program
>>> Files/CMake/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:445
>>> (_FPHSA_FAILURE_MESSAGE)
>>> 23:48:21   CMakeModules/FindGLEW.cmake:38 
>>> (find_package_handle_standard_args)
>>> 23:48:21   
>>> C:/Jenkins/workspace/windows-kicad-msvc-vcpkg/build/release/cpu/x86/label/msvc/vcpkg/scripts/buildsystems/vcpkg.cmake:405
>>> (_find_package)
>>> 23:48:21   CMakeLists.txt:586 (find_package)
>>>
>>> On Tue, 7 Jul 2020 at 01:49, Mark Roszko  wrote:

 1. cmake scripts already work with wxwidgets, that was already done awhile 
 back. I've been building with MSVC for awhile



 One dependency that'll need "porting" is ngspice.
 But let me put this out there, does it make sense to leave ngspice to a 
 higher level distro and not built as part of kicad?
 We've already had cases of repackaging Windows and macOS just to bump 
 ngspice versions up.
 Why not make it standard baseline as part of kicad instead of allowing 
 versions to be mixed?


 On Mon, Jul 6, 2020 at 3:04 PM Nick Østergaard  wrote:
>
> Just a FYI, we have not really solved wxpython phoenix for macos yet,
> though some progress were made recently.
>
> For MSVC there are a number of issues yet to be addressed, this is
> with the intention of using vcpkg.
>  1. Fix cmake scripts for wxwidgets
>  2. Add opencascade to vcpkg
>  3. Add swig to vcpkg (or sip if that is what we want to use in the 
> future)
>  4. Probably a small handful of other things need to be done
>
> On Mon, 6 Jul 2020 at 20:35, Jeff Young  wrote:
>>
>> I love this part:
>>
>> wxPython4.0 (needed for Python3)
>>
>>
>> And I thought our versioning was challenged. ;)
>> 

Re: [Kicad-developers] Critical path item / request for help

[Wayne Stambaugh]

I would rather not include ngspice in KiCad and build it from source.
Remember when we used to build boost from source?  We spent a lot of man
hours implementing and supporting it.  I consider that a valuable lesson
learned.

On 7/6/20 7:49 PM, Mark Roszko wrote:
> 1. cmake scripts already work with wxwidgets, that was already done
> awhile back. I've been building with MSVC for awhile
> 
> 
> 
> One dependency that'll need "porting" is ngspice.
> But let me put this out there, does it make sense to leave ngspice to a
> higher level distro and not built as part of kicad?
> We've already had cases of repackaging Windows and macOS just to bump
> ngspice versions up. 
> Why not make it standard baseline as part of kicad instead of allowing
> versions to be mixed?
> 
> 
> On Mon, Jul 6, 2020 at 3:04 PM Nick Østergaard  > wrote:
> 
> Just a FYI, we have not really solved wxpython phoenix for macos yet,
> though some progress were made recently.
> 
> For MSVC there are a number of issues yet to be addressed, this is
> with the intention of using vcpkg.
>  1. Fix cmake scripts for wxwidgets
>  2. Add opencascade to vcpkg
>  3. Add swig to vcpkg (or sip if that is what we want to use in the
> future)
>  4. Probably a small handful of other things need to be done
> 
> On Mon, 6 Jul 2020 at 20:35, Jeff Young  > wrote:
> >
> > I love this part:
> >
> > wxPython4.0 (needed for Python3)
> >
> >
> > And I thought our versioning was challenged. ;)
> > ___
> > 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
> 
> 
> 
> -- 
> 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
> 

___
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] Critical path item / request for help

[Adam Wolf]

(We are still working on migrating from OCE to OCC on macOS.  It
builds and runs fine, but there's something funny in the macOS
bundling process that I need to debug.)

On Tue, Jul 7, 2020 at 8:07 AM Nick Østergaard  wrote:
>
> About the findwxWidgets, I see it has been updated in kicad, but
> shouldn't such a fix be upstreamed in cmake as well?
>
> I did a clean vcpkg environment and it does seem to compile again,
> lets see if it works for x86 and x64 and debug and release in a couple
> of hours.
>
> I don't see any progress about OCC, I only saw a request to make it.
>
> On Tue, 7 Jul 2020 at 14:59, Jon Evans  wrote:
> >
> > Yes, wxWidgets I can now use straight from vcpkg.
> >
> > I took a look at wxPython phoenix and the build system is...something else.
> > Is anyone more experienced with Python build systems?
> > It seems like the happy path for vcpkg is for projects that use cmake.
> > This hybrid of Python and C++ with custom build system in Python looks
> > like a headache to integrate.
> >
> > I have not looked at SWIG yet.  OCC it seems like is in progress (we
> > are less worried about that one)
> >
> > -Jon
> >
> > On Tue, Jul 7, 2020 at 7:31 AM Mark Roszko  wrote:
> > >
> > > Nope, I'm building straight out of vcpkg now.
> > > Jon Evans posted the patches to kicad's findwxwidgets back in November 
> > > fyi.
> > >
> > > On Tue, Jul 7, 2020 at 5:39 AM Nick Østergaard  wrote:
> > >>
> > >> Hi Mark
> > >>
> > >> I still need to patch FindwxWidgets.cmake, using this version:
> > >> https://gist.github.com/nickoe/d3c224a2587eff8ea959bc383a993520
> > >>
> > >> See there two vcpkg issues:
> > >> https://github.com/microsoft/vcpkg/issues/1843
> > >> https://github.com/microsoft/vcpkg/issues/4756
> > >>
> > >> I thought you were using a selfbuilt version of wxwidgets. Have you
> > >> started to use it directly from vcpkg?
> > >>
> > >> I use:
> > >>
> > >> cmake ^
> > >> 
> > >> -DCMAKE_TOOLCHAIN_FILE=%WORKSPACE%\vcpkg\scripts\buildsystems\vcpkg.cmake
> > >>  ^
> > >> -DCMAKE_INSTALL_PREFIX:PATH=%WORKSPACE%\install
> > >> -DCMAKE_PDB_OUTPUT_DIRECTORY:PATH=%WORKSPACE%\_pdb ^
> > >> -DCMAKE_RUNTIME_OUTPUT_DIRECTORY:PATH=%WORKSPACE%\_bin ^
> > >> -DKICAD_SPICE=OFF ^
> > >> -DKICAD_USE_OCE=OFF ^
> > >> -DKICAD_SCRIPTING=OFF ^
> > >> -DKICAD_SCRIPTING_MODULES=OFF ^
> > >> -DKICAD_SCRIPTING_WXPYTHON=OFF ^
> > >> ..\src
> > >>
> > >> cmake --build . --config %build% --target install -- /M
> > >>
> > >> Recently I started to get this error at install time:
> > >>
> > >> 23:48:21 -- Found OpenGL: opengl32
> > >> 23:48:21 CMake Error at C:/Program
> > >> Files/CMake/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:164
> > >> (message):
> > >> 23:48:21   Could NOT find GLEW (missing: GLEW_INCLUDE_DIR GLEW_LIBRARY)
> > >> 23:48:21 Call Stack (most recent call first):
> > >> 23:48:21   C:/Program
> > >> Files/CMake/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:445
> > >> (_FPHSA_FAILURE_MESSAGE)
> > >> 23:48:21   CMakeModules/FindGLEW.cmake:38 
> > >> (find_package_handle_standard_args)
> > >> 23:48:21   
> > >> C:/Jenkins/workspace/windows-kicad-msvc-vcpkg/build/release/cpu/x86/label/msvc/vcpkg/scripts/buildsystems/vcpkg.cmake:405
> > >> (_find_package)
> > >> 23:48:21   CMakeLists.txt:586 (find_package)
> > >>
> > >> On Tue, 7 Jul 2020 at 01:49, Mark Roszko  wrote:
> > >> >
> > >> > 1. cmake scripts already work with wxwidgets, that was already done 
> > >> > awhile back. I've been building with MSVC for awhile
> > >> >
> > >> >
> > >> >
> > >> > One dependency that'll need "porting" is ngspice.
> > >> > But let me put this out there, does it make sense to leave ngspice to 
> > >> > a higher level distro and not built as part of kicad?
> > >> > We've already had cases of repackaging Windows and macOS just to bump 
> > >> > ngspice versions up.
> > >> > Why not make it standard baseline as part of kicad instead of allowing 
> > >> > versions to be mixed?
> > >> >
> > >> >
> > >> > On Mon, Jul 6, 2020 at 3:04 PM Nick Østergaard  
> > >> > wrote:
> > >> >>
> > >> >> Just a FYI, we have not really solved wxpython phoenix for macos yet,
> > >> >> though some progress were made recently.
> > >> >>
> > >> >> For MSVC there are a number of issues yet to be addressed, this is
> > >> >> with the intention of using vcpkg.
> > >> >>  1. Fix cmake scripts for wxwidgets
> > >> >>  2. Add opencascade to vcpkg
> > >> >>  3. Add swig to vcpkg (or sip if that is what we want to use in the 
> > >> >> future)
> > >> >>  4. Probably a small handful of other things need to be done
> > >> >>
> > >> >> On Mon, 6 Jul 2020 at 20:35, Jeff Young  wrote:
> > >> >> >
> > >> >> > I love this part:
> > >> >> >
> > >> >> > wxPython4.0 (needed for Python3)
> > >> >> >
> > >> >> >
> > >> >> > And I thought our versioning was challenged. ;)
> > >> >> > ___
> > >> >> > Mailing list: https://launchpad.net/~kicad-developers
> > >> >> > Post to 

Re: [Kicad-developers] Critical path item / request for help

[Nick Østergaard]

About the findwxWidgets, I see it has been updated in kicad, but
shouldn't such a fix be upstreamed in cmake as well?

I did a clean vcpkg environment and it does seem to compile again,
lets see if it works for x86 and x64 and debug and release in a couple
of hours.

I don't see any progress about OCC, I only saw a request to make it.

On Tue, 7 Jul 2020 at 14:59, Jon Evans  wrote:
>
> Yes, wxWidgets I can now use straight from vcpkg.
>
> I took a look at wxPython phoenix and the build system is...something else.
> Is anyone more experienced with Python build systems?
> It seems like the happy path for vcpkg is for projects that use cmake.
> This hybrid of Python and C++ with custom build system in Python looks
> like a headache to integrate.
>
> I have not looked at SWIG yet.  OCC it seems like is in progress (we
> are less worried about that one)
>
> -Jon
>
> On Tue, Jul 7, 2020 at 7:31 AM Mark Roszko  wrote:
> >
> > Nope, I'm building straight out of vcpkg now.
> > Jon Evans posted the patches to kicad's findwxwidgets back in November fyi.
> >
> > On Tue, Jul 7, 2020 at 5:39 AM Nick Østergaard  wrote:
> >>
> >> Hi Mark
> >>
> >> I still need to patch FindwxWidgets.cmake, using this version:
> >> https://gist.github.com/nickoe/d3c224a2587eff8ea959bc383a993520
> >>
> >> See there two vcpkg issues:
> >> https://github.com/microsoft/vcpkg/issues/1843
> >> https://github.com/microsoft/vcpkg/issues/4756
> >>
> >> I thought you were using a selfbuilt version of wxwidgets. Have you
> >> started to use it directly from vcpkg?
> >>
> >> I use:
> >>
> >> cmake ^
> >> 
> >> -DCMAKE_TOOLCHAIN_FILE=%WORKSPACE%\vcpkg\scripts\buildsystems\vcpkg.cmake ^
> >> -DCMAKE_INSTALL_PREFIX:PATH=%WORKSPACE%\install
> >> -DCMAKE_PDB_OUTPUT_DIRECTORY:PATH=%WORKSPACE%\_pdb ^
> >> -DCMAKE_RUNTIME_OUTPUT_DIRECTORY:PATH=%WORKSPACE%\_bin ^
> >> -DKICAD_SPICE=OFF ^
> >> -DKICAD_USE_OCE=OFF ^
> >> -DKICAD_SCRIPTING=OFF ^
> >> -DKICAD_SCRIPTING_MODULES=OFF ^
> >> -DKICAD_SCRIPTING_WXPYTHON=OFF ^
> >> ..\src
> >>
> >> cmake --build . --config %build% --target install -- /M
> >>
> >> Recently I started to get this error at install time:
> >>
> >> 23:48:21 -- Found OpenGL: opengl32
> >> 23:48:21 CMake Error at C:/Program
> >> Files/CMake/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:164
> >> (message):
> >> 23:48:21   Could NOT find GLEW (missing: GLEW_INCLUDE_DIR GLEW_LIBRARY)
> >> 23:48:21 Call Stack (most recent call first):
> >> 23:48:21   C:/Program
> >> Files/CMake/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:445
> >> (_FPHSA_FAILURE_MESSAGE)
> >> 23:48:21   CMakeModules/FindGLEW.cmake:38 
> >> (find_package_handle_standard_args)
> >> 23:48:21   
> >> C:/Jenkins/workspace/windows-kicad-msvc-vcpkg/build/release/cpu/x86/label/msvc/vcpkg/scripts/buildsystems/vcpkg.cmake:405
> >> (_find_package)
> >> 23:48:21   CMakeLists.txt:586 (find_package)
> >>
> >> On Tue, 7 Jul 2020 at 01:49, Mark Roszko  wrote:
> >> >
> >> > 1. cmake scripts already work with wxwidgets, that was already done 
> >> > awhile back. I've been building with MSVC for awhile
> >> >
> >> >
> >> >
> >> > One dependency that'll need "porting" is ngspice.
> >> > But let me put this out there, does it make sense to leave ngspice to a 
> >> > higher level distro and not built as part of kicad?
> >> > We've already had cases of repackaging Windows and macOS just to bump 
> >> > ngspice versions up.
> >> > Why not make it standard baseline as part of kicad instead of allowing 
> >> > versions to be mixed?
> >> >
> >> >
> >> > On Mon, Jul 6, 2020 at 3:04 PM Nick Østergaard  wrote:
> >> >>
> >> >> Just a FYI, we have not really solved wxpython phoenix for macos yet,
> >> >> though some progress were made recently.
> >> >>
> >> >> For MSVC there are a number of issues yet to be addressed, this is
> >> >> with the intention of using vcpkg.
> >> >>  1. Fix cmake scripts for wxwidgets
> >> >>  2. Add opencascade to vcpkg
> >> >>  3. Add swig to vcpkg (or sip if that is what we want to use in the 
> >> >> future)
> >> >>  4. Probably a small handful of other things need to be done
> >> >>
> >> >> On Mon, 6 Jul 2020 at 20:35, Jeff Young  wrote:
> >> >> >
> >> >> > I love this part:
> >> >> >
> >> >> > wxPython4.0 (needed for Python3)
> >> >> >
> >> >> >
> >> >> > And I thought our versioning was challenged. ;)
> >> >> > ___
> >> >> > 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] Critical path item / request for help

[Jon Evans]

Yes, wxWidgets I can now use straight from vcpkg.

I took a look at wxPython phoenix and the build system is...something else.
Is anyone more experienced with Python build systems?
It seems like the happy path for vcpkg is for projects that use cmake.
This hybrid of Python and C++ with custom build system in Python looks
like a headache to integrate.

I have not looked at SWIG yet.  OCC it seems like is in progress (we
are less worried about that one)

-Jon

On Tue, Jul 7, 2020 at 7:31 AM Mark Roszko  wrote:
>
> Nope, I'm building straight out of vcpkg now.
> Jon Evans posted the patches to kicad's findwxwidgets back in November fyi.
>
> On Tue, Jul 7, 2020 at 5:39 AM Nick Østergaard  wrote:
>>
>> Hi Mark
>>
>> I still need to patch FindwxWidgets.cmake, using this version:
>> https://gist.github.com/nickoe/d3c224a2587eff8ea959bc383a993520
>>
>> See there two vcpkg issues:
>> https://github.com/microsoft/vcpkg/issues/1843
>> https://github.com/microsoft/vcpkg/issues/4756
>>
>> I thought you were using a selfbuilt version of wxwidgets. Have you
>> started to use it directly from vcpkg?
>>
>> I use:
>>
>> cmake ^
>> 
>> -DCMAKE_TOOLCHAIN_FILE=%WORKSPACE%\vcpkg\scripts\buildsystems\vcpkg.cmake ^
>> -DCMAKE_INSTALL_PREFIX:PATH=%WORKSPACE%\install
>> -DCMAKE_PDB_OUTPUT_DIRECTORY:PATH=%WORKSPACE%\_pdb ^
>> -DCMAKE_RUNTIME_OUTPUT_DIRECTORY:PATH=%WORKSPACE%\_bin ^
>> -DKICAD_SPICE=OFF ^
>> -DKICAD_USE_OCE=OFF ^
>> -DKICAD_SCRIPTING=OFF ^
>> -DKICAD_SCRIPTING_MODULES=OFF ^
>> -DKICAD_SCRIPTING_WXPYTHON=OFF ^
>> ..\src
>>
>> cmake --build . --config %build% --target install -- /M
>>
>> Recently I started to get this error at install time:
>>
>> 23:48:21 -- Found OpenGL: opengl32
>> 23:48:21 CMake Error at C:/Program
>> Files/CMake/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:164
>> (message):
>> 23:48:21   Could NOT find GLEW (missing: GLEW_INCLUDE_DIR GLEW_LIBRARY)
>> 23:48:21 Call Stack (most recent call first):
>> 23:48:21   C:/Program
>> Files/CMake/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:445
>> (_FPHSA_FAILURE_MESSAGE)
>> 23:48:21   CMakeModules/FindGLEW.cmake:38 (find_package_handle_standard_args)
>> 23:48:21   
>> C:/Jenkins/workspace/windows-kicad-msvc-vcpkg/build/release/cpu/x86/label/msvc/vcpkg/scripts/buildsystems/vcpkg.cmake:405
>> (_find_package)
>> 23:48:21   CMakeLists.txt:586 (find_package)
>>
>> On Tue, 7 Jul 2020 at 01:49, Mark Roszko  wrote:
>> >
>> > 1. cmake scripts already work with wxwidgets, that was already done awhile 
>> > back. I've been building with MSVC for awhile
>> >
>> >
>> >
>> > One dependency that'll need "porting" is ngspice.
>> > But let me put this out there, does it make sense to leave ngspice to a 
>> > higher level distro and not built as part of kicad?
>> > We've already had cases of repackaging Windows and macOS just to bump 
>> > ngspice versions up.
>> > Why not make it standard baseline as part of kicad instead of allowing 
>> > versions to be mixed?
>> >
>> >
>> > On Mon, Jul 6, 2020 at 3:04 PM Nick Østergaard  wrote:
>> >>
>> >> Just a FYI, we have not really solved wxpython phoenix for macos yet,
>> >> though some progress were made recently.
>> >>
>> >> For MSVC there are a number of issues yet to be addressed, this is
>> >> with the intention of using vcpkg.
>> >>  1. Fix cmake scripts for wxwidgets
>> >>  2. Add opencascade to vcpkg
>> >>  3. Add swig to vcpkg (or sip if that is what we want to use in the 
>> >> future)
>> >>  4. Probably a small handful of other things need to be done
>> >>
>> >> On Mon, 6 Jul 2020 at 20:35, Jeff Young  wrote:
>> >> >
>> >> > I love this part:
>> >> >
>> >> > wxPython4.0 (needed for Python3)
>> >> >
>> >> >
>> >> > And I thought our versioning was challenged. ;)
>> >> > ___
>> >> > 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
>> >
>> >
>> >
>> > --
>> > Mark
>
>
>
> --
> 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

___
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] Critical path item / request for help

[Mark Roszko]

Nope, I'm building straight out of vcpkg now.
Jon Evans posted the patches to kicad's findwxwidgets back in November fyi.

On Tue, Jul 7, 2020 at 5:39 AM Nick Østergaard  wrote:

> Hi Mark
>
> I still need to patch FindwxWidgets.cmake, using this version:
> https://gist.github.com/nickoe/d3c224a2587eff8ea959bc383a993520
>
> See there two vcpkg issues:
> https://github.com/microsoft/vcpkg/issues/1843
> https://github.com/microsoft/vcpkg/issues/4756
>
> I thought you were using a selfbuilt version of wxwidgets. Have you
> started to use it directly from vcpkg?
>
> I use:
>
> cmake ^
>
> -DCMAKE_TOOLCHAIN_FILE=%WORKSPACE%\vcpkg\scripts\buildsystems\vcpkg.cmake ^
> -DCMAKE_INSTALL_PREFIX:PATH=%WORKSPACE%\install
> -DCMAKE_PDB_OUTPUT_DIRECTORY:PATH=%WORKSPACE%\_pdb ^
> -DCMAKE_RUNTIME_OUTPUT_DIRECTORY:PATH=%WORKSPACE%\_bin ^
> -DKICAD_SPICE=OFF ^
> -DKICAD_USE_OCE=OFF ^
> -DKICAD_SCRIPTING=OFF ^
> -DKICAD_SCRIPTING_MODULES=OFF ^
> -DKICAD_SCRIPTING_WXPYTHON=OFF ^
> ..\src
>
> cmake --build . --config %build% --target install -- /M
>
> Recently I started to get this error at install time:
>
> 23:48:21 -- Found OpenGL: opengl32
> 23:48:21 CMake Error at C:/Program
>
> Files/CMake/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:164
> (message):
> 23:48:21   Could NOT find GLEW (missing: GLEW_INCLUDE_DIR GLEW_LIBRARY)
> 23:48:21 Call Stack (most recent call first):
> 23:48:21   C:/Program
>
> Files/CMake/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:445
> (_FPHSA_FAILURE_MESSAGE)
> 23:48:21   CMakeModules/FindGLEW.cmake:38
> (find_package_handle_standard_args)
> 23:48:21
>  
> C:/Jenkins/workspace/windows-kicad-msvc-vcpkg/build/release/cpu/x86/label/msvc/vcpkg/scripts/buildsystems/vcpkg.cmake:405
> (_find_package)
> 23:48:21   CMakeLists.txt:586 (find_package)
>
> On Tue, 7 Jul 2020 at 01:49, Mark Roszko  wrote:
> >
> > 1. cmake scripts already work with wxwidgets, that was already done
> awhile back. I've been building with MSVC for awhile
> >
> >
> >
> > One dependency that'll need "porting" is ngspice.
> > But let me put this out there, does it make sense to leave ngspice to a
> higher level distro and not built as part of kicad?
> > We've already had cases of repackaging Windows and macOS just to bump
> ngspice versions up.
> > Why not make it standard baseline as part of kicad instead of allowing
> versions to be mixed?
> >
> >
> > On Mon, Jul 6, 2020 at 3:04 PM Nick Østergaard 
> wrote:
> >>
> >> Just a FYI, we have not really solved wxpython phoenix for macos yet,
> >> though some progress were made recently.
> >>
> >> For MSVC there are a number of issues yet to be addressed, this is
> >> with the intention of using vcpkg.
> >>  1. Fix cmake scripts for wxwidgets
> >>  2. Add opencascade to vcpkg
> >>  3. Add swig to vcpkg (or sip if that is what we want to use in the
> future)
> >>  4. Probably a small handful of other things need to be done
> >>
> >> On Mon, 6 Jul 2020 at 20:35, Jeff Young  wrote:
> >> >
> >> > I love this part:
> >> >
> >> > wxPython4.0 (needed for Python3)
> >> >
> >> >
> >> > And I thought our versioning was challenged. ;)
> >> > ___
> >> > 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
> >
> >
> >
> > --
> > Mark
>


-- 
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] Critical path item / request for help

[Nick Østergaard]

Hi Mark

I still need to patch FindwxWidgets.cmake, using this version:
https://gist.github.com/nickoe/d3c224a2587eff8ea959bc383a993520

See there two vcpkg issues:
https://github.com/microsoft/vcpkg/issues/1843
https://github.com/microsoft/vcpkg/issues/4756

I thought you were using a selfbuilt version of wxwidgets. Have you
started to use it directly from vcpkg?

I use:

cmake ^
-DCMAKE_TOOLCHAIN_FILE=%WORKSPACE%\vcpkg\scripts\buildsystems\vcpkg.cmake ^
-DCMAKE_INSTALL_PREFIX:PATH=%WORKSPACE%\install
-DCMAKE_PDB_OUTPUT_DIRECTORY:PATH=%WORKSPACE%\_pdb ^
-DCMAKE_RUNTIME_OUTPUT_DIRECTORY:PATH=%WORKSPACE%\_bin ^
-DKICAD_SPICE=OFF ^
-DKICAD_USE_OCE=OFF ^
-DKICAD_SCRIPTING=OFF ^
-DKICAD_SCRIPTING_MODULES=OFF ^
-DKICAD_SCRIPTING_WXPYTHON=OFF ^
..\src

cmake --build . --config %build% --target install -- /M

Recently I started to get this error at install time:

23:48:21 -- Found OpenGL: opengl32
23:48:21 CMake Error at C:/Program
Files/CMake/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:164
(message):
23:48:21   Could NOT find GLEW (missing: GLEW_INCLUDE_DIR GLEW_LIBRARY)
23:48:21 Call Stack (most recent call first):
23:48:21   C:/Program
Files/CMake/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:445
(_FPHSA_FAILURE_MESSAGE)
23:48:21   CMakeModules/FindGLEW.cmake:38 (find_package_handle_standard_args)
23:48:21   
C:/Jenkins/workspace/windows-kicad-msvc-vcpkg/build/release/cpu/x86/label/msvc/vcpkg/scripts/buildsystems/vcpkg.cmake:405
(_find_package)
23:48:21   CMakeLists.txt:586 (find_package)

On Tue, 7 Jul 2020 at 01:49, Mark Roszko  wrote:
>
> 1. cmake scripts already work with wxwidgets, that was already done awhile 
> back. I've been building with MSVC for awhile
>
>
>
> One dependency that'll need "porting" is ngspice.
> But let me put this out there, does it make sense to leave ngspice to a 
> higher level distro and not built as part of kicad?
> We've already had cases of repackaging Windows and macOS just to bump ngspice 
> versions up.
> Why not make it standard baseline as part of kicad instead of allowing 
> versions to be mixed?
>
>
> On Mon, Jul 6, 2020 at 3:04 PM Nick Østergaard  wrote:
>>
>> Just a FYI, we have not really solved wxpython phoenix for macos yet,
>> though some progress were made recently.
>>
>> For MSVC there are a number of issues yet to be addressed, this is
>> with the intention of using vcpkg.
>>  1. Fix cmake scripts for wxwidgets
>>  2. Add opencascade to vcpkg
>>  3. Add swig to vcpkg (or sip if that is what we want to use in the future)
>>  4. Probably a small handful of other things need to be done
>>
>> On Mon, 6 Jul 2020 at 20:35, Jeff Young  wrote:
>> >
>> > I love this part:
>> >
>> > wxPython4.0 (needed for Python3)
>> >
>> >
>> > And I thought our versioning was challenged. ;)
>> > ___
>> > 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
>
>
>
> --
> 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