Re: [Kicad-developers] Windows builds broken

[Wayne Stambaugh]

Nick,

Thanks, that did the trick.  I guess I need to update the build
documentation.

Wayne

On 5/1/2019 5:05 PM, Nick Østergaard wrote:
> Maybe it will be fixed in the next release of cmake
> https://gitlab.kitware.com/cmake/cmake/merge_requests/2747
> Found via https://gitlab.kitware.com/cmake/cmake/issues/18865
> 
> On Wed, 1 May 2019 at 22:34, Nick Østergaard  wrote:
>>
>> @Wayne, please note that I think there is a workaround. I have not
>> tested it myself, but I guess you can configure kicad with
>> Boost_NO_BOOST_CMAKE=ON as mention in the github issue.
>>
>> On Wed, 1 May 2019 at 20:33, Wayne Stambaugh  wrote:
>>>
>>> Jeff,
>>>
>>> I think that was a different issue.  My issue was link problem due to
>>> msys2 upgrading boost to 1.70 which apparently now uses CMake instead of
>>> the old b2 build system.  It looks like the new cmake stuff is not
>>> getting the boost link libraries correct.  I may take another look at it
>>> when I have some free time but I've go a bunch of stuff I need to work
>>> on rather than fixing platform specific build issues.
>>>
>>> Thanks,
>>>
>>> Wayne
>>>
>>> On 5/1/2019 7:53 AM, Jeff Young wrote:
 Someone on the forums had to turn off the qa tests on Linux to get it to 
 build:

 https://forum.kicad.info/t/call-for-testers-eemodern/16663/8


> On 1 May 2019, at 12:47, John Beard  wrote:
>
> Hi Wayne,
>
> I don't see any issues on the Jenkins Msys2 and MSVC builds. In fact, 
> it's green across the board:
>
> https://jenkins.simonrichter.eu/view/KiCad%20Status/
>
> What is the error? And when did it go wrong?
>
> Cheers,
>
> John
>
> On 01/05/2019 12:42, Wayne Stambaugh wrote:
>> Anyone else having build issues on windows?  I'm getting link errors for
>> the qa s-expr tests on both 32 and 64 bit builds.
>> Wayne
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


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

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

___
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] Windows builds broken

[Nick Østergaard]

Maybe it will be fixed in the next release of cmake
https://gitlab.kitware.com/cmake/cmake/merge_requests/2747
Found via https://gitlab.kitware.com/cmake/cmake/issues/18865

On Wed, 1 May 2019 at 22:34, Nick Østergaard  wrote:
>
> @Wayne, please note that I think there is a workaround. I have not
> tested it myself, but I guess you can configure kicad with
> Boost_NO_BOOST_CMAKE=ON as mention in the github issue.
>
> On Wed, 1 May 2019 at 20:33, Wayne Stambaugh  wrote:
> >
> > Jeff,
> >
> > I think that was a different issue.  My issue was link problem due to
> > msys2 upgrading boost to 1.70 which apparently now uses CMake instead of
> > the old b2 build system.  It looks like the new cmake stuff is not
> > getting the boost link libraries correct.  I may take another look at it
> > when I have some free time but I've go a bunch of stuff I need to work
> > on rather than fixing platform specific build issues.
> >
> > Thanks,
> >
> > Wayne
> >
> > On 5/1/2019 7:53 AM, Jeff Young wrote:
> > > Someone on the forums had to turn off the qa tests on Linux to get it to 
> > > build:
> > >
> > > https://forum.kicad.info/t/call-for-testers-eemodern/16663/8
> > >
> > >
> > >> On 1 May 2019, at 12:47, John Beard  wrote:
> > >>
> > >> Hi Wayne,
> > >>
> > >> I don't see any issues on the Jenkins Msys2 and MSVC builds. In fact, 
> > >> it's green across the board:
> > >>
> > >> https://jenkins.simonrichter.eu/view/KiCad%20Status/
> > >>
> > >> What is the error? And when did it go wrong?
> > >>
> > >> Cheers,
> > >>
> > >> John
> > >>
> > >> On 01/05/2019 12:42, Wayne Stambaugh wrote:
> > >>> Anyone else having build issues on windows?  I'm getting link errors for
> > >>> the qa s-expr tests on both 32 and 64 bit builds.
> > >>> Wayne
> > >>> ___
> > >>> Mailing list: https://launchpad.net/~kicad-developers
> > >>> Post to : kicad-developers@lists.launchpad.net
> > >>> Unsubscribe : https://launchpad.net/~kicad-developers
> > >>> More help   : https://help.launchpad.net/ListHelp
> > >>
> > >> ___
> > >> Mailing list: https://launchpad.net/~kicad-developers
> > >> Post to : kicad-developers@lists.launchpad.net
> > >> Unsubscribe : https://launchpad.net/~kicad-developers
> > >> More help   : https://help.launchpad.net/ListHelp
> > >
> > >
> > > ___
> > > Mailing list: https://launchpad.net/~kicad-developers
> > > Post to : kicad-developers@lists.launchpad.net
> > > Unsubscribe : https://launchpad.net/~kicad-developers
> > > More help   : https://help.launchpad.net/ListHelp
> > >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp

___
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] Windows builds broken

[Nick Østergaard]

@Wayne, please note that I think there is a workaround. I have not
tested it myself, but I guess you can configure kicad with
Boost_NO_BOOST_CMAKE=ON as mention in the github issue.

On Wed, 1 May 2019 at 20:33, Wayne Stambaugh  wrote:
>
> Jeff,
>
> I think that was a different issue.  My issue was link problem due to
> msys2 upgrading boost to 1.70 which apparently now uses CMake instead of
> the old b2 build system.  It looks like the new cmake stuff is not
> getting the boost link libraries correct.  I may take another look at it
> when I have some free time but I've go a bunch of stuff I need to work
> on rather than fixing platform specific build issues.
>
> Thanks,
>
> Wayne
>
> On 5/1/2019 7:53 AM, Jeff Young wrote:
> > Someone on the forums had to turn off the qa tests on Linux to get it to 
> > build:
> >
> > https://forum.kicad.info/t/call-for-testers-eemodern/16663/8
> >
> >
> >> On 1 May 2019, at 12:47, John Beard  wrote:
> >>
> >> Hi Wayne,
> >>
> >> I don't see any issues on the Jenkins Msys2 and MSVC builds. In fact, it's 
> >> green across the board:
> >>
> >> https://jenkins.simonrichter.eu/view/KiCad%20Status/
> >>
> >> What is the error? And when did it go wrong?
> >>
> >> Cheers,
> >>
> >> John
> >>
> >> On 01/05/2019 12:42, Wayne Stambaugh wrote:
> >>> Anyone else having build issues on windows?  I'm getting link errors for
> >>> the qa s-expr tests on both 32 and 64 bit builds.
> >>> Wayne
> >>> ___
> >>> Mailing list: https://launchpad.net/~kicad-developers
> >>> Post to : kicad-developers@lists.launchpad.net
> >>> Unsubscribe : https://launchpad.net/~kicad-developers
> >>> More help   : https://help.launchpad.net/ListHelp
> >>
> >> ___
> >> Mailing list: https://launchpad.net/~kicad-developers
> >> Post to : kicad-developers@lists.launchpad.net
> >> Unsubscribe : https://launchpad.net/~kicad-developers
> >> More help   : https://help.launchpad.net/ListHelp
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
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] Windows builds broken

[Wayne Stambaugh]

Jeff,

I think that was a different issue.  My issue was link problem due to
msys2 upgrading boost to 1.70 which apparently now uses CMake instead of
the old b2 build system.  It looks like the new cmake stuff is not
getting the boost link libraries correct.  I may take another look at it
when I have some free time but I've go a bunch of stuff I need to work
on rather than fixing platform specific build issues.

Thanks,

Wayne

On 5/1/2019 7:53 AM, Jeff Young wrote:
> Someone on the forums had to turn off the qa tests on Linux to get it to 
> build:
> 
> https://forum.kicad.info/t/call-for-testers-eemodern/16663/8
> 
> 
>> On 1 May 2019, at 12:47, John Beard  wrote:
>>
>> Hi Wayne,
>>
>> I don't see any issues on the Jenkins Msys2 and MSVC builds. In fact, it's 
>> green across the board:
>>
>> https://jenkins.simonrichter.eu/view/KiCad%20Status/
>>
>> What is the error? And when did it go wrong?
>>
>> Cheers,
>>
>> John
>>
>> On 01/05/2019 12:42, Wayne Stambaugh wrote:
>>> Anyone else having build issues on windows?  I'm getting link errors for
>>> the qa s-expr tests on both 32 and 64 bit builds.
>>> Wayne
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

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

Re: [Kicad-developers] Windows builds broken

[Wayne Stambaugh]

This is odd.  You are correct about PKGBUILD. Here is the contents of my
/mingw32/lib/cmake folder:

boost_atomic-1.70.0/
boost_chrono-1.70.0/
boost_container-1.70.0/
boost_context-1.70.0/
boost_contract-1.70.0/
boost_coroutine-1.70.0/
boost_date_time-1.70.0/
boost_exception-1.70.0/
boost_fiber_numa-1.70.0/
boost_fiber-1.70.0/
boost_filesystem-1.70.0/
boost_graph_parallel-1.70.0/
boost_graph-1.70.0/
boost_headers-1.70.0/
boost_iostreams-1.70.0/
boost_locale-1.70.0/
boost_log_setup-1.70.0/
boost_log-1.70.0/
boost_math_c99-1.70.0/
boost_math_c99f-1.70.0/
boost_math_c99l-1.70.0/
boost_math_tr1-1.70.0/
boost_math_tr1f-1.70.0/
boost_math_tr1l-1.70.0/
boost_math-1.70.0/
boost_numpy-1.70.0/
boost_prg_exec_monitor-1.70.0/
boost_program_options-1.70.0/
boost_python-1.70.0/
boost_random-1.70.0/
boost_regex-1.70.0/
boost_serialization-1.70.0/
boost_stacktrace_addr2line-1.70.0/
boost_stacktrace_backtrace-1.70.0/
boost_stacktrace_basic-1.70.0/
boost_stacktrace_noop-1.70.0/
boost_stacktrace_windbg_cached-1.70.0/
boost_stacktrace_windbg-1.70.0/
boost_system-1.70.0/
boost_test_exec_monitor-1.70.0/
boost_thread-1.70.0/
boost_timer-1.70.0/
boost_type_erasure-1.70.0/
boost_unit_test_framework-1.70.0/
boost_wave-1.70.0/
boost_wserialization-1.70.0/
Boost-1.70.0/
BoostDetectToolset-1.70.0.cmake
c-ares/
clang/
DBus1/
fftw3/
glew/
glm/
harfbuzz/
jsoncpp/
libxml2/
llvm/
minizip-exports.cmake
minizip-exports-release.cmake
openjpeg-2.3/
SDL2/
xapian/
z3/

Maybe ./b2 now just calls cmake to do the build.  I have never built
boost on msys2 using cmake or b2 so this wasn't me.  When I downgrade
boost, the boost_* folders get removed so something is different.

On 5/1/2019 11:55 AM, Nick Østergaard wrote:
> I don't think so, at least when I look at the PKGBUILD it is still
> using bootstrap.sh and b2 to build. See:
> https://github.com/msys2/MINGW-packages/blob/fd550b8d48e6bc831b1e36202eaf495cba5062f8/mingw-w64-boost/PKGBUILD
> 
> I don't see anything immediately alarming. Maybe the builds scripts in
> boost changed such that they need patching to work properly with
> msys2?
> 
> Also it seems that other people are struggling:
> https://github.com/msys2/MINGW-packages/issues/5233
> 
> Nick
> 
> On Wed, 1 May 2019 at 15:41, Wayne Stambaugh  wrote:
>>
>> On 5/1/2019 8:53 AM, John Beard wrote:
>>> On 01/05/2019 13:36, Wayne Stambaugh wrote:
 On 5/1/2019 8:27 AM, John Beard wrote:
> On 01/05/2019 12:53, Jeff Young wrote:
>> Someone on the forums had to turn off the qa tests on Linux to get it
>> to build:
 It fails during linking not compiling.  I also tried clang but I get the
 same error.  Here is the gcc command that is failing:
>>>
>>> Jeff's forum issue is a compiler failure in qa_kicad2step, not linking
>>> in qa_sexpr. I don't think it's related to this.
>>>
 cd /E/build/mingw64/kicad/product-debug/qa/libs/sexpr &&
 /E/msys64/mingw64/bin/g++.exe -Wall  -Wsuggest-override -Werror=vla
 -fpermissive -g3 -ggdb3 -DDEBUG -Wno-deprecated-declarations
 -Wl,--whole-archive CMakeFiles/qa_sexpr.dir/objects.a
 -Wl,--no-whole-archive  -o qa_sexpr.exe
 -Wl,--major-image-version,0,--minor-image-version,0
 ../../../libs/sexpr/libsexpr.a
 ../../unit_test_utils/libunit_test_utils.a -LE:/msys64/mingw64/lib -pipe
 -Wl,--subsystem,windows -mwindows -lwx_mswu_gl-3.0 -lwx_mswu_aui-3.0
 -lwx_mswu_adv-3.0 -lwx_mswu_html-3.0 -lwx_mswu_core-3.0
 -lwx_baseu_net-3.0 -lwx_baseu-3.0 -lwx_baseu_xml-3.0 -lwx_mswu_stc-3.0
 -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32
 -luuid -lcomdlg32 -ladvapi32
>>>
>>> Do *any* unit tests build? I don't see "-lboost_unit_test_framework
>>> -lboost_filesystem -lboost_system" in there, and it should be. Does
>>> CMake have the right paths? For me, it is like this:
>>>
>>>
>>> Boost_UNIT_TEST_FRAMEWORK_LIBRARY_DEBUG:FILEPATH=/usr/lib/libboost_unit_test_framework.so
>>
>> boost_unit_test_framework_DIR:PATH=E:/msys64/mingw32/lib/cmake/boost_unit_test_framework-1.70.0
>>
>> Looks like msys2 folks decided to use boost's cmake support to build
>> boost starting with 1.70 instead of the old boost build system.  I
>> thought this was still experimental but I could be wrong.  None the
>> less, boost 1.70 is broken on msys2 so I guess I will have to downgrade
>> and pin boost yet again :(  For everyone out there using msys2, do not
>> upgrade to boost 1.70.  If you did, downgrade boost to 1.69 and edit
>> your pacman.conf file to prevent boost from upgrading.
>>
>>>
>>>
>>> Sadly Arch hasn't got Boost 1.70 yet, so it's a bit tricky to test.
>>>
>>> Cheers,
>>>
>>> John
>>
>> ___
>> 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 

Re: [Kicad-developers] Windows builds broken

[Nick Østergaard]

I don't think so, at least when I look at the PKGBUILD it is still
using bootstrap.sh and b2 to build. See:
https://github.com/msys2/MINGW-packages/blob/fd550b8d48e6bc831b1e36202eaf495cba5062f8/mingw-w64-boost/PKGBUILD

I don't see anything immediately alarming. Maybe the builds scripts in
boost changed such that they need patching to work properly with
msys2?

Also it seems that other people are struggling:
https://github.com/msys2/MINGW-packages/issues/5233

Nick

On Wed, 1 May 2019 at 15:41, Wayne Stambaugh  wrote:
>
> On 5/1/2019 8:53 AM, John Beard wrote:
> > On 01/05/2019 13:36, Wayne Stambaugh wrote:
> >> On 5/1/2019 8:27 AM, John Beard wrote:
> >>> On 01/05/2019 12:53, Jeff Young wrote:
>  Someone on the forums had to turn off the qa tests on Linux to get it
>  to build:
> >> It fails during linking not compiling.  I also tried clang but I get the
> >> same error.  Here is the gcc command that is failing:
> >
> > Jeff's forum issue is a compiler failure in qa_kicad2step, not linking
> > in qa_sexpr. I don't think it's related to this.
> >
> >> cd /E/build/mingw64/kicad/product-debug/qa/libs/sexpr &&
> >> /E/msys64/mingw64/bin/g++.exe -Wall  -Wsuggest-override -Werror=vla
> >> -fpermissive -g3 -ggdb3 -DDEBUG -Wno-deprecated-declarations
> >> -Wl,--whole-archive CMakeFiles/qa_sexpr.dir/objects.a
> >> -Wl,--no-whole-archive  -o qa_sexpr.exe
> >> -Wl,--major-image-version,0,--minor-image-version,0
> >> ../../../libs/sexpr/libsexpr.a
> >> ../../unit_test_utils/libunit_test_utils.a -LE:/msys64/mingw64/lib -pipe
> >> -Wl,--subsystem,windows -mwindows -lwx_mswu_gl-3.0 -lwx_mswu_aui-3.0
> >> -lwx_mswu_adv-3.0 -lwx_mswu_html-3.0 -lwx_mswu_core-3.0
> >> -lwx_baseu_net-3.0 -lwx_baseu-3.0 -lwx_baseu_xml-3.0 -lwx_mswu_stc-3.0
> >> -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32
> >> -luuid -lcomdlg32 -ladvapi32
> >
> > Do *any* unit tests build? I don't see "-lboost_unit_test_framework
> > -lboost_filesystem -lboost_system" in there, and it should be. Does
> > CMake have the right paths? For me, it is like this:
> >
> >
> > Boost_UNIT_TEST_FRAMEWORK_LIBRARY_DEBUG:FILEPATH=/usr/lib/libboost_unit_test_framework.so
>
> boost_unit_test_framework_DIR:PATH=E:/msys64/mingw32/lib/cmake/boost_unit_test_framework-1.70.0
>
> Looks like msys2 folks decided to use boost's cmake support to build
> boost starting with 1.70 instead of the old boost build system.  I
> thought this was still experimental but I could be wrong.  None the
> less, boost 1.70 is broken on msys2 so I guess I will have to downgrade
> and pin boost yet again :(  For everyone out there using msys2, do not
> upgrade to boost 1.70.  If you did, downgrade boost to 1.69 and edit
> your pacman.conf file to prevent boost from upgrading.
>
> >
> >
> > Sadly Arch hasn't got Boost 1.70 yet, so it's a bit tricky to test.
> >
> > Cheers,
> >
> > John
>
> ___
> 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] Windows builds broken

[Wayne Stambaugh]

On 5/1/2019 8:53 AM, John Beard wrote:
> On 01/05/2019 13:36, Wayne Stambaugh wrote:
>> On 5/1/2019 8:27 AM, John Beard wrote:
>>> On 01/05/2019 12:53, Jeff Young wrote:
 Someone on the forums had to turn off the qa tests on Linux to get it
 to build:
>> It fails during linking not compiling.  I also tried clang but I get the
>> same error.  Here is the gcc command that is failing:
> 
> Jeff's forum issue is a compiler failure in qa_kicad2step, not linking
> in qa_sexpr. I don't think it's related to this.
> 
>> cd /E/build/mingw64/kicad/product-debug/qa/libs/sexpr &&
>> /E/msys64/mingw64/bin/g++.exe -Wall  -Wsuggest-override -Werror=vla
>> -fpermissive -g3 -ggdb3 -DDEBUG -Wno-deprecated-declarations
>> -Wl,--whole-archive CMakeFiles/qa_sexpr.dir/objects.a
>> -Wl,--no-whole-archive  -o qa_sexpr.exe
>> -Wl,--major-image-version,0,--minor-image-version,0
>> ../../../libs/sexpr/libsexpr.a
>> ../../unit_test_utils/libunit_test_utils.a -LE:/msys64/mingw64/lib -pipe
>> -Wl,--subsystem,windows -mwindows -lwx_mswu_gl-3.0 -lwx_mswu_aui-3.0
>> -lwx_mswu_adv-3.0 -lwx_mswu_html-3.0 -lwx_mswu_core-3.0
>> -lwx_baseu_net-3.0 -lwx_baseu-3.0 -lwx_baseu_xml-3.0 -lwx_mswu_stc-3.0
>> -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32
>> -luuid -lcomdlg32 -ladvapi32
> 
> Do *any* unit tests build? I don't see "-lboost_unit_test_framework
> -lboost_filesystem -lboost_system" in there, and it should be. Does
> CMake have the right paths? For me, it is like this:
> 
> 
> Boost_UNIT_TEST_FRAMEWORK_LIBRARY_DEBUG:FILEPATH=/usr/lib/libboost_unit_test_framework.so

boost_unit_test_framework_DIR:PATH=E:/msys64/mingw32/lib/cmake/boost_unit_test_framework-1.70.0

Looks like msys2 folks decided to use boost's cmake support to build
boost starting with 1.70 instead of the old boost build system.  I
thought this was still experimental but I could be wrong.  None the
less, boost 1.70 is broken on msys2 so I guess I will have to downgrade
and pin boost yet again :(  For everyone out there using msys2, do not
upgrade to boost 1.70.  If you did, downgrade boost to 1.69 and edit
your pacman.conf file to prevent boost from upgrading.

> 
> 
> Sadly Arch hasn't got Boost 1.70 yet, so it's a bit tricky to test.
> 
> Cheers,
> 
> John

___
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] Windows builds broken

[John Beard]

On 01/05/2019 13:36, Wayne Stambaugh wrote:

On 5/1/2019 8:27 AM, John Beard wrote:

On 01/05/2019 12:53, Jeff Young wrote:

Someone on the forums had to turn off the qa tests on Linux to get it
to build:

It fails during linking not compiling.  I also tried clang but I get the
same error.  Here is the gcc command that is failing:


Jeff's forum issue is a compiler failure in qa_kicad2step, not linking 
in qa_sexpr. I don't think it's related to this.



cd /E/build/mingw64/kicad/product-debug/qa/libs/sexpr &&
/E/msys64/mingw64/bin/g++.exe -Wall  -Wsuggest-override -Werror=vla
-fpermissive -g3 -ggdb3 -DDEBUG -Wno-deprecated-declarations
-Wl,--whole-archive CMakeFiles/qa_sexpr.dir/objects.a
-Wl,--no-whole-archive  -o qa_sexpr.exe
-Wl,--major-image-version,0,--minor-image-version,0
../../../libs/sexpr/libsexpr.a
../../unit_test_utils/libunit_test_utils.a -LE:/msys64/mingw64/lib -pipe
-Wl,--subsystem,windows -mwindows -lwx_mswu_gl-3.0 -lwx_mswu_aui-3.0
-lwx_mswu_adv-3.0 -lwx_mswu_html-3.0 -lwx_mswu_core-3.0
-lwx_baseu_net-3.0 -lwx_baseu-3.0 -lwx_baseu_xml-3.0 -lwx_mswu_stc-3.0
-lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32
-luuid -lcomdlg32 -ladvapi32


Do *any* unit tests build? I don't see "-lboost_unit_test_framework 
-lboost_filesystem -lboost_system" in there, and it should be. Does 
CMake have the right paths? For me, it is like this:



Boost_UNIT_TEST_FRAMEWORK_LIBRARY_DEBUG:FILEPATH=/usr/lib/libboost_unit_test_framework.so

Sadly Arch hasn't got Boost 1.70 yet, so it's a bit tricky to test.

Cheers,

John

___
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] Windows builds broken

[Wayne Stambaugh]

On 5/1/2019 8:27 AM, John Beard wrote:
> On 01/05/2019 12:53, Jeff Young wrote:
>> Someone on the forums had to turn off the qa tests on Linux to get it
>> to build:
>>
>> https://forum.kicad.info/t/call-for-testers-eemodern/16663/8
> This bit, right?
> 
> .../qa/utils/kicad2step/pcb/test_base.cpp: In member function ‘void
> PcbBase::SexprTo2DPosAndRot::test_method()’:
> /home/pedro/kicad/kicad-source-mirror/qa/utils/kicad2step/pcb/test_base.cpp:112:5:
> error: could not convert ‘{{"(at 0 0 0)", true, {0.0, 0.0}, 0.0}, {"(at
> 3.14 4.12 90.4)", true, {3.1401e+0, 4.1201e+0},
> DegToRad(9.0406e+1)}, {"(at 3.14)", false, (), ()}, {"(att
> 3.14 4.12 90.4)", false, (), ()}}’ from ‘’ to ‘const
> std::vectorPcbBase::TEST_2D_POS_ROT’
> };
> 
> Hmm, sounds like a compiler issue to me. Perhaps it can't hack the
> constexpr in the vector list init? What's the compiler & version?

Looks like I'm going to have to turn off the qa builds as well.
Something must be broken with the msys2 boost packages or boost 1.70
broke something.

> 
> Cheers,
> 
> John
> 
> ___
> 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] Windows builds broken

[Wayne Stambaugh]

On 5/1/2019 8:27 AM, John Beard wrote:
> On 01/05/2019 12:53, Jeff Young wrote:
>> Someone on the forums had to turn off the qa tests on Linux to get it
>> to build:
>>
>> https://forum.kicad.info/t/call-for-testers-eemodern/16663/8
> This bit, right?
> 
> .../qa/utils/kicad2step/pcb/test_base.cpp: In member function ‘void
> PcbBase::SexprTo2DPosAndRot::test_method()’:
> /home/pedro/kicad/kicad-source-mirror/qa/utils/kicad2step/pcb/test_base.cpp:112:5:
> error: could not convert ‘{{"(at 0 0 0)", true, {0.0, 0.0}, 0.0}, {"(at
> 3.14 4.12 90.4)", true, {3.1401e+0, 4.1201e+0},
> DegToRad(9.0406e+1)}, {"(at 3.14)", false, (), ()}, {"(att
> 3.14 4.12 90.4)", false, (), ()}}’ from ‘’ to ‘const
> std::vectorPcbBase::TEST_2D_POS_ROT’
> };
> 
> Hmm, sounds like a compiler issue to me. Perhaps it can't hack the
> constexpr in the vector list init? What's the compiler & version?

32 bit - gcc 7.4.0
64 bit - gcc 8.3.0

32 bit - clang 8.0.0
64 bit - clang 8.0.0

> 
> Cheers,
> 
> John
> 
> ___
> 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] Windows builds broken

[Wayne Stambaugh]

On 5/1/2019 8:27 AM, John Beard wrote:
> On 01/05/2019 12:53, Jeff Young wrote:
>> Someone on the forums had to turn off the qa tests on Linux to get it
>> to build:
>>
>> https://forum.kicad.info/t/call-for-testers-eemodern/16663/8
> This bit, right?
> 
> .../qa/utils/kicad2step/pcb/test_base.cpp: In member function ‘void
> PcbBase::SexprTo2DPosAndRot::test_method()’:
> /home/pedro/kicad/kicad-source-mirror/qa/utils/kicad2step/pcb/test_base.cpp:112:5:
> error: could not convert ‘{{"(at 0 0 0)", true, {0.0, 0.0}, 0.0}, {"(at
> 3.14 4.12 90.4)", true, {3.1401e+0, 4.1201e+0},
> DegToRad(9.0406e+1)}, {"(at 3.14)", false, (), ()}, {"(att
> 3.14 4.12 90.4)", false, (), ()}}’ from ‘’ to ‘const
> std::vectorPcbBase::TEST_2D_POS_ROT’
> };
> 
> Hmm, sounds like a compiler issue to me. Perhaps it can't hack the
> constexpr in the vector list init? What's the compiler & version?
> 
> Cheers,
> 
> John

It fails during linking not compiling.  I also tried clang but I get the
same error.  Here is the gcc command that is failing:

cd /E/build/mingw64/kicad/product-debug/qa/libs/sexpr &&
/E/msys64/mingw64/bin/cmake.exe -E remove -f
CMakeFiles/qa_sexpr.dir/objects.a
cd /E/build/mingw64/kicad/product-debug/qa/libs/sexpr &&
/E/msys64/mingw64/bin/ar.exe cr CMakeFiles/qa_sexpr.dir/objects.a
@CMakeFiles/qa_sexpr.dir/objects1.rsp
cd /E/build/mingw64/kicad/product-debug/qa/libs/sexpr &&
/E/msys64/mingw64/bin/g++.exe -Wall  -Wsuggest-override -Werror=vla
-fpermissive -g3 -ggdb3 -DDEBUG -Wno-deprecated-declarations
-Wl,--whole-archive CMakeFiles/qa_sexpr.dir/objects.a
-Wl,--no-whole-archive  -o qa_sexpr.exe
-Wl,--major-image-version,0,--minor-image-version,0
../../../libs/sexpr/libsexpr.a
../../unit_test_utils/libunit_test_utils.a -LE:/msys64/mingw64/lib -pipe
-Wl,--subsystem,windows -mwindows -lwx_mswu_gl-3.0 -lwx_mswu_aui-3.0
-lwx_mswu_adv-3.0 -lwx_mswu_html-3.0 -lwx_mswu_core-3.0
-lwx_baseu_net-3.0 -lwx_baseu-3.0 -lwx_baseu_xml-3.0 -lwx_mswu_stc-3.0
-lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32
-luuid -lcomdlg32 -ladvapi32

___
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] Windows builds broken

[John Beard]

On 01/05/2019 12:53, Jeff Young wrote:

Someone on the forums had to turn off the qa tests on Linux to get it to build:

https://forum.kicad.info/t/call-for-testers-eemodern/16663/8

This bit, right?

.../qa/utils/kicad2step/pcb/test_base.cpp: In member function ‘void 
PcbBase::SexprTo2DPosAndRot::test_method()’:
/home/pedro/kicad/kicad-source-mirror/qa/utils/kicad2step/pcb/test_base.cpp:112:5: 
error: could not convert ‘{{"(at 0 0 0)", true, {0.0, 0.0}, 0.0}, {"(at 
3.14 4.12 90.4)", true, {3.1401e+0, 4.1201e+0}, 
DegToRad(9.0406e+1)}, {"(at 3.14)", false, (), ()}, {"(att 
3.14 4.12 90.4)", false, (), ()}}’ from ‘’ to ‘const 
std::vectorPcbBase::TEST_2D_POS_ROT’

};

Hmm, sounds like a compiler issue to me. Perhaps it can't hack the 
constexpr in the vector list init? What's the compiler & version?


Cheers,

John

___
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] Windows builds broken

[Wayne Stambaugh]

Clean build fails as well.  I did upgrade msys2 yesterday so maybe
something is borked with msys2.

On 5/1/2019 7:53 AM, Wayne Stambaugh wrote:
> Hey John,
> 
> I'll try a clean build to see if that fixes it.  I rarely have to do
> that.  I haven't done a windows build in a while so I was a bit
> surprised.  I've attached the build error.
> 
> Wayne
> 
> 
> On 5/1/2019 7:47 AM, John Beard wrote:
>> Hi Wayne,
>>
>> I don't see any issues on the Jenkins Msys2 and MSVC builds. In fact,
>> it's green across the board:
>>
>> https://jenkins.simonrichter.eu/view/KiCad%20Status/
>>
>> What is the error? And when did it go wrong?
>>
>> Cheers,
>>
>> John
>>
>> On 01/05/2019 12:42, Wayne Stambaugh wrote:
>>> Anyone else having build issues on windows?  I'm getting link errors for
>>> the qa s-expr tests on both 32 and 64 bit builds.
>>>
>>> Wayne
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] Windows builds broken

[John Beard]

On 01/05/2019 12:53, Wayne Stambaugh wrote:


I'll try a clean build to see if that fixes it.  I rarely have to do
that.  I haven't done a windows build in a while so I was a bit
surprised.  I've attached the build error.


Hmm, have you upgraded Boost or something? IIRC, Boost 1.70 was just 
released? Looks like it can't find any of the Boost library functions at 
link. Could be an upgrade moved them and CMake has stale cached variables?


Running make VERBOSE=1 qa_sexpr will print the command used to do the 
link, which should show the paths that are being used.


Cheers,

John

___
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] Windows builds broken

[Wayne Stambaugh]

Hey John,

I'll try a clean build to see if that fixes it.  I rarely have to do
that.  I haven't done a windows build in a while so I was a bit
surprised.  I've attached the build error.

Wayne


On 5/1/2019 7:47 AM, John Beard wrote:
> Hi Wayne,
> 
> I don't see any issues on the Jenkins Msys2 and MSVC builds. In fact,
> it's green across the board:
> 
> https://jenkins.simonrichter.eu/view/KiCad%20Status/
> 
> What is the error? And when did it go wrong?
> 
> Cheers,
> 
> John
> 
> On 01/05/2019 12:42, Wayne Stambaugh wrote:
>> Anyone else having build issues on windows?  I'm getting link errors for
>> the qa s-expr tests on both 32 and 64 bit builds.
>>
>> Wayne
>>
>> ___
>> 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
CMakeFiles/qa_sexpr.dir/objects.a(test_module.cpp.obj):test_module.cpp:(.text+0x5):
 undefined reference to 
`_imp___ZN5boost9unit_test9framework17master_test_suiteEv'
CMakeFiles/qa_sexpr.dir/objects.a(test_module.cpp.obj):test_module.cpp:(.text.startup+0x25):
 undefined reference to `_imp___ZN5boost9unit_test14unit_test_mainEPFbvEiPPc'
CMakeFiles/qa_sexpr.dir/objects.a(test_module.cpp.obj):test_module.cpp:(.text.startup+0x35):
 undefined reference to `_imp___ZN5boost9unit_test15unit_test_log_t8instanceEv'
CMakeFiles/qa_sexpr.dir/objects.a(test_sexpr.cpp.obj):test_sexpr.cpp:(.text+0x84):
 undefined reference to 
`_imp___ZN5boost9unit_test15unit_test_log_t14set_checkpointENS0_13basic_cstringIKcEEjS4_'
CMakeFiles/qa_sexpr.dir/objects.a(test_sexpr.cpp.obj):test_sexpr.cpp:(.text+0x96):
 undefined reference to `_imp___ZN5boost9unit_test12lazy_ostream4instE'
CMakeFiles/qa_sexpr.dir/objects.a(test_sexpr.cpp.obj):test_sexpr.cpp:(.text+0x219):
 undefined reference to 
`_imp___ZN5boost9unit_test9framework11add_contextERKNS0_12lazy_ostreamEb'
CMakeFiles/qa_sexpr.dir/objects.a(test_sexpr.cpp.obj):test_sexpr.cpp:(.text+0x2a1):
 undefined reference to 
`_imp___ZN5boost10test_tools9tt_detail16report_assertionERKNS0_16assertion_resultERKNS_9unit_test12lazy_ostreamENS5_13basic_cstringIKcEEjNS1_10tool_levelENS1_10check_typeEjz'
CMakeFiles/qa_sexpr.dir/objects.a(test_sexpr.cpp.obj):test_sexpr.cpp:(.text+0x3ef):
 undefined reference to 
`_imp___ZN5boost9unit_test15unit_test_log_t14set_checkpointENS0_13basic_cstringIKcEEjS4_'
CMakeFiles/qa_sexpr.dir/objects.a(test_sexpr.cpp.obj):test_sexpr.cpp:(.text+0x401):
 undefined reference to `_imp___ZN5boost9unit_test12lazy_ostream4instE'
CMakeFiles/qa_sexpr.dir/objects.a(test_sexpr.cpp.obj):test_sexpr.cpp:(.text+0x586):
 undefined reference to 
`_imp___ZN5boost9unit_test9framework11add_contextERKNS0_12lazy_ostreamEb'
CMakeFiles/qa_sexpr.dir/objects.a(test_sexpr.cpp.obj):test_sexpr.cpp:(.text+0x60e):
 undefined reference to 
`_imp___ZN5boost10test_tools9tt_detail16report_assertionERKNS0_16assertion_resultERKNS_9unit_test12lazy_ostreamENS5_13basic_cstringIKcEEjNS1_10tool_levelENS1_10check_typeEjz'
CMakeFiles/qa_sexpr.dir/objects.a(test_sexpr.cpp.obj):test_sexpr.cpp:(.text+0x7e0):
 undefined reference to 
`_imp___ZN5boost9unit_test15unit_test_log_t14set_checkpointENS0_13basic_cstringIKcEEjS4_'
CMakeFiles/qa_sexpr.dir/objects.a(test_sexpr.cpp.obj):test_sexpr.cpp:(.text+0x7e5):
 undefined reference to `_imp___ZN5boost9unit_test12lazy_ostream4instE'
CMakeFiles/qa_sexpr.dir/objects.a(test_sexpr.cpp.obj):test_sexpr.cpp:(.text+0x83b):
 undefined reference to `_imp___ZN5boost9unit_test12lazy_ostream4instE'
CMakeFiles/qa_sexpr.dir/objects.a(test_sexpr.cpp.obj):test_sexpr.cpp:(.text+0x88e):
 undefined reference to `_imp___ZN5boost9unit_test12lazy_ostream4instE'
CMakeFiles/qa_sexpr.dir/objects.a(test_sexpr.cpp.obj):test_sexpr.cpp:(.text+0x8da):
 undefined reference to `_imp___ZN5boost9unit_test12lazy_ostream4instE'
CMakeFiles/qa_sexpr.dir/objects.a(test_sexpr.cpp.obj):test_sexpr.cpp:(.text+0x99a):
 undefined reference to 
`_imp___ZN5boost9unit_test9framework11add_contextERKNS0_12lazy_ostreamEb'
CMakeFiles/qa_sexpr.dir/objects.a(test_sexpr.cpp.obj):test_sexpr.cpp:(.text+0xa22):
 undefined reference to 
`_imp___ZN5boost10test_tools9tt_detail16report_assertionERKNS0_16assertion_resultERKNS_9unit_test12lazy_ostreamENS5_13basic_cstringIKcEEjNS1_10tool_levelENS1_10check_typeEjz'
CMakeFiles/qa_sexpr.dir/objects.a(test_sexpr.cpp.obj):test_sexpr.cpp:(.text+0xcb0):
 undefined reference to 
`_imp___ZN5boost9unit_test15unit_test_log_t14set_checkpointENS0_13basic_cstringIKcEEjS4_'
CMakeFiles/qa_sexpr.dir/objects.a(test_sexpr.cpp.obj):test_sexpr.cpp:(.text+0xcb5):
 undefined reference to 

Re: [Kicad-developers] Windows builds broken

[Jeff Young]

Someone on the forums had to turn off the qa tests on Linux to get it to build:

https://forum.kicad.info/t/call-for-testers-eemodern/16663/8


> On 1 May 2019, at 12:47, John Beard  wrote:
> 
> Hi Wayne,
> 
> I don't see any issues on the Jenkins Msys2 and MSVC builds. In fact, it's 
> green across the board:
> 
> https://jenkins.simonrichter.eu/view/KiCad%20Status/
> 
> What is the error? And when did it go wrong?
> 
> Cheers,
> 
> John
> 
> On 01/05/2019 12:42, Wayne Stambaugh wrote:
>> Anyone else having build issues on windows?  I'm getting link errors for
>> the qa s-expr tests on both 32 and 64 bit builds.
>> Wayne
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


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

Re: [Kicad-developers] Windows builds broken

[John Beard]

Hi Wayne,

I don't see any issues on the Jenkins Msys2 and MSVC builds. In fact, 
it's green across the board:


https://jenkins.simonrichter.eu/view/KiCad%20Status/

What is the error? And when did it go wrong?

Cheers,

John

On 01/05/2019 12:42, Wayne Stambaugh wrote:

Anyone else having build issues on windows?  I'm getting link errors for
the qa s-expr tests on both 32 and 64 bit builds.

Wayne

___
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] Windows Builds

[Wayne Stambaugh]

Thank you gentlemen.  I appreciate the support.

Wayne

On 7/25/2018 2:58 PM, Adam Wolf wrote:
> Nice work team!
> 
> On Wed, Jul 25, 2018, 1:57 PM Mark Roszko  > wrote:
> 
> Appears Simon has handled it, the downloads are updated.
> 
> I installed it and it no longer asserts.
> 
> On Wed, Jul 25, 2018 at 1:20 PM Wayne Stambaugh
> mailto:stambau...@gmail.com>> wrote:
> >
> > On 7/25/2018 12:54 PM, Mark Roszko wrote:
> > > * Simon's pull request.
> > >
> > > https://github.com/KiCad/kicad-winbuilder/pull/74
> >
> > Nick must have given me admin permissions so I merged Simon's pull
> > request.  The new release packages should be available shortly.  Do I
> > need to do anything to make sure the rebuilt packages are available on
> > the kicad download page?
> >
> > > On Wed, Jul 25, 2018 at 12:33 PM Wayne Stambaugh
> mailto:stambau...@gmail.com>> wrote:
> > >>
> > >> I believe have github admin permissions at the org level. 
> Please post
> > >> the link to Mark's pull request and I will see if I can merge it.
> > >>
> > >> On 7/25/2018 12:29 PM, Adam Wolf wrote:
> > >>> Does anyone else have admin permissions at the org level?
> > >>>
> > >>> On Wed, Jul 25, 2018, 11:19 AM Wayne Stambaugh
> mailto:stambau...@gmail.com>
> > >>> >>
> wrote:
> > >>>
> > >>>     On 7/25/2018 11:15 AM, Mark Roszko wrote:
> > >>>     > @Wayne, The hold up on Windows was that Nick went on
> vacation
> > >>>     > basically the day after posting the first 5.0 build. So
> bad timing.>
> > >>>     >
> > >>>     >> I've changed it to Release for the time being (but
> someone still
> > >>>     needs to accept my pull request in GitHub)
> > >>>     >
> > >>>     > Unforunately Nick is the only one with privs on the
> winbuilder repo on
> > >>>     > github unless someone else does from the organization
> level access
> > >>>     > list.
> > >>>
> > >>>     I guess we will have to wait until Nick returns from
> vacation to get
> > >>>     this resolved.  Once he gets back, I'll ping him about
> having him assign
> > >>>     privileges to someone else as a backup so we don't get bit
> by this in
> > >>>     the future.
> > >>>
> > >>>     >
> > >>>     >> RelWithDebInfo should generate the same code as
> Release, and
> > >>>     after stripping debug information, the binaries should be
> identical.
> > >>>     >
> > >>>     > You know, looking at your commit, its interesting.
> Because PKGBUILD
> > >>>     > which you change from RelWithDebInfo to Release
> explicitly was always
> > >>>     > fine, the nightlies never gave that assert (I checked).
> > >>>     > But PKGBUILD-STABLE had no config specifiedso
> perhaps it drifted
> > >>>     > to DEBUG somehow?
> > >>>     >
> > >>>     > On Wed, Jul 25, 2018 at 9:09 AM Simon Richter
> > >>>        >> wrote:
> > >>>     >>
> > >>>     >> Hi,
> > >>>     >>
> > >>>     >> On 25.07.2018 14:16, Wayne Stambaugh wrote:
> > >>>     >>
> > >>>     >>> We should have created a release build of the stable
> version.
> > >>>     I'm fine
> > >>>     >>> with nightly builds having debugging information. 
> Stable releases
> > >>>     >>> should not have debug info.
> > >>>     >>
> > >>>     >> These are built as RelWithDebInfo, and the debug
> information is
> > >>>     stripped
> > >>>     >> out during installation, or rather should be (we're
> trying to
> > >>>     keep the
> > >>>     >> MSYS build as close to a standard Linux/BSD build as
> possible,
> > >>>     and they
> > >>>     >> usually archive the debug information separately before
> > >>>     stripping, which
> > >>>     >> is why this mode is useful at all).
> > >>>     >>
> > >>>     >> I've changed it to Release for the time being (but
> someone still
> > >>>     needs
> > >>>     >> to accept my pull request in GitHub), but this is
> indicative of a
> > >>>     bug in
> > >>>     >> the build scripts. RelWithDebInfo should generate the
> same code as
> > >>>     >> Release, and after stripping debug information, the
> binaries
> > >>>     should be
> > >>>     >> identical.
> > >>>     >>
> > >>>     >> There are two problems I see:
> > >>>     >>
> > >>>     >>  - we check explicitly if the build type is Release,
> which then
> > >>>     doesn't
> > >>>     >> match
> > >>>     >>  - we have a redundant -DDEBUG which is explicitly set
> — release
> > >>>     builds
> > 

Re: [Kicad-developers] Windows Builds

[Maciej Suminski]

Thank you all! It was the #1 issue with the 5.0 release.

Cheers,
Orson

On 07/25/2018 08:57 PM, Mark Roszko wrote:
> Appears Simon has handled it, the downloads are updated.
> 
> I installed it and it no longer asserts.
> 
> On Wed, Jul 25, 2018 at 1:20 PM Wayne Stambaugh  wrote:
>>
>> On 7/25/2018 12:54 PM, Mark Roszko wrote:
>>> * Simon's pull request.
>>>
>>> https://github.com/KiCad/kicad-winbuilder/pull/74
>>
>> Nick must have given me admin permissions so I merged Simon's pull
>> request.  The new release packages should be available shortly.  Do I
>> need to do anything to make sure the rebuilt packages are available on
>> the kicad download page?
>>
>>> On Wed, Jul 25, 2018 at 12:33 PM Wayne Stambaugh  
>>> wrote:

 I believe have github admin permissions at the org level.  Please post
 the link to Mark's pull request and I will see if I can merge it.

 On 7/25/2018 12:29 PM, Adam Wolf wrote:
> Does anyone else have admin permissions at the org level?
>
> On Wed, Jul 25, 2018, 11:19 AM Wayne Stambaugh  > wrote:
>
> On 7/25/2018 11:15 AM, Mark Roszko wrote:
> > @Wayne, The hold up on Windows was that Nick went on vacation
> > basically the day after posting the first 5.0 build. So bad timing.>
> >
> >> I've changed it to Release for the time being (but someone still
> needs to accept my pull request in GitHub)
> >
> > Unforunately Nick is the only one with privs on the winbuilder repo 
> on
> > github unless someone else does from the organization level access
> > list.
>
> I guess we will have to wait until Nick returns from vacation to get
> this resolved.  Once he gets back, I'll ping him about having him 
> assign
> privileges to someone else as a backup so we don't get bit by this in
> the future.
>
> >
> >> RelWithDebInfo should generate the same code as Release, and
> after stripping debug information, the binaries should be identical.
> >
> > You know, looking at your commit, its interesting. Because PKGBUILD
> > which you change from RelWithDebInfo to Release explicitly was 
> always
> > fine, the nightlies never gave that assert (I checked).
> > But PKGBUILD-STABLE had no config specifiedso perhaps it drifted
> > to DEBUG somehow?
> >
> > On Wed, Jul 25, 2018 at 9:09 AM Simon Richter
> mailto:simon.rich...@hogyros.de>> wrote:
> >>
> >> Hi,
> >>
> >> On 25.07.2018 14:16, Wayne Stambaugh wrote:
> >>
> >>> We should have created a release build of the stable version.
> I'm fine
> >>> with nightly builds having debugging information.  Stable releases
> >>> should not have debug info.
> >>
> >> These are built as RelWithDebInfo, and the debug information is
> stripped
> >> out during installation, or rather should be (we're trying to
> keep the
> >> MSYS build as close to a standard Linux/BSD build as possible,
> and they
> >> usually archive the debug information separately before
> stripping, which
> >> is why this mode is useful at all).
> >>
> >> I've changed it to Release for the time being (but someone still
> needs
> >> to accept my pull request in GitHub), but this is indicative of a
> bug in
> >> the build scripts. RelWithDebInfo should generate the same code as
> >> Release, and after stripping debug information, the binaries
> should be
> >> identical.
> >>
> >> There are two problems I see:
> >>
> >>  - we check explicitly if the build type is Release, which then
> doesn't
> >> match
> >>  - we have a redundant -DDEBUG which is explicitly set — release
> builds
> >> have -DNDEBUG, which is set by CMake already, and this is what 
> should
> >> switch debugging facilities like asserts.
> >>
> >> I've submitted a patch to get rid of -DDEBUG two years ago, I
> doubt it
> >> still applies. I can make a new one if it has a chance of being
> applied.
> >>
> >>Simon
> >>
> >> ___
> >> 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] Windows Builds

[Adam Wolf]

Nice work team!

On Wed, Jul 25, 2018, 1:57 PM Mark Roszko  wrote:

> Appears Simon has handled it, the downloads are updated.
>
> I installed it and it no longer asserts.
>
> On Wed, Jul 25, 2018 at 1:20 PM Wayne Stambaugh 
> wrote:
> >
> > On 7/25/2018 12:54 PM, Mark Roszko wrote:
> > > * Simon's pull request.
> > >
> > > https://github.com/KiCad/kicad-winbuilder/pull/74
> >
> > Nick must have given me admin permissions so I merged Simon's pull
> > request.  The new release packages should be available shortly.  Do I
> > need to do anything to make sure the rebuilt packages are available on
> > the kicad download page?
> >
> > > On Wed, Jul 25, 2018 at 12:33 PM Wayne Stambaugh 
> wrote:
> > >>
> > >> I believe have github admin permissions at the org level.  Please post
> > >> the link to Mark's pull request and I will see if I can merge it.
> > >>
> > >> On 7/25/2018 12:29 PM, Adam Wolf wrote:
> > >>> Does anyone else have admin permissions at the org level?
> > >>>
> > >>> On Wed, Jul 25, 2018, 11:19 AM Wayne Stambaugh  > >>> > wrote:
> > >>>
> > >>> On 7/25/2018 11:15 AM, Mark Roszko wrote:
> > >>> > @Wayne, The hold up on Windows was that Nick went on vacation
> > >>> > basically the day after posting the first 5.0 build. So bad
> timing.>
> > >>> >
> > >>> >> I've changed it to Release for the time being (but someone
> still
> > >>> needs to accept my pull request in GitHub)
> > >>> >
> > >>> > Unforunately Nick is the only one with privs on the winbuilder
> repo on
> > >>> > github unless someone else does from the organization level
> access
> > >>> > list.
> > >>>
> > >>> I guess we will have to wait until Nick returns from vacation to
> get
> > >>> this resolved.  Once he gets back, I'll ping him about having
> him assign
> > >>> privileges to someone else as a backup so we don't get bit by
> this in
> > >>> the future.
> > >>>
> > >>> >
> > >>> >> RelWithDebInfo should generate the same code as Release, and
> > >>> after stripping debug information, the binaries should be
> identical.
> > >>> >
> > >>> > You know, looking at your commit, its interesting. Because
> PKGBUILD
> > >>> > which you change from RelWithDebInfo to Release explicitly was
> always
> > >>> > fine, the nightlies never gave that assert (I checked).
> > >>> > But PKGBUILD-STABLE had no config specifiedso perhaps it
> drifted
> > >>> > to DEBUG somehow?
> > >>> >
> > >>> > On Wed, Jul 25, 2018 at 9:09 AM Simon Richter
> > >>> mailto:simon.rich...@hogyros.de>>
> wrote:
> > >>> >>
> > >>> >> Hi,
> > >>> >>
> > >>> >> On 25.07.2018 14:16, Wayne Stambaugh wrote:
> > >>> >>
> > >>> >>> We should have created a release build of the stable version.
> > >>> I'm fine
> > >>> >>> with nightly builds having debugging information.  Stable
> releases
> > >>> >>> should not have debug info.
> > >>> >>
> > >>> >> These are built as RelWithDebInfo, and the debug information
> is
> > >>> stripped
> > >>> >> out during installation, or rather should be (we're trying to
> > >>> keep the
> > >>> >> MSYS build as close to a standard Linux/BSD build as possible,
> > >>> and they
> > >>> >> usually archive the debug information separately before
> > >>> stripping, which
> > >>> >> is why this mode is useful at all).
> > >>> >>
> > >>> >> I've changed it to Release for the time being (but someone
> still
> > >>> needs
> > >>> >> to accept my pull request in GitHub), but this is indicative
> of a
> > >>> bug in
> > >>> >> the build scripts. RelWithDebInfo should generate the same
> code as
> > >>> >> Release, and after stripping debug information, the binaries
> > >>> should be
> > >>> >> identical.
> > >>> >>
> > >>> >> There are two problems I see:
> > >>> >>
> > >>> >>  - we check explicitly if the build type is Release, which
> then
> > >>> doesn't
> > >>> >> match
> > >>> >>  - we have a redundant -DDEBUG which is explicitly set —
> release
> > >>> builds
> > >>> >> have -DNDEBUG, which is set by CMake already, and this is
> what should
> > >>> >> switch debugging facilities like asserts.
> > >>> >>
> > >>> >> I've submitted a patch to get rid of -DDEBUG two years ago, I
> > >>> doubt it
> > >>> >> still applies. I can make a new one if it has a chance of
> being
> > >>> applied.
> > >>> >>
> > >>> >>Simon
> > >>> >>
> > >>> >> ___
> > >>> >> Mailing list: https://launchpad.net/~kicad-developers
> > >>> 
> > >>> >> Post to : kicad-developers@lists.launchpad.net
> > >>> 
> > >>> >> Unsubscribe : https://launchpad.net/~kicad-developers
> > >>> 

Re: [Kicad-developers] Windows Builds

[Mark Roszko]

Appears Simon has handled it, the downloads are updated.

I installed it and it no longer asserts.

On Wed, Jul 25, 2018 at 1:20 PM Wayne Stambaugh  wrote:
>
> On 7/25/2018 12:54 PM, Mark Roszko wrote:
> > * Simon's pull request.
> >
> > https://github.com/KiCad/kicad-winbuilder/pull/74
>
> Nick must have given me admin permissions so I merged Simon's pull
> request.  The new release packages should be available shortly.  Do I
> need to do anything to make sure the rebuilt packages are available on
> the kicad download page?
>
> > On Wed, Jul 25, 2018 at 12:33 PM Wayne Stambaugh  
> > wrote:
> >>
> >> I believe have github admin permissions at the org level.  Please post
> >> the link to Mark's pull request and I will see if I can merge it.
> >>
> >> On 7/25/2018 12:29 PM, Adam Wolf wrote:
> >>> Does anyone else have admin permissions at the org level?
> >>>
> >>> On Wed, Jul 25, 2018, 11:19 AM Wayne Stambaugh  >>> > wrote:
> >>>
> >>> On 7/25/2018 11:15 AM, Mark Roszko wrote:
> >>> > @Wayne, The hold up on Windows was that Nick went on vacation
> >>> > basically the day after posting the first 5.0 build. So bad timing.>
> >>> >
> >>> >> I've changed it to Release for the time being (but someone still
> >>> needs to accept my pull request in GitHub)
> >>> >
> >>> > Unforunately Nick is the only one with privs on the winbuilder repo 
> >>> on
> >>> > github unless someone else does from the organization level access
> >>> > list.
> >>>
> >>> I guess we will have to wait until Nick returns from vacation to get
> >>> this resolved.  Once he gets back, I'll ping him about having him 
> >>> assign
> >>> privileges to someone else as a backup so we don't get bit by this in
> >>> the future.
> >>>
> >>> >
> >>> >> RelWithDebInfo should generate the same code as Release, and
> >>> after stripping debug information, the binaries should be identical.
> >>> >
> >>> > You know, looking at your commit, its interesting. Because PKGBUILD
> >>> > which you change from RelWithDebInfo to Release explicitly was 
> >>> always
> >>> > fine, the nightlies never gave that assert (I checked).
> >>> > But PKGBUILD-STABLE had no config specifiedso perhaps it drifted
> >>> > to DEBUG somehow?
> >>> >
> >>> > On Wed, Jul 25, 2018 at 9:09 AM Simon Richter
> >>> mailto:simon.rich...@hogyros.de>> wrote:
> >>> >>
> >>> >> Hi,
> >>> >>
> >>> >> On 25.07.2018 14:16, Wayne Stambaugh wrote:
> >>> >>
> >>> >>> We should have created a release build of the stable version.
> >>> I'm fine
> >>> >>> with nightly builds having debugging information.  Stable releases
> >>> >>> should not have debug info.
> >>> >>
> >>> >> These are built as RelWithDebInfo, and the debug information is
> >>> stripped
> >>> >> out during installation, or rather should be (we're trying to
> >>> keep the
> >>> >> MSYS build as close to a standard Linux/BSD build as possible,
> >>> and they
> >>> >> usually archive the debug information separately before
> >>> stripping, which
> >>> >> is why this mode is useful at all).
> >>> >>
> >>> >> I've changed it to Release for the time being (but someone still
> >>> needs
> >>> >> to accept my pull request in GitHub), but this is indicative of a
> >>> bug in
> >>> >> the build scripts. RelWithDebInfo should generate the same code as
> >>> >> Release, and after stripping debug information, the binaries
> >>> should be
> >>> >> identical.
> >>> >>
> >>> >> There are two problems I see:
> >>> >>
> >>> >>  - we check explicitly if the build type is Release, which then
> >>> doesn't
> >>> >> match
> >>> >>  - we have a redundant -DDEBUG which is explicitly set — release
> >>> builds
> >>> >> have -DNDEBUG, which is set by CMake already, and this is what 
> >>> should
> >>> >> switch debugging facilities like asserts.
> >>> >>
> >>> >> I've submitted a patch to get rid of -DDEBUG two years ago, I
> >>> doubt it
> >>> >> still applies. I can make a new one if it has a chance of being
> >>> applied.
> >>> >>
> >>> >>Simon
> >>> >>
> >>> >> ___
> >>> >> 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
> >>> 

Re: [Kicad-developers] Windows Builds

[Wayne Stambaugh]

On 7/25/2018 12:54 PM, Mark Roszko wrote:
> * Simon's pull request.
> 
> https://github.com/KiCad/kicad-winbuilder/pull/74

Nick must have given me admin permissions so I merged Simon's pull
request.  The new release packages should be available shortly.  Do I
need to do anything to make sure the rebuilt packages are available on
the kicad download page?

> On Wed, Jul 25, 2018 at 12:33 PM Wayne Stambaugh  wrote:
>>
>> I believe have github admin permissions at the org level.  Please post
>> the link to Mark's pull request and I will see if I can merge it.
>>
>> On 7/25/2018 12:29 PM, Adam Wolf wrote:
>>> Does anyone else have admin permissions at the org level?
>>>
>>> On Wed, Jul 25, 2018, 11:19 AM Wayne Stambaugh >> > wrote:
>>>
>>> On 7/25/2018 11:15 AM, Mark Roszko wrote:
>>> > @Wayne, The hold up on Windows was that Nick went on vacation
>>> > basically the day after posting the first 5.0 build. So bad timing.>
>>> >
>>> >> I've changed it to Release for the time being (but someone still
>>> needs to accept my pull request in GitHub)
>>> >
>>> > Unforunately Nick is the only one with privs on the winbuilder repo on
>>> > github unless someone else does from the organization level access
>>> > list.
>>>
>>> I guess we will have to wait until Nick returns from vacation to get
>>> this resolved.  Once he gets back, I'll ping him about having him assign
>>> privileges to someone else as a backup so we don't get bit by this in
>>> the future.
>>>
>>> >
>>> >> RelWithDebInfo should generate the same code as Release, and
>>> after stripping debug information, the binaries should be identical.
>>> >
>>> > You know, looking at your commit, its interesting. Because PKGBUILD
>>> > which you change from RelWithDebInfo to Release explicitly was always
>>> > fine, the nightlies never gave that assert (I checked).
>>> > But PKGBUILD-STABLE had no config specifiedso perhaps it drifted
>>> > to DEBUG somehow?
>>> >
>>> > On Wed, Jul 25, 2018 at 9:09 AM Simon Richter
>>> mailto:simon.rich...@hogyros.de>> wrote:
>>> >>
>>> >> Hi,
>>> >>
>>> >> On 25.07.2018 14:16, Wayne Stambaugh wrote:
>>> >>
>>> >>> We should have created a release build of the stable version.
>>> I'm fine
>>> >>> with nightly builds having debugging information.  Stable releases
>>> >>> should not have debug info.
>>> >>
>>> >> These are built as RelWithDebInfo, and the debug information is
>>> stripped
>>> >> out during installation, or rather should be (we're trying to
>>> keep the
>>> >> MSYS build as close to a standard Linux/BSD build as possible,
>>> and they
>>> >> usually archive the debug information separately before
>>> stripping, which
>>> >> is why this mode is useful at all).
>>> >>
>>> >> I've changed it to Release for the time being (but someone still
>>> needs
>>> >> to accept my pull request in GitHub), but this is indicative of a
>>> bug in
>>> >> the build scripts. RelWithDebInfo should generate the same code as
>>> >> Release, and after stripping debug information, the binaries
>>> should be
>>> >> identical.
>>> >>
>>> >> There are two problems I see:
>>> >>
>>> >>  - we check explicitly if the build type is Release, which then
>>> doesn't
>>> >> match
>>> >>  - we have a redundant -DDEBUG which is explicitly set — release
>>> builds
>>> >> have -DNDEBUG, which is set by CMake already, and this is what should
>>> >> switch debugging facilities like asserts.
>>> >>
>>> >> I've submitted a patch to get rid of -DDEBUG two years ago, I
>>> doubt it
>>> >> still applies. I can make a new one if it has a chance of being
>>> applied.
>>> >>
>>> >>Simon
>>> >>
>>> >> ___
>>> >> Mailing list: https://launchpad.net/~kicad-developers
>>> 
>>> >> Post to : kicad-developers@lists.launchpad.net
>>> 
>>> >> Unsubscribe : https://launchpad.net/~kicad-developers
>>> 
>>> >> More help   : https://help.launchpad.net/ListHelp
>>> >
>>> >
>>> >
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> 
>>> Post to : kicad-developers@lists.launchpad.net
>>> 
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> 
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> 

Re: [Kicad-developers] Windows Builds

[Simon Richter]

Hi,

On 25.07.2018 18:18, Wayne Stambaugh wrote:

> I guess we will have to wait until Nick returns from vacation to get
> this resolved.

I just pointed Jenkins at my fork, but that's bad style, basically.

   Simon



signature.asc
Description: OpenPGP digital signature
___
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] Windows Builds

[Mark Roszko]

* Simon's pull request.

https://github.com/KiCad/kicad-winbuilder/pull/74
On Wed, Jul 25, 2018 at 12:33 PM Wayne Stambaugh  wrote:
>
> I believe have github admin permissions at the org level.  Please post
> the link to Mark's pull request and I will see if I can merge it.
>
> On 7/25/2018 12:29 PM, Adam Wolf wrote:
> > Does anyone else have admin permissions at the org level?
> >
> > On Wed, Jul 25, 2018, 11:19 AM Wayne Stambaugh  > > wrote:
> >
> > On 7/25/2018 11:15 AM, Mark Roszko wrote:
> > > @Wayne, The hold up on Windows was that Nick went on vacation
> > > basically the day after posting the first 5.0 build. So bad timing.>
> > >
> > >> I've changed it to Release for the time being (but someone still
> > needs to accept my pull request in GitHub)
> > >
> > > Unforunately Nick is the only one with privs on the winbuilder repo on
> > > github unless someone else does from the organization level access
> > > list.
> >
> > I guess we will have to wait until Nick returns from vacation to get
> > this resolved.  Once he gets back, I'll ping him about having him assign
> > privileges to someone else as a backup so we don't get bit by this in
> > the future.
> >
> > >
> > >> RelWithDebInfo should generate the same code as Release, and
> > after stripping debug information, the binaries should be identical.
> > >
> > > You know, looking at your commit, its interesting. Because PKGBUILD
> > > which you change from RelWithDebInfo to Release explicitly was always
> > > fine, the nightlies never gave that assert (I checked).
> > > But PKGBUILD-STABLE had no config specifiedso perhaps it drifted
> > > to DEBUG somehow?
> > >
> > > On Wed, Jul 25, 2018 at 9:09 AM Simon Richter
> > mailto:simon.rich...@hogyros.de>> wrote:
> > >>
> > >> Hi,
> > >>
> > >> On 25.07.2018 14:16, Wayne Stambaugh wrote:
> > >>
> > >>> We should have created a release build of the stable version.
> > I'm fine
> > >>> with nightly builds having debugging information.  Stable releases
> > >>> should not have debug info.
> > >>
> > >> These are built as RelWithDebInfo, and the debug information is
> > stripped
> > >> out during installation, or rather should be (we're trying to
> > keep the
> > >> MSYS build as close to a standard Linux/BSD build as possible,
> > and they
> > >> usually archive the debug information separately before
> > stripping, which
> > >> is why this mode is useful at all).
> > >>
> > >> I've changed it to Release for the time being (but someone still
> > needs
> > >> to accept my pull request in GitHub), but this is indicative of a
> > bug in
> > >> the build scripts. RelWithDebInfo should generate the same code as
> > >> Release, and after stripping debug information, the binaries
> > should be
> > >> identical.
> > >>
> > >> There are two problems I see:
> > >>
> > >>  - we check explicitly if the build type is Release, which then
> > doesn't
> > >> match
> > >>  - we have a redundant -DDEBUG which is explicitly set — release
> > builds
> > >> have -DNDEBUG, which is set by CMake already, and this is what should
> > >> switch debugging facilities like asserts.
> > >>
> > >> I've submitted a patch to get rid of -DDEBUG two years ago, I
> > doubt it
> > >> still applies. I can make a new one if it has a chance of being
> > applied.
> > >>
> > >>Simon
> > >>
> > >> ___
> > >> Mailing list: https://launchpad.net/~kicad-developers
> > 
> > >> Post to : kicad-developers@lists.launchpad.net
> > 
> > >> Unsubscribe : https://launchpad.net/~kicad-developers
> > 
> > >> More help   : https://help.launchpad.net/ListHelp
> > >
> > >
> > >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > 
> > Post to : kicad-developers@lists.launchpad.net
> > 
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > 
> > More help   : https://help.launchpad.net/ListHelp
> >
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp



-- 
Mark

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

Re: [Kicad-developers] Windows Builds

[Wayne Stambaugh]

I believe have github admin permissions at the org level.  Please post
the link to Mark's pull request and I will see if I can merge it.

On 7/25/2018 12:29 PM, Adam Wolf wrote:
> Does anyone else have admin permissions at the org level?
> 
> On Wed, Jul 25, 2018, 11:19 AM Wayne Stambaugh  > wrote:
> 
> On 7/25/2018 11:15 AM, Mark Roszko wrote:
> > @Wayne, The hold up on Windows was that Nick went on vacation
> > basically the day after posting the first 5.0 build. So bad timing.>
> >
> >> I've changed it to Release for the time being (but someone still
> needs to accept my pull request in GitHub)
> >
> > Unforunately Nick is the only one with privs on the winbuilder repo on
> > github unless someone else does from the organization level access
> > list.
> 
> I guess we will have to wait until Nick returns from vacation to get
> this resolved.  Once he gets back, I'll ping him about having him assign
> privileges to someone else as a backup so we don't get bit by this in
> the future.
> 
> >
> >> RelWithDebInfo should generate the same code as Release, and
> after stripping debug information, the binaries should be identical.
> >
> > You know, looking at your commit, its interesting. Because PKGBUILD
> > which you change from RelWithDebInfo to Release explicitly was always
> > fine, the nightlies never gave that assert (I checked).
> > But PKGBUILD-STABLE had no config specifiedso perhaps it drifted
> > to DEBUG somehow?
> >
> > On Wed, Jul 25, 2018 at 9:09 AM Simon Richter
> mailto:simon.rich...@hogyros.de>> wrote:
> >>
> >> Hi,
> >>
> >> On 25.07.2018 14:16, Wayne Stambaugh wrote:
> >>
> >>> We should have created a release build of the stable version. 
> I'm fine
> >>> with nightly builds having debugging information.  Stable releases
> >>> should not have debug info.
> >>
> >> These are built as RelWithDebInfo, and the debug information is
> stripped
> >> out during installation, or rather should be (we're trying to
> keep the
> >> MSYS build as close to a standard Linux/BSD build as possible,
> and they
> >> usually archive the debug information separately before
> stripping, which
> >> is why this mode is useful at all).
> >>
> >> I've changed it to Release for the time being (but someone still
> needs
> >> to accept my pull request in GitHub), but this is indicative of a
> bug in
> >> the build scripts. RelWithDebInfo should generate the same code as
> >> Release, and after stripping debug information, the binaries
> should be
> >> identical.
> >>
> >> There are two problems I see:
> >>
> >>  - we check explicitly if the build type is Release, which then
> doesn't
> >> match
> >>  - we have a redundant -DDEBUG which is explicitly set — release
> builds
> >> have -DNDEBUG, which is set by CMake already, and this is what should
> >> switch debugging facilities like asserts.
> >>
> >> I've submitted a patch to get rid of -DDEBUG two years ago, I
> doubt it
> >> still applies. I can make a new one if it has a chance of being
> applied.
> >>
> >>    Simon
> >>
> >> ___
> >> Mailing list: https://launchpad.net/~kicad-developers
> 
> >> Post to     : kicad-developers@lists.launchpad.net
> 
> >> Unsubscribe : https://launchpad.net/~kicad-developers
> 
> >> More help   : https://help.launchpad.net/ListHelp
> >
> >
> >
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> 
> Post to     : kicad-developers@lists.launchpad.net
> 
> Unsubscribe : https://launchpad.net/~kicad-developers
> 
> More help   : https://help.launchpad.net/ListHelp
> 

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

Re: [Kicad-developers] Windows Builds

[Adam Wolf]

Does anyone else have admin permissions at the org level?

On Wed, Jul 25, 2018, 11:19 AM Wayne Stambaugh  wrote:

> On 7/25/2018 11:15 AM, Mark Roszko wrote:
> > @Wayne, The hold up on Windows was that Nick went on vacation
> > basically the day after posting the first 5.0 build. So bad timing.>
> >
> >> I've changed it to Release for the time being (but someone still needs
> to accept my pull request in GitHub)
> >
> > Unforunately Nick is the only one with privs on the winbuilder repo on
> > github unless someone else does from the organization level access
> > list.
>
> I guess we will have to wait until Nick returns from vacation to get
> this resolved.  Once he gets back, I'll ping him about having him assign
> privileges to someone else as a backup so we don't get bit by this in
> the future.
>
> >
> >> RelWithDebInfo should generate the same code as Release, and after
> stripping debug information, the binaries should be identical.
> >
> > You know, looking at your commit, its interesting. Because PKGBUILD
> > which you change from RelWithDebInfo to Release explicitly was always
> > fine, the nightlies never gave that assert (I checked).
> > But PKGBUILD-STABLE had no config specifiedso perhaps it drifted
> > to DEBUG somehow?
> >
> > On Wed, Jul 25, 2018 at 9:09 AM Simon Richter 
> wrote:
> >>
> >> Hi,
> >>
> >> On 25.07.2018 14:16, Wayne Stambaugh wrote:
> >>
> >>> We should have created a release build of the stable version.  I'm fine
> >>> with nightly builds having debugging information.  Stable releases
> >>> should not have debug info.
> >>
> >> These are built as RelWithDebInfo, and the debug information is stripped
> >> out during installation, or rather should be (we're trying to keep the
> >> MSYS build as close to a standard Linux/BSD build as possible, and they
> >> usually archive the debug information separately before stripping, which
> >> is why this mode is useful at all).
> >>
> >> I've changed it to Release for the time being (but someone still needs
> >> to accept my pull request in GitHub), but this is indicative of a bug in
> >> the build scripts. RelWithDebInfo should generate the same code as
> >> Release, and after stripping debug information, the binaries should be
> >> identical.
> >>
> >> There are two problems I see:
> >>
> >>  - we check explicitly if the build type is Release, which then doesn't
> >> match
> >>  - we have a redundant -DDEBUG which is explicitly set — release builds
> >> have -DNDEBUG, which is set by CMake already, and this is what should
> >> switch debugging facilities like asserts.
> >>
> >> I've submitted a patch to get rid of -DDEBUG two years ago, I doubt it
> >> still applies. I can make a new one if it has a chance of being applied.
> >>
> >>Simon
> >>
> >> ___
> >> Mailing list: https://launchpad.net/~kicad-developers
> >> Post to : kicad-developers@lists.launchpad.net
> >> Unsubscribe : https://launchpad.net/~kicad-developers
> >> More help   : https://help.launchpad.net/ListHelp
> >
> >
> >
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Windows Builds

[Wayne Stambaugh]

On 7/25/2018 11:15 AM, Mark Roszko wrote:
> @Wayne, The hold up on Windows was that Nick went on vacation
> basically the day after posting the first 5.0 build. So bad timing.>
> 
>> I've changed it to Release for the time being (but someone still needs to 
>> accept my pull request in GitHub)
> 
> Unforunately Nick is the only one with privs on the winbuilder repo on
> github unless someone else does from the organization level access
> list.

I guess we will have to wait until Nick returns from vacation to get
this resolved.  Once he gets back, I'll ping him about having him assign
privileges to someone else as a backup so we don't get bit by this in
the future.

> 
>> RelWithDebInfo should generate the same code as Release, and after stripping 
>> debug information, the binaries should be identical.
> 
> You know, looking at your commit, its interesting. Because PKGBUILD
> which you change from RelWithDebInfo to Release explicitly was always
> fine, the nightlies never gave that assert (I checked).
> But PKGBUILD-STABLE had no config specifiedso perhaps it drifted
> to DEBUG somehow?
> 
> On Wed, Jul 25, 2018 at 9:09 AM Simon Richter  
> wrote:
>>
>> Hi,
>>
>> On 25.07.2018 14:16, Wayne Stambaugh wrote:
>>
>>> We should have created a release build of the stable version.  I'm fine
>>> with nightly builds having debugging information.  Stable releases
>>> should not have debug info.
>>
>> These are built as RelWithDebInfo, and the debug information is stripped
>> out during installation, or rather should be (we're trying to keep the
>> MSYS build as close to a standard Linux/BSD build as possible, and they
>> usually archive the debug information separately before stripping, which
>> is why this mode is useful at all).
>>
>> I've changed it to Release for the time being (but someone still needs
>> to accept my pull request in GitHub), but this is indicative of a bug in
>> the build scripts. RelWithDebInfo should generate the same code as
>> Release, and after stripping debug information, the binaries should be
>> identical.
>>
>> There are two problems I see:
>>
>>  - we check explicitly if the build type is Release, which then doesn't
>> match
>>  - we have a redundant -DDEBUG which is explicitly set — release builds
>> have -DNDEBUG, which is set by CMake already, and this is what should
>> switch debugging facilities like asserts.
>>
>> I've submitted a patch to get rid of -DDEBUG two years ago, I doubt it
>> still applies. I can make a new one if it has a chance of being applied.
>>
>>Simon
>>
>> ___
>> 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] Windows Builds

[Mark Roszko]

@Wayne, The hold up on Windows was that Nick went on vacation
basically the day after posting the first 5.0 build. So bad timing.


>I've changed it to Release for the time being (but someone still needs to 
>accept my pull request in GitHub)

Unforunately Nick is the only one with privs on the winbuilder repo on
github unless someone else does from the organization level access
list.

>RelWithDebInfo should generate the same code as Release, and after stripping 
>debug information, the binaries should be identical.

You know, looking at your commit, its interesting. Because PKGBUILD
which you change from RelWithDebInfo to Release explicitly was always
fine, the nightlies never gave that assert (I checked).
But PKGBUILD-STABLE had no config specifiedso perhaps it drifted
to DEBUG somehow?

On Wed, Jul 25, 2018 at 9:09 AM Simon Richter  wrote:
>
> Hi,
>
> On 25.07.2018 14:16, Wayne Stambaugh wrote:
>
> > We should have created a release build of the stable version.  I'm fine
> > with nightly builds having debugging information.  Stable releases
> > should not have debug info.
>
> These are built as RelWithDebInfo, and the debug information is stripped
> out during installation, or rather should be (we're trying to keep the
> MSYS build as close to a standard Linux/BSD build as possible, and they
> usually archive the debug information separately before stripping, which
> is why this mode is useful at all).
>
> I've changed it to Release for the time being (but someone still needs
> to accept my pull request in GitHub), but this is indicative of a bug in
> the build scripts. RelWithDebInfo should generate the same code as
> Release, and after stripping debug information, the binaries should be
> identical.
>
> There are two problems I see:
>
>  - we check explicitly if the build type is Release, which then doesn't
> match
>  - we have a redundant -DDEBUG which is explicitly set — release builds
> have -DNDEBUG, which is set by CMake already, and this is what should
> switch debugging facilities like asserts.
>
> I've submitted a patch to get rid of -DDEBUG two years ago, I doubt it
> still applies. I can make a new one if it has a chance of being applied.
>
>Simon
>
> ___
> 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] Windows Builds

[Simon Richter]

Hi,

On 25.07.2018 14:16, Wayne Stambaugh wrote:

> We should have created a release build of the stable version.  I'm fine
> with nightly builds having debugging information.  Stable releases
> should not have debug info.

These are built as RelWithDebInfo, and the debug information is stripped
out during installation, or rather should be (we're trying to keep the
MSYS build as close to a standard Linux/BSD build as possible, and they
usually archive the debug information separately before stripping, which
is why this mode is useful at all).

I've changed it to Release for the time being (but someone still needs
to accept my pull request in GitHub), but this is indicative of a bug in
the build scripts. RelWithDebInfo should generate the same code as
Release, and after stripping debug information, the binaries should be
identical.

There are two problems I see:

 - we check explicitly if the build type is Release, which then doesn't
match
 - we have a redundant -DDEBUG which is explicitly set — release builds
have -DNDEBUG, which is set by CMake already, and this is what should
switch debugging facilities like asserts.

I've submitted a patch to get rid of -DDEBUG two years ago, I doubt it
still applies. I can make a new one if it has a chance of being applied.

   Simon



signature.asc
Description: OpenPGP digital signature
___
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] Windows Builds

[Adam Wolf]

(Marek and I did pull the macOS builds, and I regenerated it as
Release and got everything all fixed up on the website.)
On Wed, Jul 25, 2018 at 7:31 AM Wayne Stambaugh  wrote:
>
> We should have created a release build of the stable version.  I'm fine
> with nightly builds having debugging information.  Stable releases
> should not have debug info.
>
> On 7/25/2018 8:10 AM, Jakub Kozdon wrote:
> > There are probably in http://downloads.kicad-pcb.org/windows/testing/
> > instead of stable.
> >
> > Dne 25.7.2018 v 13:51 Wayne Stambaugh napsal(a):
> >> I thought we created a new windows release build to prevent the
> >> assertions.  Did that not happen?
> >>
> >> On 7/25/2018 7:01 AM, Andrew Lutsenko wrote:
> >>> Were the windows builds ever fixed?
> >>> I downloaded 5.0 today and get a wxWidgets assert simply from clicking
> >>> on tools menu in Pcbnew.
> >>> kicadassert.png
> >>>
> >>>
> >>> On Mon, Jul 23, 2018 at 6:34 AM Wayne Stambaugh  >>> > wrote:
> >>>
> >>>  I'm fine with creating a packaging document.  We could add it to
> >>> the
> >>>  developers documentation or it could also be an external
> >>> document with a
> >>>  link in the compiling doc.
> >>>
> >>>  Wayne
> >>>
> >>>  On 7/23/2018 8:40 AM, Adam Wolf wrote:
> >>>  > Agreed, Wayne. The macOS 5.0.0-1 build is uploading right now.
> >>> It is a
> >>>  > Release build.
> >>>  >
> >>>  > I have a small set of packaging tests I perform on releases
> >>> before
> >>>  > uploading them.  It *really* saved my bacon with the macOS
> >>> release,
> >>>  > and it sounds like it would have been helpful with the Windows
> >>>  > release.  What do we think about moving them, along with other
> >>>  > packager-oriented updates and directives, into its own
> >>> documentation
> >>>  > section?  This should help build package unity, and also help
> >>> clean up
> >>>  > the the 5.1 and later announcements.  (They won't need to have
> >>>  > packager-oriented updates, since that's all in a single
> >>> section in the
> >>>  > docs).  If it seems OK but no one else is excited about it, I
> >>>  > volunteer to coordinate this.  It goes along with another
> >>> V6-timeline
> >>>  > KiCad project of mine.
> >>>  >
> >>>  > Adam
> >>>  > On Mon, Jul 23, 2018 at 6:52 AM Wayne Stambaugh
> >>>  mailto:stambau...@gmail.com>> wrote:
> >>>  >>
> >>>  >> I would prefer that we create release builds
> >>>  (CMAKE_BUILD_TYPE=Release)
> >>>  >> for the stable releases.  Debug builds are fine for nightly
> >>> builds.
> >>>  >>
> >>>  >> On 7/23/2018 12:07 AM, Mark Roszko wrote:
> >>>  >>> Done.
> >>>  >>>
> >>>  >>> Wouldn't be bad if the wxAsserts were squashed :X
> >>>  >>> But then again some of them come from wx internally in annoying
> >>>  ways.
> >>>  >>> On Mon, Jul 23, 2018 at 12:03 AM Adam Wolf
> >>>  >>>  >>>  > wrote:
> >>>  
> >>>   Ok, this sounds bad.
> >>>  
> >>>   Can someone (Marek?) pull the macOS build and revert the macOS
> >>>  download page, please?  I'm running extremely low on sleep from the
> >>>  last two nights of KiCad hacking and I am literally in bed already.
> >>>  
> >>>   I will regenerate the macOS build with Release instead in
> >>>  approximately 8 hours.
> >>>  
> >>>   Adam
> >>>  
> >>>   On Sun, Jul 22, 2018, 10:48 PM Mark Roszko
> >>>  mailto:mark.ros...@gmail.com>> wrote:
> >>>  >
> >>>  > Welp, I poked Nick. It looks like the stable-debug build got
> >>>  packaged
> >>>  > instead of the stable build config (I can reproduce the
> >>> asserts).
> >>>  > Though the executables are suspiciously not huge like they
> >>>  should be.
> >>>  > On Sun, Jul 22, 2018 at 11:30 PM Seth Hillbrand
> >>>  mailto:s...@hillbrand.org>> wrote:
> >>>  >>
> >>>  >> No, It's because asserts are being triggered.  These are
> >>>  disabled (normally) in Release builds.
> >>>  >>
> >>>  >> -S
> >>>  >>
> >>>  >> Am So., 22. Juli 2018 um 20:28 Uhr schrieb Mark Roszko
> >>>  mailto:mark.ros...@gmail.com>>:
> >>>  >>>
> >>>  >>> Is it because the installer exe is huge?
> >>>  >>>
> >>>  >>> That's because the footprint libraries are now part of the
> >>>  installers
> >>>  >>> and they are absolutely massive. (4GB uncompressed)
> >>>  >>>
> >>>  >>> the installed files look fine to me though? The kiface
> >>> files
> >>>  would be
> >>>  >>> hundreds of megs themselves if they had debug symbols but
> >>>  they are at
> >>>  >>> "normal" levels.
> >>>  >>> On Sun, Jul 22, 2018 at 11:16 PM Seth Hillbrand
> >>>  mailto:s...@hillbrand.org>> wrote:
> 

Re: [Kicad-developers] Windows Builds

[Wayne Stambaugh]

We should have created a release build of the stable version.  I'm fine
with nightly builds having debugging information.  Stable releases
should not have debug info.

On 7/25/2018 8:10 AM, Jakub Kozdon wrote:
> There are probably in http://downloads.kicad-pcb.org/windows/testing/
> instead of stable.
> 
> Dne 25.7.2018 v 13:51 Wayne Stambaugh napsal(a):
>> I thought we created a new windows release build to prevent the
>> assertions.  Did that not happen?
>>
>> On 7/25/2018 7:01 AM, Andrew Lutsenko wrote:
>>> Were the windows builds ever fixed?
>>> I downloaded 5.0 today and get a wxWidgets assert simply from clicking
>>> on tools menu in Pcbnew.
>>> kicadassert.png
>>> ​
>>>
>>> On Mon, Jul 23, 2018 at 6:34 AM Wayne Stambaugh >> > wrote:
>>>
>>>  I'm fine with creating a packaging document.  We could add it to
>>> the
>>>  developers documentation or it could also be an external
>>> document with a
>>>  link in the compiling doc.
>>>
>>>  Wayne
>>>
>>>  On 7/23/2018 8:40 AM, Adam Wolf wrote:
>>>  > Agreed, Wayne. The macOS 5.0.0-1 build is uploading right now.
>>> It is a
>>>  > Release build.
>>>  >
>>>  > I have a small set of packaging tests I perform on releases
>>> before
>>>  > uploading them.  It *really* saved my bacon with the macOS
>>> release,
>>>  > and it sounds like it would have been helpful with the Windows
>>>  > release.  What do we think about moving them, along with other
>>>  > packager-oriented updates and directives, into its own
>>> documentation
>>>  > section?  This should help build package unity, and also help
>>> clean up
>>>  > the the 5.1 and later announcements.  (They won't need to have
>>>  > packager-oriented updates, since that's all in a single
>>> section in the
>>>  > docs).  If it seems OK but no one else is excited about it, I
>>>  > volunteer to coordinate this.  It goes along with another
>>> V6-timeline
>>>  > KiCad project of mine.
>>>  >
>>>  > Adam
>>>  > On Mon, Jul 23, 2018 at 6:52 AM Wayne Stambaugh
>>>  mailto:stambau...@gmail.com>> wrote:
>>>  >>
>>>  >> I would prefer that we create release builds
>>>  (CMAKE_BUILD_TYPE=Release)
>>>  >> for the stable releases.  Debug builds are fine for nightly
>>> builds.
>>>  >>
>>>  >> On 7/23/2018 12:07 AM, Mark Roszko wrote:
>>>  >>> Done.
>>>  >>>
>>>  >>> Wouldn't be bad if the wxAsserts were squashed :X
>>>  >>> But then again some of them come from wx internally in annoying
>>>  ways.
>>>  >>> On Mon, Jul 23, 2018 at 12:03 AM Adam Wolf
>>>  >>> >>  > wrote:
>>>  
>>>   Ok, this sounds bad.
>>>  
>>>   Can someone (Marek?) pull the macOS build and revert the macOS
>>>  download page, please?  I'm running extremely low on sleep from the
>>>  last two nights of KiCad hacking and I am literally in bed already.
>>>  
>>>   I will regenerate the macOS build with Release instead in
>>>  approximately 8 hours.
>>>  
>>>   Adam
>>>  
>>>   On Sun, Jul 22, 2018, 10:48 PM Mark Roszko
>>>  mailto:mark.ros...@gmail.com>> wrote:
>>>  >
>>>  > Welp, I poked Nick. It looks like the stable-debug build got
>>>  packaged
>>>  > instead of the stable build config (I can reproduce the
>>> asserts).
>>>  > Though the executables are suspiciously not huge like they
>>>  should be.
>>>  > On Sun, Jul 22, 2018 at 11:30 PM Seth Hillbrand
>>>  mailto:s...@hillbrand.org>> wrote:
>>>  >>
>>>  >> No, It's because asserts are being triggered.  These are
>>>  disabled (normally) in Release builds.
>>>  >>
>>>  >> -S
>>>  >>
>>>  >> Am So., 22. Juli 2018 um 20:28 Uhr schrieb Mark Roszko
>>>  mailto:mark.ros...@gmail.com>>:
>>>  >>>
>>>  >>> Is it because the installer exe is huge?
>>>  >>>
>>>  >>> That's because the footprint libraries are now part of the
>>>  installers
>>>  >>> and they are absolutely massive. (4GB uncompressed)
>>>  >>>
>>>  >>> the installed files look fine to me though? The kiface
>>> files
>>>  would be
>>>  >>> hundreds of megs themselves if they had debug symbols but
>>>  they are at
>>>  >>> "normal" levels.
>>>  >>> On Sun, Jul 22, 2018 at 11:16 PM Seth Hillbrand
>>>  mailto:s...@hillbrand.org>> wrote:
>>>  
>>>   Hi Devs-
>>>  
>>>   I'm seeing some reports (lp:1783037) that indicate the
>>>  Windows build may be compiled CMAKE_BUILD_TYPE=RelWithDebInfo
>>>  instead of Release.
>>>  
>>>   Can anyone confirm this?  Is there a reason to do this for
>>>  Windows?
>>>  
>>>   -Seth
>>>  
>>>  

Re: [Kicad-developers] Windows Builds

[Jakub Kozdon]

There are probably in http://downloads.kicad-pcb.org/windows/testing/ 
instead of stable.


Dne 25.7.2018 v 13:51 Wayne Stambaugh napsal(a):

I thought we created a new windows release build to prevent the
assertions.  Did that not happen?

On 7/25/2018 7:01 AM, Andrew Lutsenko wrote:

Were the windows builds ever fixed?
I downloaded 5.0 today and get a wxWidgets assert simply from clicking
on tools menu in Pcbnew.
kicadassert.png
​

On Mon, Jul 23, 2018 at 6:34 AM Wayne Stambaugh mailto:stambau...@gmail.com>> wrote:

 I'm fine with creating a packaging document.  We could add it to the
 developers documentation or it could also be an external document with a
 link in the compiling doc.

 Wayne

 On 7/23/2018 8:40 AM, Adam Wolf wrote:
 > Agreed, Wayne. The macOS 5.0.0-1 build is uploading right now. It is a
 > Release build.
 >
 > I have a small set of packaging tests I perform on releases before
 > uploading them.  It *really* saved my bacon with the macOS release,
 > and it sounds like it would have been helpful with the Windows
 > release.  What do we think about moving them, along with other
 > packager-oriented updates and directives, into its own documentation
 > section?  This should help build package unity, and also help clean up
 > the the 5.1 and later announcements.  (They won't need to have
 > packager-oriented updates, since that's all in a single section in the
 > docs).  If it seems OK but no one else is excited about it, I
 > volunteer to coordinate this.  It goes along with another V6-timeline
 > KiCad project of mine.
 >
 > Adam
 > On Mon, Jul 23, 2018 at 6:52 AM Wayne Stambaugh
 mailto:stambau...@gmail.com>> wrote:
 >>
 >> I would prefer that we create release builds
 (CMAKE_BUILD_TYPE=Release)
 >> for the stable releases.  Debug builds are fine for nightly builds.
 >>
 >> On 7/23/2018 12:07 AM, Mark Roszko wrote:
 >>> Done.
 >>>
 >>> Wouldn't be bad if the wxAsserts were squashed :X
 >>> But then again some of them come from wx internally in annoying
 ways.
 >>> On Mon, Jul 23, 2018 at 12:03 AM Adam Wolf
 >>> mailto:adamw...@feelslikeburning.com>> wrote:
 
  Ok, this sounds bad.
 
  Can someone (Marek?) pull the macOS build and revert the macOS
 download page, please?  I'm running extremely low on sleep from the
 last two nights of KiCad hacking and I am literally in bed already.
 
  I will regenerate the macOS build with Release instead in
 approximately 8 hours.
 
  Adam
 
  On Sun, Jul 22, 2018, 10:48 PM Mark Roszko
 mailto:mark.ros...@gmail.com>> wrote:
 >
 > Welp, I poked Nick. It looks like the stable-debug build got
 packaged
 > instead of the stable build config (I can reproduce the asserts).
 > Though the executables are suspiciously not huge like they
 should be.
 > On Sun, Jul 22, 2018 at 11:30 PM Seth Hillbrand
 mailto:s...@hillbrand.org>> wrote:
 >>
 >> No, It's because asserts are being triggered.  These are
 disabled (normally) in Release builds.
 >>
 >> -S
 >>
 >> Am So., 22. Juli 2018 um 20:28 Uhr schrieb Mark Roszko
 mailto:mark.ros...@gmail.com>>:
 >>>
 >>> Is it because the installer exe is huge?
 >>>
 >>> That's because the footprint libraries are now part of the
 installers
 >>> and they are absolutely massive. (4GB uncompressed)
 >>>
 >>> the installed files look fine to me though? The kiface files
 would be
 >>> hundreds of megs themselves if they had debug symbols but
 they are at
 >>> "normal" levels.
 >>> On Sun, Jul 22, 2018 at 11:16 PM Seth Hillbrand
 mailto:s...@hillbrand.org>> wrote:
 
  Hi Devs-
 
  I'm seeing some reports (lp:1783037) that indicate the
 Windows build may be compiled CMAKE_BUILD_TYPE=RelWithDebInfo
 instead of Release.
 
  Can anyone confirm this?  Is there a reason to do this for
 Windows?
 
  -Seth
 
  ___
  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
 >
 > ___
 > 

Re: [Kicad-developers] Windows Builds

[Wayne Stambaugh]

I thought we created a new windows release build to prevent the
assertions.  Did that not happen?

On 7/25/2018 7:01 AM, Andrew Lutsenko wrote:
> Were the windows builds ever fixed? 
> I downloaded 5.0 today and get a wxWidgets assert simply from clicking
> on tools menu in Pcbnew.
> kicadassert.png
> ​
> 
> On Mon, Jul 23, 2018 at 6:34 AM Wayne Stambaugh  > wrote:
> 
> I'm fine with creating a packaging document.  We could add it to the
> developers documentation or it could also be an external document with a
> link in the compiling doc.
> 
> Wayne
> 
> On 7/23/2018 8:40 AM, Adam Wolf wrote:
> > Agreed, Wayne. The macOS 5.0.0-1 build is uploading right now. It is a
> > Release build.
> >
> > I have a small set of packaging tests I perform on releases before
> > uploading them.  It *really* saved my bacon with the macOS release,
> > and it sounds like it would have been helpful with the Windows
> > release.  What do we think about moving them, along with other
> > packager-oriented updates and directives, into its own documentation
> > section?  This should help build package unity, and also help clean up
> > the the 5.1 and later announcements.  (They won't need to have
> > packager-oriented updates, since that's all in a single section in the
> > docs).  If it seems OK but no one else is excited about it, I
> > volunteer to coordinate this.  It goes along with another V6-timeline
> > KiCad project of mine.
> >
> > Adam
> > On Mon, Jul 23, 2018 at 6:52 AM Wayne Stambaugh
> mailto:stambau...@gmail.com>> wrote:
> >>
> >> I would prefer that we create release builds
> (CMAKE_BUILD_TYPE=Release)
> >> for the stable releases.  Debug builds are fine for nightly builds.
> >>
> >> On 7/23/2018 12:07 AM, Mark Roszko wrote:
> >>> Done.
> >>>
> >>> Wouldn't be bad if the wxAsserts were squashed :X
> >>> But then again some of them come from wx internally in annoying
> ways.
> >>> On Mon, Jul 23, 2018 at 12:03 AM Adam Wolf
> >>>  > wrote:
> 
>  Ok, this sounds bad.
> 
>  Can someone (Marek?) pull the macOS build and revert the macOS
> download page, please?  I'm running extremely low on sleep from the
> last two nights of KiCad hacking and I am literally in bed already.
> 
>  I will regenerate the macOS build with Release instead in
> approximately 8 hours.
> 
>  Adam
> 
>  On Sun, Jul 22, 2018, 10:48 PM Mark Roszko
> mailto:mark.ros...@gmail.com>> wrote:
> >
> > Welp, I poked Nick. It looks like the stable-debug build got
> packaged
> > instead of the stable build config (I can reproduce the asserts).
> > Though the executables are suspiciously not huge like they
> should be.
> > On Sun, Jul 22, 2018 at 11:30 PM Seth Hillbrand
> mailto:s...@hillbrand.org>> wrote:
> >>
> >> No, It's because asserts are being triggered.  These are
> disabled (normally) in Release builds.
> >>
> >> -S
> >>
> >> Am So., 22. Juli 2018 um 20:28 Uhr schrieb Mark Roszko
> mailto:mark.ros...@gmail.com>>:
> >>>
> >>> Is it because the installer exe is huge?
> >>>
> >>> That's because the footprint libraries are now part of the
> installers
> >>> and they are absolutely massive. (4GB uncompressed)
> >>>
> >>> the installed files look fine to me though? The kiface files
> would be
> >>> hundreds of megs themselves if they had debug symbols but
> they are at
> >>> "normal" levels.
> >>> On Sun, Jul 22, 2018 at 11:16 PM Seth Hillbrand
> mailto:s...@hillbrand.org>> wrote:
> 
>  Hi Devs-
> 
>  I'm seeing some reports (lp:1783037) that indicate the
> Windows build may be compiled CMAKE_BUILD_TYPE=RelWithDebInfo
> instead of Release.
> 
>  Can anyone confirm this?  Is there a reason to do this for
> Windows?
> 
>  -Seth
> 
>  ___
>  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
> >
> > ___
> > 

Re: [Kicad-developers] Windows Builds

[Andrew Lutsenko]

Were the windows builds ever fixed?
I downloaded 5.0 today and get a wxWidgets assert simply from clicking on
tools menu in Pcbnew.
[image: kicadassert.png]
​

On Mon, Jul 23, 2018 at 6:34 AM Wayne Stambaugh 
wrote:

> I'm fine with creating a packaging document.  We could add it to the
> developers documentation or it could also be an external document with a
> link in the compiling doc.
>
> Wayne
>
> On 7/23/2018 8:40 AM, Adam Wolf wrote:
> > Agreed, Wayne. The macOS 5.0.0-1 build is uploading right now. It is a
> > Release build.
> >
> > I have a small set of packaging tests I perform on releases before
> > uploading them.  It *really* saved my bacon with the macOS release,
> > and it sounds like it would have been helpful with the Windows
> > release.  What do we think about moving them, along with other
> > packager-oriented updates and directives, into its own documentation
> > section?  This should help build package unity, and also help clean up
> > the the 5.1 and later announcements.  (They won't need to have
> > packager-oriented updates, since that's all in a single section in the
> > docs).  If it seems OK but no one else is excited about it, I
> > volunteer to coordinate this.  It goes along with another V6-timeline
> > KiCad project of mine.
> >
> > Adam
> > On Mon, Jul 23, 2018 at 6:52 AM Wayne Stambaugh 
> wrote:
> >>
> >> I would prefer that we create release builds (CMAKE_BUILD_TYPE=Release)
> >> for the stable releases.  Debug builds are fine for nightly builds.
> >>
> >> On 7/23/2018 12:07 AM, Mark Roszko wrote:
> >>> Done.
> >>>
> >>> Wouldn't be bad if the wxAsserts were squashed :X
> >>> But then again some of them come from wx internally in annoying ways.
> >>> On Mon, Jul 23, 2018 at 12:03 AM Adam Wolf
> >>>  wrote:
> 
>  Ok, this sounds bad.
> 
>  Can someone (Marek?) pull the macOS build and revert the macOS
> download page, please?  I'm running extremely low on sleep from the last
> two nights of KiCad hacking and I am literally in bed already.
> 
>  I will regenerate the macOS build with Release instead in
> approximately 8 hours.
> 
>  Adam
> 
>  On Sun, Jul 22, 2018, 10:48 PM Mark Roszko 
> wrote:
> >
> > Welp, I poked Nick. It looks like the stable-debug build got packaged
> > instead of the stable build config (I can reproduce the asserts).
> > Though the executables are suspiciously not huge like they should be.
> > On Sun, Jul 22, 2018 at 11:30 PM Seth Hillbrand 
> wrote:
> >>
> >> No, It's because asserts are being triggered.  These are disabled
> (normally) in Release builds.
> >>
> >> -S
> >>
> >> Am So., 22. Juli 2018 um 20:28 Uhr schrieb Mark Roszko <
> mark.ros...@gmail.com>:
> >>>
> >>> Is it because the installer exe is huge?
> >>>
> >>> That's because the footprint libraries are now part of the
> installers
> >>> and they are absolutely massive. (4GB uncompressed)
> >>>
> >>> the installed files look fine to me though? The kiface files would
> be
> >>> hundreds of megs themselves if they had debug symbols but they are
> at
> >>> "normal" levels.
> >>> On Sun, Jul 22, 2018 at 11:16 PM Seth Hillbrand <
> s...@hillbrand.org> wrote:
> 
>  Hi Devs-
> 
>  I'm seeing some reports (lp:1783037) that indicate the Windows
> build may be compiled CMAKE_BUILD_TYPE=RelWithDebInfo instead of Release.
> 
>  Can anyone confirm this?  Is there a reason to do this for
> Windows?
> 
>  -Seth
> 
>  ___
>  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
>
> ___
> 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 : 

Re: [Kicad-developers] Windows Builds

[Wayne Stambaugh]

I'm fine with creating a packaging document.  We could add it to the
developers documentation or it could also be an external document with a
link in the compiling doc.

Wayne

On 7/23/2018 8:40 AM, Adam Wolf wrote:
> Agreed, Wayne. The macOS 5.0.0-1 build is uploading right now. It is a
> Release build.
> 
> I have a small set of packaging tests I perform on releases before
> uploading them.  It *really* saved my bacon with the macOS release,
> and it sounds like it would have been helpful with the Windows
> release.  What do we think about moving them, along with other
> packager-oriented updates and directives, into its own documentation
> section?  This should help build package unity, and also help clean up
> the the 5.1 and later announcements.  (They won't need to have
> packager-oriented updates, since that's all in a single section in the
> docs).  If it seems OK but no one else is excited about it, I
> volunteer to coordinate this.  It goes along with another V6-timeline
> KiCad project of mine.
> 
> Adam
> On Mon, Jul 23, 2018 at 6:52 AM Wayne Stambaugh  wrote:
>>
>> I would prefer that we create release builds (CMAKE_BUILD_TYPE=Release)
>> for the stable releases.  Debug builds are fine for nightly builds.
>>
>> On 7/23/2018 12:07 AM, Mark Roszko wrote:
>>> Done.
>>>
>>> Wouldn't be bad if the wxAsserts were squashed :X
>>> But then again some of them come from wx internally in annoying ways.
>>> On Mon, Jul 23, 2018 at 12:03 AM Adam Wolf
>>>  wrote:

 Ok, this sounds bad.

 Can someone (Marek?) pull the macOS build and revert the macOS download 
 page, please?  I'm running extremely low on sleep from the last two nights 
 of KiCad hacking and I am literally in bed already.

 I will regenerate the macOS build with Release instead in approximately 8 
 hours.

 Adam

 On Sun, Jul 22, 2018, 10:48 PM Mark Roszko  wrote:
>
> Welp, I poked Nick. It looks like the stable-debug build got packaged
> instead of the stable build config (I can reproduce the asserts).
> Though the executables are suspiciously not huge like they should be.
> On Sun, Jul 22, 2018 at 11:30 PM Seth Hillbrand  
> wrote:
>>
>> No, It's because asserts are being triggered.  These are disabled 
>> (normally) in Release builds.
>>
>> -S
>>
>> Am So., 22. Juli 2018 um 20:28 Uhr schrieb Mark Roszko 
>> :
>>>
>>> Is it because the installer exe is huge?
>>>
>>> That's because the footprint libraries are now part of the installers
>>> and they are absolutely massive. (4GB uncompressed)
>>>
>>> the installed files look fine to me though? The kiface files would be
>>> hundreds of megs themselves if they had debug symbols but they are at
>>> "normal" levels.
>>> On Sun, Jul 22, 2018 at 11:16 PM Seth Hillbrand  
>>> wrote:

 Hi Devs-

 I'm seeing some reports (lp:1783037) that indicate the Windows build 
 may be compiled CMAKE_BUILD_TYPE=RelWithDebInfo instead of Release.

 Can anyone confirm this?  Is there a reason to do this for Windows?

 -Seth

 ___
 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

___
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] Windows Builds

[Wayne Stambaugh]

I would prefer that we create release builds (CMAKE_BUILD_TYPE=Release)
for the stable releases.  Debug builds are fine for nightly builds.

On 7/23/2018 12:07 AM, Mark Roszko wrote:
> Done.
> 
> Wouldn't be bad if the wxAsserts were squashed :X
> But then again some of them come from wx internally in annoying ways.
> On Mon, Jul 23, 2018 at 12:03 AM Adam Wolf
>  wrote:
>>
>> Ok, this sounds bad.
>>
>> Can someone (Marek?) pull the macOS build and revert the macOS download 
>> page, please?  I'm running extremely low on sleep from the last two nights 
>> of KiCad hacking and I am literally in bed already.
>>
>> I will regenerate the macOS build with Release instead in approximately 8 
>> hours.
>>
>> Adam
>>
>> On Sun, Jul 22, 2018, 10:48 PM Mark Roszko  wrote:
>>>
>>> Welp, I poked Nick. It looks like the stable-debug build got packaged
>>> instead of the stable build config (I can reproduce the asserts).
>>> Though the executables are suspiciously not huge like they should be.
>>> On Sun, Jul 22, 2018 at 11:30 PM Seth Hillbrand  wrote:

 No, It's because asserts are being triggered.  These are disabled 
 (normally) in Release builds.

 -S

 Am So., 22. Juli 2018 um 20:28 Uhr schrieb Mark Roszko 
 :
>
> Is it because the installer exe is huge?
>
> That's because the footprint libraries are now part of the installers
> and they are absolutely massive. (4GB uncompressed)
>
> the installed files look fine to me though? The kiface files would be
> hundreds of megs themselves if they had debug symbols but they are at
> "normal" levels.
> On Sun, Jul 22, 2018 at 11:16 PM Seth Hillbrand  
> wrote:
>>
>> Hi Devs-
>>
>> I'm seeing some reports (lp:1783037) that indicate the Windows build may 
>> be compiled CMAKE_BUILD_TYPE=RelWithDebInfo instead of Release.
>>
>> Can anyone confirm this?  Is there a reason to do this for Windows?
>>
>> -Seth
>>
>> ___
>> 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] Windows Builds

[Rene Pöschl]

On 23/07/18 05:27, Mark Roszko wrote:

Is it because the installer exe is huge?

That's because the footprint libraries are now part of the installers
and they are absolutely massive. (4GB uncompressed)


The whole repo (including git history) only has ~90MB
If any libs are to blame then it will be the 3d models. (6.5 GB 
including git history)


the installed files look fine to me though? The kiface files would be
hundreds of megs themselves if they had debug symbols but they are at
"normal" levels.
On Sun, Jul 22, 2018 at 11:16 PM Seth Hillbrand  wrote:

Hi Devs-

I'm seeing some reports (lp:1783037) that indicate the Windows build may be 
compiled CMAKE_BUILD_TYPE=RelWithDebInfo instead of Release.

Can anyone confirm this?  Is there a reason to do this for Windows?

-Seth

___
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] Windows Builds

[Mark Roszko]

Done.

Wouldn't be bad if the wxAsserts were squashed :X
But then again some of them come from wx internally in annoying ways.
On Mon, Jul 23, 2018 at 12:03 AM Adam Wolf
 wrote:
>
> Ok, this sounds bad.
>
> Can someone (Marek?) pull the macOS build and revert the macOS download page, 
> please?  I'm running extremely low on sleep from the last two nights of KiCad 
> hacking and I am literally in bed already.
>
> I will regenerate the macOS build with Release instead in approximately 8 
> hours.
>
> Adam
>
> On Sun, Jul 22, 2018, 10:48 PM Mark Roszko  wrote:
>>
>> Welp, I poked Nick. It looks like the stable-debug build got packaged
>> instead of the stable build config (I can reproduce the asserts).
>> Though the executables are suspiciously not huge like they should be.
>> On Sun, Jul 22, 2018 at 11:30 PM Seth Hillbrand  wrote:
>> >
>> > No, It's because asserts are being triggered.  These are disabled 
>> > (normally) in Release builds.
>> >
>> > -S
>> >
>> > Am So., 22. Juli 2018 um 20:28 Uhr schrieb Mark Roszko 
>> > :
>> >>
>> >> Is it because the installer exe is huge?
>> >>
>> >> That's because the footprint libraries are now part of the installers
>> >> and they are absolutely massive. (4GB uncompressed)
>> >>
>> >> the installed files look fine to me though? The kiface files would be
>> >> hundreds of megs themselves if they had debug symbols but they are at
>> >> "normal" levels.
>> >> On Sun, Jul 22, 2018 at 11:16 PM Seth Hillbrand  
>> >> wrote:
>> >> >
>> >> > Hi Devs-
>> >> >
>> >> > I'm seeing some reports (lp:1783037) that indicate the Windows build 
>> >> > may be compiled CMAKE_BUILD_TYPE=RelWithDebInfo instead of Release.
>> >> >
>> >> > Can anyone confirm this?  Is there a reason to do this for Windows?
>> >> >
>> >> > -Seth
>> >> >
>> >> > ___
>> >> > 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



-- 
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] Windows Builds

[Adam Wolf]

Ok, this sounds bad.

Can someone (Marek?) pull the macOS build and revert the macOS download
page, please?  I'm running extremely low on sleep from the last two nights
of KiCad hacking and I am literally in bed already.

I will regenerate the macOS build with Release instead in approximately 8
hours.

Adam

On Sun, Jul 22, 2018, 10:48 PM Mark Roszko  wrote:

> Welp, I poked Nick. It looks like the stable-debug build got packaged
> instead of the stable build config (I can reproduce the asserts).
> Though the executables are suspiciously not huge like they should be.
> On Sun, Jul 22, 2018 at 11:30 PM Seth Hillbrand 
> wrote:
> >
> > No, It's because asserts are being triggered.  These are disabled
> (normally) in Release builds.
> >
> > -S
> >
> > Am So., 22. Juli 2018 um 20:28 Uhr schrieb Mark Roszko <
> mark.ros...@gmail.com>:
> >>
> >> Is it because the installer exe is huge?
> >>
> >> That's because the footprint libraries are now part of the installers
> >> and they are absolutely massive. (4GB uncompressed)
> >>
> >> the installed files look fine to me though? The kiface files would be
> >> hundreds of megs themselves if they had debug symbols but they are at
> >> "normal" levels.
> >> On Sun, Jul 22, 2018 at 11:16 PM Seth Hillbrand 
> wrote:
> >> >
> >> > Hi Devs-
> >> >
> >> > I'm seeing some reports (lp:1783037) that indicate the Windows build
> may be compiled CMAKE_BUILD_TYPE=RelWithDebInfo instead of Release.
> >> >
> >> > Can anyone confirm this?  Is there a reason to do this for Windows?
> >> >
> >> > -Seth
> >> >
> >> > ___
> >> > 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] Windows Builds

[Mark Roszko]

Is it because the installer exe is huge?

That's because the footprint libraries are now part of the installers
and they are absolutely massive. (4GB uncompressed)

the installed files look fine to me though? The kiface files would be
hundreds of megs themselves if they had debug symbols but they are at
"normal" levels.
On Sun, Jul 22, 2018 at 11:16 PM Seth Hillbrand  wrote:
>
> Hi Devs-
>
> I'm seeing some reports (lp:1783037) that indicate the Windows build may be 
> compiled CMAKE_BUILD_TYPE=RelWithDebInfo instead of Release.
>
> Can anyone confirm this?  Is there a reason to do this for Windows?
>
> -Seth
>
> ___
> 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] Windows Builds

[Seth Hillbrand]

No, It's because asserts are being triggered.  These are disabled
(normally) in Release builds.

-S

Am So., 22. Juli 2018 um 20:28 Uhr schrieb Mark Roszko <
mark.ros...@gmail.com>:

> Is it because the installer exe is huge?
>
> That's because the footprint libraries are now part of the installers
> and they are absolutely massive. (4GB uncompressed)
>
> the installed files look fine to me though? The kiface files would be
> hundreds of megs themselves if they had debug symbols but they are at
> "normal" levels.
> On Sun, Jul 22, 2018 at 11:16 PM Seth Hillbrand 
> wrote:
> >
> > Hi Devs-
> >
> > I'm seeing some reports (lp:1783037) that indicate the Windows build may
> be compiled CMAKE_BUILD_TYPE=RelWithDebInfo instead of Release.
> >
> > Can anyone confirm this?  Is there a reason to do this for Windows?
> >
> > -Seth
> >
> > ___
> > 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] Windows Builds

[Mark Roszko]

Welp, I poked Nick. It looks like the stable-debug build got packaged
instead of the stable build config (I can reproduce the asserts).
Though the executables are suspiciously not huge like they should be.
On Sun, Jul 22, 2018 at 11:30 PM Seth Hillbrand  wrote:
>
> No, It's because asserts are being triggered.  These are disabled (normally) 
> in Release builds.
>
> -S
>
> Am So., 22. Juli 2018 um 20:28 Uhr schrieb Mark Roszko 
> :
>>
>> Is it because the installer exe is huge?
>>
>> That's because the footprint libraries are now part of the installers
>> and they are absolutely massive. (4GB uncompressed)
>>
>> the installed files look fine to me though? The kiface files would be
>> hundreds of megs themselves if they had debug symbols but they are at
>> "normal" levels.
>> On Sun, Jul 22, 2018 at 11:16 PM Seth Hillbrand  wrote:
>> >
>> > Hi Devs-
>> >
>> > I'm seeing some reports (lp:1783037) that indicate the Windows build may 
>> > be compiled CMAKE_BUILD_TYPE=RelWithDebInfo instead of Release.
>> >
>> > Can anyone confirm this?  Is there a reason to do this for Windows?
>> >
>> > -Seth
>> >
>> > ___
>> > 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] Windows builds broken?

[Maciej Sumiński]

Sincere apologies. As far as I can see, Jean-Pierre has already pushed a
fix.

Orson

On 04/24/2018 03:22 PM, Wayne Stambaugh wrote:
> Is anyone else have issues with broken windows builds?  I'm getting this
> error after pulling the latest changes:
> 
> C:/msys64/home/wstambaugh/src/kicad-trunk/common/tool/tool_manager.cpp:838:20:
> error: prototype for 'KIGFX::VC_SETTINGS
> TOOL_MANAGER::GetCurrentToolVC() const' does not match any in class
> 'TOOL_MANAGER'
>  KIGFX::VC_SETTINGS TOOL_MANAGER::GetCurrentToolVC() const
> ^~~~
> In file included from
> C:/msys64/home/wstambaugh/src/kicad-trunk/common/tool/tool_manager.cpp:39:0:
> C:/msys64/home/wstambaugh/src/kicad-trunk/include/tool/tool_manager.h:373:25:
> error: candidate is: KIGFX::VC_SETTINGS&
> TOOL_MANAGER::GetCurrentToolVC() const
>  KIGFX::VC_SETTINGS& GetCurrentToolVC() const;
>  ^~~~
> make[2]: *** [common/CMakeFiles/common.dir/build.make:3936:
> common/CMakeFiles/common.dir/tool/tool_manager.cpp.obj] Error 1
> make[1]: *** [CMakeFiles/Makefile2:623:
> common/CMakeFiles/common.dir/all] Error 2
> m
> 
> ___
> 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
> 




signature.asc
Description: OpenPGP digital signature
___
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] Windows builds broken?

[jp charras]

Le 24/04/2018 à 15:22, Wayne Stambaugh a écrit :
> Is anyone else have issues with broken windows builds?  I'm getting this
> error after pulling the latest changes:
> 

Yes, me.
I just committed a fix, a few minutes ago.


> C:/msys64/home/wstambaugh/src/kicad-trunk/common/tool/tool_manager.cpp:838:20:
> error: prototype for 'KIGFX::VC_SETTINGS
> TOOL_MANAGER::GetCurrentToolVC() const' does not match any in class
> 'TOOL_MANAGER'
>  KIGFX::VC_SETTINGS TOOL_MANAGER::GetCurrentToolVC() const
> ^~~~
> In file included from
> C:/msys64/home/wstambaugh/src/kicad-trunk/common/tool/tool_manager.cpp:39:0:
> C:/msys64/home/wstambaugh/src/kicad-trunk/include/tool/tool_manager.h:373:25:
> error: candidate is: KIGFX::VC_SETTINGS&
> TOOL_MANAGER::GetCurrentToolVC() const
>  KIGFX::VC_SETTINGS& GetCurrentToolVC() const;
>  ^~~~
> make[2]: *** [common/CMakeFiles/common.dir/build.make:3936:
> common/CMakeFiles/common.dir/tool/tool_manager.cpp.obj] Error 1
> make[1]: *** [CMakeFiles/Makefile2:623:
> common/CMakeFiles/common.dir/all] Error 2
> m

-- 
Jean-Pierre CHARRAS

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

Re: [Kicad-developers] Windows builds broken?

[Wayne Stambaugh]

On 4/24/2018 9:33 AM, jp charras wrote:
> Le 24/04/2018 à 15:22, Wayne Stambaugh a écrit :
>> Is anyone else have issues with broken windows builds?  I'm getting this
>> error after pulling the latest changes:
>>
> 
> Yes, me.
> I just committed a fix, a few minutes ago.

Thanks for the quick response!

> 
> 
>> C:/msys64/home/wstambaugh/src/kicad-trunk/common/tool/tool_manager.cpp:838:20:
>> error: prototype for 'KIGFX::VC_SETTINGS
>> TOOL_MANAGER::GetCurrentToolVC() const' does not match any in class
>> 'TOOL_MANAGER'
>>  KIGFX::VC_SETTINGS TOOL_MANAGER::GetCurrentToolVC() const
>> ^~~~
>> In file included from
>> C:/msys64/home/wstambaugh/src/kicad-trunk/common/tool/tool_manager.cpp:39:0:
>> C:/msys64/home/wstambaugh/src/kicad-trunk/include/tool/tool_manager.h:373:25:
>> error: candidate is: KIGFX::VC_SETTINGS&
>> TOOL_MANAGER::GetCurrentToolVC() const
>>  KIGFX::VC_SETTINGS& GetCurrentToolVC() const;
>>  ^~~~
>> make[2]: *** [common/CMakeFiles/common.dir/build.make:3936:
>> common/CMakeFiles/common.dir/tool/tool_manager.cpp.obj] Error 1
>> make[1]: *** [CMakeFiles/Makefile2:623:
>> common/CMakeFiles/common.dir/all] Error 2
>> m
> 

___
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