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

[Nick Østergaard]

If anyone is using vcpkg based dependencies for building kicad with
msvc, could you please test the build configurations that I have
enabled on jenkins?

See https://jenkins.simonrichter.eu/job/windows-kicad-msvc-vcpkg/

The debug build fails for 64 bit builds, and there is some issue with
curl for 32 bit builts for both debug and release.

Nick Østergaard

On Wed, 8 Jul 2020 at 02:08, Wayne Stambaugh  wrote:
>
> 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 ^
> > > 

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

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

[Mark Roszko]

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

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

[Nick Østergaard]

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

[Jeff Young]

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

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

[Seth Hillbrand]

Hi Folks-

One aspect of KiCad v6 that is critical for us is the ability to move to 
Python3 on all platforms.  So far, we've been able to port Linux and 
MacOS but Windows remains the laggard.


There are a couple ways to proceed here for the interested developer.  
Our standard chain uses mingw32.  This build system does not yet support 
wxPython4.0 (needed for Python3).  The package in mingw32 could be 
updated to support wxPython4.0.


Alternatively, wxPython4 for Windows compiles using Microsoft Visual 
Studio.  We do not have a full build of KiCad and dependencies that 
works using MS Visual Studio and their packaging repository vcpkg.  That 
said, we've been moving in that direction with the main system, so 
adding the needed items to vcpkg for a full KiCad build may be easier.


Is there anyone on this list who'd be willing to take this project on?

Best-
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