Re: [Kicad-developers] PATCH: Raytracing - a more pleasing way sequencing blocks to render ?
Hi Henner, Happy to see someone using and adding features to 3D Viewer! I didn't get a chance to test the patch yet but I was thinking adding another options to implement some kind of spiral rendering from the center :) (as usually the board is centered) Mario Luzeiro From: Kicad-developers on behalf of Henner Zeller Sent: 01 May 2019 07:29 To: KiCad Developers Subject: [Kicad-developers] PATCH: Raytracing - a more pleasing way sequencing blocks to render ? Hi, I often use the excellent raytracing mode to get a nice 3D view of the board. The rendering of the individual blocks is done in a Morton sequence, possibly to minimize cache-miss penalties. Since this render sequence starts in one corner, it usually takes a while until the "meat" of the render hits the interesting parts in the middle of the board. So I implemented an alternative sequence: from the center out, in a growing circle. To ease the time long renders take, it is actually two complementing checkerboard patterns in consecutive passes (hard to explain, you have to patch and look for yourself). I find this much more pleasing to watch and also it helps to early see for the user if they want to adjust the view as the important parts are rendered first. Of course, this will be slightly slower (possibly due to cache issues), but in measurements on my machine this is typically in the imperceptible noise (9.0 seconds vs. 9.1 seconds for instance). Given that there might be a performance penalty I prepared two patches: one that just does the rendering from the center, and one which provides a setting in the menu-bar to give full choice. (it might be good for comparison the two types of renderings, but given the complexity and the added end-user confusion and the essentially imperceptible performance penalty, I'd tend towards just using the simple implementation without menu-bar settings). Anyway, attached you find two patches: raytrace-from-center-always.patch just does as described above, without setting. The raytrace-from-center-with-menubar-setting.patch goes all the way of having a menu-bar choice and storing the setting in a configuration (more complex, less preferred). These patches are against the 5.1 branch, but it also applies cleanly to master. Cheers, Henner. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Pcbnew display origin transforms for v6
Hi Reece, You should code internal stuff in VECTOR2I rather than wxPoint. wxPoint should only be used when going to the UI. (We’re trying to reduce our wxWidgets dependencies, although this is very much a work in progress.) If you do use UNIT_BINDER keep in mind that it’s not yet used in WX_GRID (mainly because some work needs to be done so that cells know whether or not they hold a numeric value). If you want to tackle that too, that would be awesome. Cheers, Jeff. > On 1 May 2019, at 02:50, Reece R. Pollack wrote: > > Inspired by KiCon (and before the high wears off) I'm moving forward with my > project to allow the user to specify the coordinate display origin in pcbnew. > I have this working as patches to the v5.1.2 branch, but they're hard-coded > to use the Aux origin. I'd like some guidance on how best to code this for > eventual inclusion into the v6 development branch. > > My plan is: > Create a new class ORIGIN_TRANSFORM. This class maintains the user's > configuration and provides functions to perform the transforms necessary to > convert between the internal coordinate representation and the equivalent > coordinates relative to the user-selected origin. > Embed two ORIGIN_TRANSFORM objects in the BOARD_DESIGN_SETTINGS class > representing the origin transforms for the X and Y axes. > Create a new tab in the pcbnew "Preferences" to allow the user to select the > origin (Page [default], Aux, or Grid) and direction (Left or Right [default], > Up or Down [default]) for each axis. > Modify the board file format to save and load the user's ORIGIN_TRANSFORM > configuration. Saving this in the .kicad_pcb file allows everyone editing the > board to see coordinates reported relative to the same origin. > Modify each of the dialog classes that displays object coordinates to use the > ORIGIN_TRANSFORM objects to display coordinates relative to the user-selected > origin. When the dialog is closed object coordinates are converted back to > internal coordinates. > Modify the PCB_BASE_FRAME class to display the absolute cursor position > relative to the user-selected origin. > This is structured to allow the UNIT_BINDER class to manage origin > transforms, much like it handles the mm/mil conversions. I would change the > constructor to take a reference to an ORIGIN_TRANSFORM object as an > additional argument; the default value would be a unity-transform whose > conversion functions return the value to be converted unmodified. Those > UNIT_BINDER objects that represent a coordinate value (commonly m_posX and > m_posY) would be constructed with a reference to one of the two > ORIGIN_TRANSFORM objects in the BOARD_DESIGN_SETTINGS class. > > The problem with this strategy is that KiCad reuses UNIT_BINDER objects for > dissimilar purposes. For example, DIALOG_GRAPHIC_ITEM_PROPERTIES::m_endX can > represent the end point of a graphic line, for which origin transform is > needed. But it can also represent the radius of a circle, for which origin > transform is inappropriate. Thus UNIT_BINDER needs a method similar to the > Show() function to enable or disable the origin transform depending on how it > is being used. This may argue against pushing this functionality into > UNIT_BINDER. > > If I don't modify the UNIT_BINDER class I'll probably code the > ORIGIN_TRANSFORM class to handle wxPoint objects rather than individual > coordinates. Thus there would be only one ORIGIN_TRANSFORM object added to > the BOARD_DESIGN_SETTINGS class. The transform in the dialog class then > becomes a single call to transform a coordinate pair rather than one each for > X and Y. > Thoughts? Comments? Suggestions? Brickbats? > -Reece > > > ___ > 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] PATCH: Raytracing - a more pleasing way sequencing blocks to render ?
On 01/05/2019 10:53, Mário Luzeiro wrote:
Hi Henner,
I didn't get a chance to test the patch yet but
I was thinking adding another options to implement some kind of spiral
rendering from the center :) (as usually the board is centered)
Assuming the reason for the Morton code in the existing code is to
improve cache locality, it should work pretty well - each block is near
the previous one, though not as good as the Morton code, because we will
go around and do some "far" blocks before doing "near" blocks on the
next loop out, wasting/recaching some items.
However, as a fun test, this sort functor actually produces *better*
speeds (24s vs 25s)
[&](const SFVEC2UI &a, const SFVEC2UI &b){ return !!(rand() % 2); }
So jumping around the blocks randomly actually *improves* speed. I don't
know why!
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
[Kicad-developers] Windows builds broken
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
Re: [Kicad-developers] Windows builds broken
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 broken
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
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 `_imp___ZN5boost9unit_test
Re: [Kicad-developers] Windows builds broken
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
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
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
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
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
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
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] PATCH: Raytracing - a more pleasing way sequencing blocks to render ?
Hi John,
yeah the Morton code is to improve cache hits.
Regarding the speed test, since OS are multi-tasking there could be some
interference on the results so 1s difference is not a very measurable
difference ( 4% ).
A possibility would be to run the same scene multiple times and make an average
of the times.
On this small change proposed by Henner I wouldn't put into account the speed,
as I hope (even with cache misses) there will not be a dramatic change on the
render time.
Mario Luzeiro
From: John Beard
Sent: 01 May 2019 12:10
To: Mário Luzeiro; Henner Zeller; KiCad Developers
Subject: Re: [Kicad-developers] PATCH: Raytracing - a more pleasing way
sequencing blocks to render ?
On 01/05/2019 10:53, Mário Luzeiro wrote:
> Hi Henner,
> I didn't get a chance to test the patch yet but
> I was thinking adding another options to implement some kind of spiral
> rendering from the center :) (as usually the board is centered)
Assuming the reason for the Morton code in the existing code is to
improve cache locality, it should work pretty well - each block is near
the previous one, though not as good as the Morton code, because we will
go around and do some "far" blocks before doing "near" blocks on the
next loop out, wasting/recaching some items.
However, as a fun test, this sort functor actually produces *better*
speeds (24s vs 25s)
[&](const SFVEC2UI &a, const SFVEC2UI &b){ return !!(rand() % 2); }
So jumping around the blocks randomly actually *improves* speed. I don't
know why!
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] PATCH: Raytracing - a more pleasing way sequencing blocks to render ?
On 01/05/2019 13:57, Mário Luzeiro wrote: Hi John, yeah the Morton code is to improve cache hits. Regarding the speed test, since OS are multi-tasking there could be some interference on the results so 1s difference is not a very measurable difference ( 4% ). A possibility would be to run the same scene multiple times and make an average of the times. Sure, it was just a fun observation. It does change a bit from run to run, but I was at least expecting a small penalty. Next up, wipes[1] and then perhaps Snake :-D A more robust benchmarking harness would probably be the way to go if we really were serious about putting the pedal to the metal here. But I think the centre-first approach is certainly better usability, but I'm unsure about the checkerboard. Cheers, John [1]: https://www.youtube.com/watch?v=cGqAu9gj_F0 ___ 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
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] PATCH: Raytracing - a more pleasing way sequencing blocks to render ?
On Wed, 1 May 2019 at 06:14, John Beard wrote:
>
> On 01/05/2019 13:57, Mário Luzeiro wrote:
> > Hi John,
> >
> > yeah the Morton code is to improve cache hits.
> >
> > Regarding the speed test, since OS are multi-tasking there could be some
> > interference on the results so 1s difference is not a very measurable
> > difference ( 4% ).
> > A possibility would be to run the same scene multiple times and make an
> > average of the times.
>
> Sure, it was just a fun observation. It does change a bit from run to
> run, but I was at least expecting a small penalty. Next up, wipes[1] and
> then perhaps Snake :-D
>
> A more robust benchmarking harness would probably be the way to go if we
> really were serious about putting the pedal to the metal here.
>
> But I think the centre-first approach is certainly better usability, but
> I'm unsure about the checkerboard.
I agree, without checkerboard it makes it quicker to see what is going
on in the center. Attached the (even simpler) just spiraling out from
the center patch.
>
> Cheers,
>
> John
>
> [1]: https://www.youtube.com/watch?v=cGqAu9gj_F0
diff --git a/3d-viewer/3d_rendering/3d_render_raytracing/c3d_render_raytracing.cpp b/3d-viewer/3d_rendering/3d_render_raytracing/c3d_render_raytracing.cpp
index b059cfeaf..f7fc54b21 100644
--- a/3d-viewer/3d_rendering/3d_render_raytracing/c3d_render_raytracing.cpp
+++ b/3d-viewer/3d_rendering/3d_render_raytracing/c3d_render_raytracing.cpp
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include "c3d_render_raytracing.h"
#include "mortoncodes.h"
@@ -2074,6 +2075,13 @@ bool C3D_RENDER_RAYTRACING::initializeOpenGL()
}
+static float distance(const SFVEC2UI &a, const SFVEC2UI &b)
+{
+const float dx = (float)a.x - (float)b.x;
+const float dy = (float)a.y - (float)b.y;
+return hypotf(dx, dy);
+}
+
void C3D_RENDER_RAYTRACING::initialize_block_positions()
{
@@ -2123,26 +2131,26 @@ void C3D_RENDER_RAYTRACING::initialize_block_positions()
m_postshader_ssao.UpdateSize( m_realBufferSize );
-// Calc block positions
+// Calc block positions for regular rendering. Choose an 'inside out'
+// style of rendering
// /
m_blockPositions.clear();
-m_blockPositions.reserve( (m_realBufferSize.x / RAYPACKET_DIM) *
- (m_realBufferSize.y / RAYPACKET_DIM) );
-
-i = 0;
-
-while(1)
-{
-SFVEC2UI blockPos( DecodeMorton2X(i) * RAYPACKET_DIM,
- DecodeMorton2Y(i) * RAYPACKET_DIM );
-i++;
-
-if( (blockPos.x >= m_realBufferSize.x) && (blockPos.y >= m_realBufferSize.y) )
-break;
-
-if( (blockPos.x < m_realBufferSize.x) && (blockPos.y < m_realBufferSize.y) )
-m_blockPositions.push_back( blockPos );
-}
+const int blocks_x = m_realBufferSize.x / RAYPACKET_DIM;
+const int blocks_y = m_realBufferSize.y / RAYPACKET_DIM;
+m_blockPositions.reserve( blocks_x * blocks_y );
+
+for (int x = 0; x < blocks_x; ++x)
+for (int y = 0; y < blocks_y; ++y)
+m_blockPositions.push_back(SFVEC2UI(x * RAYPACKET_DIM,
+y * RAYPACKET_DIM));
+
+const SFVEC2UI center(m_realBufferSize.x/2, m_realBufferSize.y/2);
+std::sort(m_blockPositions.begin(), m_blockPositions.end(),
+ [&](const SFVEC2UI &a, const SFVEC2UI &b)
+ {
+ // Sort order: inside out.
+ return distance(a, center) < distance(b, center);
+ });
// Create m_shader buffer
delete[] m_shaderBuffer;
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] PATCH: Raytracing - a more pleasing way sequencing blocks to render ?
Hi Henner, Instead of using SFVEC2UI and hypotf (probably slow), could it be implemented using SFVEC2F and glm::length( a - b ) ? Mario From: Henner Zeller Sent: 01 May 2019 14:44 To: John Beard Cc: Mário Luzeiro; KiCad Developers Subject: Re: [Kicad-developers] PATCH: Raytracing - a more pleasing way sequencing blocks to render ? On Wed, 1 May 2019 at 06:14, John Beard wrote: > > On 01/05/2019 13:57, Mário Luzeiro wrote: > > Hi John, > > > > yeah the Morton code is to improve cache hits. > > > > Regarding the speed test, since OS are multi-tasking there could be some > > interference on the results so 1s difference is not a very measurable > > difference ( 4% ). > > A possibility would be to run the same scene multiple times and make an > > average of the times. > > Sure, it was just a fun observation. It does change a bit from run to > run, but I was at least expecting a small penalty. Next up, wipes[1] and > then perhaps Snake :-D > > A more robust benchmarking harness would probably be the way to go if we > really were serious about putting the pedal to the metal here. > > But I think the centre-first approach is certainly better usability, but > I'm unsure about the checkerboard. I agree, without checkerboard it makes it quicker to see what is going on in the center. Attached the (even simpler) just spiraling out from the center patch. > > Cheers, > > John > > [1]: https://www.youtube.com/watch?v=cGqAu9gj_F0 ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] PATCH: Raytracing - a more pleasing way sequencing blocks to render ?
On Wed, 1 May 2019 at 06:54, Mário Luzeiro wrote: > > Hi Henner, > > Instead of using SFVEC2UI and hypotf (probably slow), could it be implemented > using SFVEC2F and glm::length( a - b ) ? I didn't know about SFVEC2F or glm::length functions, but then again, this only happens at preparation time when we set up a new buffer and blocks to render, so this happens once whenever the window size changes; everything in that preparation will probably only take a few microseconds to run even on an old machine, so I was not worried either (Whatever glm::length is doing, will probably just call hyoptf() anyway...) If there are more elegant ways to describe the same, it should be done of course. -h > > Mario > > From: Henner Zeller > Sent: 01 May 2019 14:44 > To: John Beard > Cc: Mário Luzeiro; KiCad Developers > Subject: Re: [Kicad-developers] PATCH: Raytracing - a more pleasing way > sequencing blocks to render ? > > On Wed, 1 May 2019 at 06:14, John Beard wrote: > > > > On 01/05/2019 13:57, Mário Luzeiro wrote: > > > Hi John, > > > > > > yeah the Morton code is to improve cache hits. > > > > > > Regarding the speed test, since OS are multi-tasking there could be some > > > interference on the results so 1s difference is not a very measurable > > > difference ( 4% ). > > > A possibility would be to run the same scene multiple times and make an > > > average of the times. > > > > Sure, it was just a fun observation. It does change a bit from run to > > run, but I was at least expecting a small penalty. Next up, wipes[1] and > > then perhaps Snake :-D > > > > A more robust benchmarking harness would probably be the way to go if we > > really were serious about putting the pedal to the metal here. > > > > But I think the centre-first approach is certainly better usability, but > > I'm unsure about the checkerboard. > > I agree, without checkerboard it makes it quicker to see what is going > on in the center. Attached the (even simpler) just spiraling out from > the center patch. > > > > > Cheers, > > > > John > > > > [1]: https://www.youtube.com/watch?v=cGqAu9gj_F0 ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] macOS build errors, swig?
Hi folks! I'm seeing broken builds, reporting 06:14:03 default: Error: the swig import helper was not fixed, check /vagrant/build/kicad/src/kicad-build/pcbnew/pcbnew.py 06:14:03 default:and fix this script: fix_swig_imports.py 06:14:03 default: make[6]: *** [pcbnew/pcbnew_wrap.cxx] Error 2 across the board on my macOS builds, both 10.11 and 10.14. This appears to be new since 9741b43da. Adam ___ 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
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
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
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, 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
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
