Re: [Kicad-developers] New package for macOS 5.1.2 stable including ngspice-30 ?
I do not personally use ngspice. I have filed an issue if someone has a
quick one to add.
https://github.com/KiCad/kicad-mac-builder/issues/90
Adam
On Mon, Jul 1, 2019, 9:43 PM Nick Østergaard wrote:
> Good news, it seems like we managed to make the kicad-mac-packaging
> scripts happy.
>
> After upgrading to ngspice 30 we had to update the include path for
> some unknown reason. But it seems like it should work now. The first
> build has been pushed to the nightly download location. It is not been
> repackaged for stable. I guess Adam will handle that if we don't
> release a 5.1.3 before.
>
> But I don't think it is ready for primetime yet, first user of the build
> says:
>
> <{HD}> haha so hitting the play button crashed all of kicad
> <{HD}> yep, just tried again. The whole thing crashes.
> <{HD}> This is fun and all but I am going out for dinner. I will be
> back in a few hours.
>
> So if anyone else on mac could try it out? Maybe you Jeff can try it out?
> I think he tested the unified version:
>
> https://kicad-downloads.s3.cern.ch/osx/nightly/kicad-unified-20190701-113048-53e18489e-10_14.dmg
>
> Cheers.
>
> On Fri, 21 Jun 2019 at 11:16, Nick Østergaard wrote:
> >
> > I see no reason to make ngspice 30 a strict minimum requirement.
> >
> > Lets just help packagers update to the latest ngspice and we are good.
> >
> > tor. 13. jun. 2019 18.33 skrev Wayne Stambaugh :
> >>
> >> On 6/10/19 4:01 PM, Carsten Schoenert wrote:
> >> > Hello Wayne,
> >> >
> >> > Am 10.06.19 um 20:15 schrieb Wayne Stambaugh:
> >> >> We cannot make ngspice 30 the minimum version. There are far too
> many
> >> >> linux distros where 30 is not available yet. Please keep in mind,
> >> >> Debian stable and the latest Ubuntu LTS version are the benchmarks
> for
> >> >> dependency package versions. I'm fine with packaging macos and
> windows
> >> >> with 30.
> >> >
> >> > current Debian stable (Stretch) has KiCad version 4.0.5+dfsg1-4 in the
> >> > archive and no package libngspice0 at all (not even in non-free) so
> >> > there is nothing to take care on here.
> >> >
> >> > The current Ubuntu LTS release 18.04 (Bionic Beaver) has KiCad version
> >> > 4.0.7+dfsg1-1ubuntu2 and libngspice0 version 27-1.
> >> > At least the KiCad version is long long outdated. So also not really
> >> > relevant too.
> >> >
> >> > But all relevant current Debian releases are providing a recent KiCad
> >> > version and also libngspice0 in version 30.2-1 (from unstable to
> >> > stretch-backports). This is also available in all Downstream of Debian
> >> > means also in Ubuntu >= 'Cosmic Cuttlefish' are providing KiCad
> >> > 5.0.0+dfsg1-2, but also libngspice0 in version 27. Updates wont
> happen.
> >> >
> >> > But Jean-Samuel Reynaud is providing actual versions of KiCad and also
> >> > the depending libngspice0 package and they even work in the always
> >> > outdated Linux Mint distro. So for me your requirements you like to
> set
> >> > are fulfilled.
> >> >
> >> > And normally the application is defining the requirements. Simulations
> >> > seems to be for some users an critical option. So if the maintainers
> of
> >> > ngspice hardly suggesting to use the most recent version of ngspice in
> >> > recent KiCad version I would strongly consider to increase this build
> >> > dependency.
> >> >
> >> > In the end it's up to the KiCad maintainers to define the requirements
> >> > for KiCad. It was a long road to get ngspice into Debian main but in
> the
> >> > end it happened, big thanks to Holger again btw! So Debian has no
> >> > problem to provide KiCad with a depending libngspice0 library >= 30.2.
> >> >
> >>
> >> Is this a problem for any of the other package devs? If not, I have no
> >> issue with bumping the minimum version to 30. If this prevents any
> >> other platforms from being built, then it will have to wait.
> >>
> >> Cheers,
> >>
> >> 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] [PATCH 0/9] MSVC build support
Simon, What is the minimum version of MSVC required for building this? -Ian On Mon, Jul 1, 2019 at 1:26 PM Simon Richter wrote: > Hi, > > this is a rework of Tom's rework of my MSVC branch, compile-tested on > Linux, MSYS2 and MSVC. The full branch is on Launchpad, as > > https://git.launchpad.net/~sjr/kicad/msvc-new . > > Before we can merge this, this needs more extensive testing, and a few > reviews. If you want to try binaries from MSVC, get them from the build > artifacts of the appropriate configuration below > > https://jenkins.simonrichter.eu/job/windows-kicad-msvc-tom/ > > I've snuck in the "Turn off compiler extensions" patch again, that one is > optional (and breaks MSYS2 without a particular workaround, so we need to > decide if we want it). The other patches are fairly straightforward. > > Including probably makes sense everywhere, not just in the files > where we need strncasecmp. > >Simon > > Simon Richter (6): > Set _USE_MATH_DEFINES on Windows > Turn off compiler extensions > Remove own copy of FindOpenSSL.cmake > Work around missing min/max in Windows headers > Pull in macro definition for strncasecmp on MSVC > Define compiler flags for MSVC > > Tomasz Wlostowski (3): > pcbnew: can't return a copy of ptr_vector if items are polymorphic and > have no clone() methods. Work it around. > Export LIB_TREE_ITEM > MSVC support for libcontext > > CMakeLists.txt | 49 ++ > CMakeModules/FindOpenSSL.cmake | 342 > --- > common/gal/cairo/cairo_print.cpp | 6 + > common/system/libcontext.cpp | 66 > eeschema/sim/ngspice.cpp | 1 + > include/lib_tree_item.h | 4 +- > include/system/libcontext.h | 16 +- > include/tool/coroutine.h | 8 +- > pcbnew/pcb_edit_frame.h | 3 +- > pcbnew/pcbnew_config.cpp | 12 +- > 10 files changed, 153 insertions(+), 354 deletions(-) > delete mode 100644 CMakeModules/FindOpenSSL.cmake > > -- > 2.11.0 > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] C++14 (redux)
Hi Devs- Now that Ubuntu 14.04LTS support has ended, are we building any platforms that do not support C++14 (gcc prior to version 5)? If not, can we bump our compiler language support to C++14? This would allow us to drop the ban on certain version of GLM as well as our custom-rolled std::make_unique. There are a few language features (generalized lambda captures!) that would tighten up quite a bit of code if available. Obviously if we are still supporting a C++11 only system, this should be delayed. Best- 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
Re: [Kicad-developers] Bug #1752298: Clean up sorting functions for mixed text and numbers
I think Simon’s example are great, and also whoever mentioned doubling up letters /after/ cycling through the 26 (so AA follows Z). Note also that there may only be the two or three in the bug report. I’ve folded in at least two other examples over the last year or so. Cheers, Jeff. > On 1 Jul 2019, at 16:54, Simon Richter wrote: > > Hi Wayne, > > On Mon, Jul 01, 2019 at 09:22:15AM -0400, Wayne Stambaugh wrote: > >> We already have a string comparison function that handles this. Take a >> look at StrNumCmp()[1] in common/string.cpp[2]. We use this function in >> many places for mixed text and number comparisons so I see no reason not >> to use it in this case unless there is a bug in StrNumCmp(). > > I wrote that bug report because we have more than one function for that, so > there is some duplication. This will probably need multiple modes that > modify it, e.g. for BGA balls or voltages being used as net names. > > Examples where I think the current order is nonintuitive: > > - [ "A1", "A2", "AA1", "AA2", "B1", "B2", ... ] > - [ "+1.2V", "+1V", "-1.2V", "-1V", "-12V", "1V", "12V" ] > > eeschema/pin_number.cpp has PinNumbers::Compare, which aims to handle the > latter case, but it has a hardcoded rule that "V" can be used as a decimal > point, which is also too broad and too narrow at the same time (e.g. we > might want a mode where "R" is a decimal point, but "V" isn't). > > 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] [PATCH] Crash Reporter
Hello Tomasz Do you have any comments on the wxwidgets version? It looks like 3.0.4 of wxwidgets is the latest version packaged in msys2 as of today. On Wed, 12 Jun 2019 at 23:58, Nick Østergaard wrote: > > It looks like you mis-cited me there. That was Wayne that wrote that, > I don't klnow about the details here. > > Anyway, the packages are shown on: > https://jenkins.simonrichter.eu/job/windows-kicad-msys2-patch/ws/pkglist.txt/*view*/ > > mingw-w64-x86_64-wxWidgets 3.0.4-2 > > On Wed, 12 Jun 2019 at 14:10, Tomasz Wlostowski > wrote: > > > > On 11/06/2019 22:29, Nick Østergaard wrote: > > > Too bad the gcc windows > > > build crash report doesn't have a stack trace. Maybe MSVC builds would > > > have more debug info. > > > > Hi Nick, > > > > My build (wx 3.1.1) under MSYS has stack traces. Which version of > > wxWidgets did you use? > > > > Tom ___ Mailing list: https://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] New package for macOS 5.1.2 stable including ngspice-30 ?
Good news, it seems like we managed to make the kicad-mac-packaging
scripts happy.
After upgrading to ngspice 30 we had to update the include path for
some unknown reason. But it seems like it should work now. The first
build has been pushed to the nightly download location. It is not been
repackaged for stable. I guess Adam will handle that if we don't
release a 5.1.3 before.
But I don't think it is ready for primetime yet, first user of the build says:
<{HD}> haha so hitting the play button crashed all of kicad
<{HD}> yep, just tried again. The whole thing crashes.
<{HD}> This is fun and all but I am going out for dinner. I will be
back in a few hours.
So if anyone else on mac could try it out? Maybe you Jeff can try it out?
I think he tested the unified version:
https://kicad-downloads.s3.cern.ch/osx/nightly/kicad-unified-20190701-113048-53e18489e-10_14.dmg
Cheers.
On Fri, 21 Jun 2019 at 11:16, Nick Østergaard wrote:
>
> I see no reason to make ngspice 30 a strict minimum requirement.
>
> Lets just help packagers update to the latest ngspice and we are good.
>
> tor. 13. jun. 2019 18.33 skrev Wayne Stambaugh :
>>
>> On 6/10/19 4:01 PM, Carsten Schoenert wrote:
>> > Hello Wayne,
>> >
>> > Am 10.06.19 um 20:15 schrieb Wayne Stambaugh:
>> >> We cannot make ngspice 30 the minimum version. There are far too many
>> >> linux distros where 30 is not available yet. Please keep in mind,
>> >> Debian stable and the latest Ubuntu LTS version are the benchmarks for
>> >> dependency package versions. I'm fine with packaging macos and windows
>> >> with 30.
>> >
>> > current Debian stable (Stretch) has KiCad version 4.0.5+dfsg1-4 in the
>> > archive and no package libngspice0 at all (not even in non-free) so
>> > there is nothing to take care on here.
>> >
>> > The current Ubuntu LTS release 18.04 (Bionic Beaver) has KiCad version
>> > 4.0.7+dfsg1-1ubuntu2 and libngspice0 version 27-1.
>> > At least the KiCad version is long long outdated. So also not really
>> > relevant too.
>> >
>> > But all relevant current Debian releases are providing a recent KiCad
>> > version and also libngspice0 in version 30.2-1 (from unstable to
>> > stretch-backports). This is also available in all Downstream of Debian
>> > means also in Ubuntu >= 'Cosmic Cuttlefish' are providing KiCad
>> > 5.0.0+dfsg1-2, but also libngspice0 in version 27. Updates wont happen.
>> >
>> > But Jean-Samuel Reynaud is providing actual versions of KiCad and also
>> > the depending libngspice0 package and they even work in the always
>> > outdated Linux Mint distro. So for me your requirements you like to set
>> > are fulfilled.
>> >
>> > And normally the application is defining the requirements. Simulations
>> > seems to be for some users an critical option. So if the maintainers of
>> > ngspice hardly suggesting to use the most recent version of ngspice in
>> > recent KiCad version I would strongly consider to increase this build
>> > dependency.
>> >
>> > In the end it's up to the KiCad maintainers to define the requirements
>> > for KiCad. It was a long road to get ngspice into Debian main but in the
>> > end it happened, big thanks to Holger again btw! So Debian has no
>> > problem to provide KiCad with a depending libngspice0 library >= 30.2.
>> >
>>
>> Is this a problem for any of the other package devs? If not, I have no
>> issue with bumping the minimum version to 30. If this prevents any
>> other platforms from being built, then it will have to wait.
>>
>> Cheers,
>>
>> 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] Arc editing in LibEdit
On 2019-07-01 7:21 a.m., Jeff Young wrote: Its on master (and so is in nightlies). Thanks, Jeff. The feature sounded experimental. I thought it might have been put in to a branch or made avaialable as a separate patch for testing. -- Cheers! Kevin. http://www.ve3syb.ca/ | "Nerds make the shiny things that https://www.patreon.com/KevinCozens | distract the mouth-breathers, and | that's why we're powerful" Owner of Elecraft K2 #2172 | #include | --Chris Hardwick ___ Mailing list: https://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] Bug 1834718
Hi Wayne- OK, I'm stumped here. I pushed the tool manager patch because it addresses a couple other issues on Linux and seems neutral in terms of this bug. What this looks like is that the new progress reporter gets assigned as the parent of the old reporter which is then deleted. We're passing the parent pointer from the tool manager, so it might be helpful to see a printout of the pointer addresses from the `frame()` function call at the beginning and end of the ZoneFillAll() function as well as the beginning of the ZoneFill() function (where it crashes). This should be the same address for the whole time, but it is possible we have some stack-smashing going on here that corrupts the address. This is really a long-shot but our first/best options didn't really pan out. -Seth On 2019-07-01 09:08, Wayne Stambaugh wrote: Nope :( #41640 0x6d26fb1d in ?? () from E:\msys64\mingw64\bin\wxmsw30u_core_gcc_custom.dll #41641 0x806e86f7 in WX_PROGRESS_REPORTER::~WX_PROGRESS_REPORTER ( this=0x1288fae0, __in_chrg=) at E:/msys64/home/Wayne/src/kicad-5.1/common/widgets/progress_reporter.cpp:117 #41642 0x806e8735 in WX_PROGRESS_REPORTER::~WX_PROGRESS_REPORTER ( this=0x1288fae0, __in_chrg=) at E:/msys64/home/Wayne/src/kicad-5.1/common/widgets/progress_reporter.cpp:118 #41643 0x809da748 in std::default_delete::operator() (this=0x15177128, __ptr=0x1288fae0) at E:/msys64/mingw64/include/c++/9.1.0/bits/unique_ptr.h:81 #41644 0x80a24404 in std::unique_ptrstd::default_delete >::~unique_ptr (this=0x15177128, __in_chrg=) at E:/msys64/mingw64/include/c++/9.1.0/bits/unique_ptr.h:289 #41645 0x802e4adf in ZONE_FILLER_TOOL::ZoneFill (this=0x1473b6b0, aEvent=...) at E:/msys64/home/Wayne/src/kicad-5.1/pcbnew/tools/zone_filler_tool.cpp:104 #41646 0x80bc7baf in std::__invoke_impl (__f= @0x128902a0: (int (ZONE_FILLER_TOOL::*)(class ZONE_FILLER_TOOL * const, const class TOOL_EVENT &)) 0x802e4888 , __t=@0x128902b0: 0x1473b6b0, __args#0=...) at E:/msys64/mingw64/include/c++/9.1.0/bits/invoke.h:73 #41647 0x80c17783 in std::__invoke (__fn= @0x128902a0: (int (ZONE_FILLER_TOOL::*)(class ZONE_FILLER_TOOL * const, const class TOOL_EVENT &)) 0x802e4888 , __args#0=@0x128902b0: 0x1473b6b0, __args#1=...) at E:/msys64/mingw64/include/c++/9.1.0/bits/invoke.h:95 #41648 0x80ab5b7b in std::_Bind))(TOOL_EVENT const&)>::__call(std::tuple&&, std::_Index_tuple<0ull, 1ull>) ( this=0x128902a0, __args=...) at E:/msys64/mingw64/include/c++/9.1.0/functional:400 #41649 0x80ab5ca4 in std::_Bind))(TOOL_EVENT const&)>::operator()(TOOL_EVENT const&) (this=0x128902a0, __args#0=...) at E:/msys64/mingw64/include/c++/9.1.0/functional:484 #41650 0x80a90219 in std::_Function_handler))(TOOL_EVENT const&)> >::_M_invoke(std::_Any_data const&, TOOL_EVENT const&) ( __functor=..., __args#0=...) at E:/msys64/mingw64/include/c++/9.1.0/bits/std_function.h:285 #41651 0x80a01b4b in std::function::operator()(TOOL_EVENT const&) const (this=0x14793998, __args#0=...) at E:/msys64/mingw64/include/c++/9.1.0/bits/std_function.h:690 #41652 0x809591ba in COROUTINEconst&>::callerStub ( aData=351771072) at E:/msys64/home/Wayne/src/kicad-5.1/include/tool/coroutine.h:331 #41653 0x807b8efa in make_fcontext () from E:\msys64\mingw64\bin\_pcbnew.kiface #41654 0x14f799c0 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) On 7/1/2019 8:35 AM, Seth Hillbrand wrote: Hi Wayne- Thanks for testing. If you have a chance, can you give the attached patch a spin? This is in place of the previous attempt. Best- Seth On 2019-07-01 07:51, Wayne Stambaugh wrote: Hey Seth, No bueno. Here is the back trace using your patch. Cheers, Wayne #41640 0x6d26fb1d in ?? () from E:\msys64\mingw64\bin\wxmsw30u_core_gcc_custom.dll #41641 0x806e8747 in WX_PROGRESS_REPORTER::~WX_PROGRESS_REPORTER ( this=0x12884860, __in_chrg=) at E:/msys64/home/Wayne/src/kicad-5.1/common/widgets/progress_reporter.cpp:117 #41642 0x806e8785 in WX_PROGRESS_REPORTER::~WX_PROGRESS_REPORTER ( this=0x12884860, __in_chrg=) at E:/msys64/home/Wayne/src/kicad-5.1/common/widgets/progress_reporter.cpp:118 #41643 0x809da798 in std::default_delete::operator() (this=0x1539f138, __ptr=0x12884860) at E:/msys64/mingw64/include/c++/9.1.0/bits/unique_ptr.h:81 #41644 0x80a24454 in std::unique_ptr >::~unique_ptr (this=0x1539f138, __in_chrg=) at E:/msys64/mingw64/include/c++/9.1.0/bits/unique_ptr.h:289 #41645 0x802e4b26 in ZONE_FILLER_TOOL::ZoneFill (this=0x14338300, aEvent=...) at E:/msys64/home/Wayne/src/kicad-5.1/pcbnew/tools/zone_filler_tool.cpp:103 #41646 0x80bc7b4f in std::__invoke_impl (__f= @0x182d4800: (int (ZONE_FILLER_TOOL::*)(class ZONE_FILLER_TOOL * const, const class TOOL_EVEN
Re: [Kicad-developers] [PATCH 1/1] Fix build order for generated headers and sources
Hi Seth, On Mon, Jul 01, 2019 at 12:33:43PM -0400, Seth Hillbrand wrote: > [ 38%] Building CXX object > eeschema/CMakeFiles/eeschema_kiface_objects.dir/widgets/symbol_tree_pane.cpp.o > /home/seth/code/kicad/kicad_bare/eeschema/dialogs/panel_sym_lib_table.cpp:29:10: > fatal error: lib_table_lexer.h: No such file or directory Mh, just saw the same on MSVC. :/ I'll do a few verbose builds in a loop to see what is happening there. In the failing builds, I can see that the file should have been built, and five minutes later the compiler complains. There is also just one instance of the generator message, so it's not the usual race condition, it seems. 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] [PATCH 1/1] Fix build order for generated headers and sources
Hi Simon- Thanks for the patch! Unfortunately, I get a build error on Linux Debian: [ 38%] Building CXX object eeschema/CMakeFiles/eeschema_kiface_objects.dir/widgets/symbol_tree_pane.cpp.o /home/seth/code/kicad/kicad_bare/eeschema/dialogs/panel_sym_lib_table.cpp:29:10: fatal error: lib_table_lexer.h: No such file or directory #include ^~~ compilation terminated. make[2]: *** [eeschema/CMakeFiles/eeschema_kiface_objects.dir/build.make:921: eeschema/CMakeFiles/eeschema_kiface_objects.dir/dialogs/panel_sym_lib_table.cpp.o] Error 1 This is with make -j42. Let me know if you'd like a full build log. Best- Seth On 2019-07-01 11:34, Simon Richter wrote: This changes make_lexer() so that it no longer generates a custom target but instead attaches the generated files to an existing one (so the first argument now is the name of an existing library or executable, and it needs to come after the add_library/add_executable call). The generated source is no longer listed in the project sources, as it is added by the function. The files are generated in the build tree rather than the source tree, and the directory is added to the include path for the respective project as well as exported to projects linking against it. Generated files in subdirectories are somewhat supported, but need to be referenced with the same name as they were generated (i.e. including the subdirectory name). --- CMakeModules/Functions.cmake | 27 CMakeModules/TokenList2DsnLexer.cmake | 2 +- common/CMakeLists.txt | 73 +-- common/page_layout/page_layout_reader.cpp | 2 +- common/page_layout/ws_data_model_io.cpp | 2 +- eeschema/CMakeLists.txt | 47 eeschema/dialogs/dialog_bom.cpp | 2 +- new/CMakeLists.txt| 26 +-- pcb_calculator/CMakeLists.txt | 14 ++ pcbnew/CMakeLists.txt | 27 pcbnew/specctra_import_export/specctra.h | 2 +- qa/eeschema/CMakeLists.txt| 5 +-- 12 files changed, 79 insertions(+), 150 deletions(-) ___ Mailing list: https://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 1/1] Fix build order for generated headers and sources
On 7/1/19 11:34 AM, Simon Richter wrote: > This changes make_lexer() so that it no longer generates a custom target > but instead attaches the generated files to an existing one (so the first > argument now is the name of an existing library or executable, and it needs > to come after the add_library/add_executable call). > > The generated source is no longer listed in the project sources, as it is > added by the function. The files are generated in the build tree rather > than the source tree, and the directory is added to the include path for > the respective project as well as exported to projects linking against it. > > Generated files in subdirectories are somewhat supported, but need to be > referenced with the same name as they were generated (i.e. including the > subdirectory name). I applied your patch, and ran a build with "make -j12". It worked fine. Steve ___ Mailing list: https://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] Bug #1752298: Clean up sorting functions for mixed text and numbers
Hi Wayne, On Mon, Jul 01, 2019 at 09:22:15AM -0400, Wayne Stambaugh wrote: > We already have a string comparison function that handles this. Take a > look at StrNumCmp()[1] in common/string.cpp[2]. We use this function in > many places for mixed text and number comparisons so I see no reason not > to use it in this case unless there is a bug in StrNumCmp(). I wrote that bug report because we have more than one function for that, so there is some duplication. This will probably need multiple modes that modify it, e.g. for BGA balls or voltages being used as net names. Examples where I think the current order is nonintuitive: - [ "A1", "A2", "AA1", "AA2", "B1", "B2", ... ] - [ "+1.2V", "+1V", "-1.2V", "-1V", "-12V", "1V", "12V" ] eeschema/pin_number.cpp has PinNumbers::Compare, which aims to handle the latter case, but it has a hardcoded rule that "V" can be used as a decimal point, which is also too broad and too narrow at the same time (e.g. we might want a mode where "R" is a decimal point, but "V" isn't). 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
[Kicad-developers] [PATCH 1/1] Fix build order for generated headers and sources
This changes make_lexer() so that it no longer generates a custom target
but instead attaches the generated files to an existing one (so the first
argument now is the name of an existing library or executable, and it needs
to come after the add_library/add_executable call).
The generated source is no longer listed in the project sources, as it is
added by the function. The files are generated in the build tree rather
than the source tree, and the directory is added to the include path for
the respective project as well as exported to projects linking against it.
Generated files in subdirectories are somewhat supported, but need to be
referenced with the same name as they were generated (i.e. including the
subdirectory name).
---
CMakeModules/Functions.cmake | 27
CMakeModules/TokenList2DsnLexer.cmake | 2 +-
common/CMakeLists.txt | 73 +--
common/page_layout/page_layout_reader.cpp | 2 +-
common/page_layout/ws_data_model_io.cpp | 2 +-
eeschema/CMakeLists.txt | 47
eeschema/dialogs/dialog_bom.cpp | 2 +-
new/CMakeLists.txt| 26 +--
pcb_calculator/CMakeLists.txt | 14 ++
pcbnew/CMakeLists.txt | 27
pcbnew/specctra_import_export/specctra.h | 2 +-
qa/eeschema/CMakeLists.txt| 5 +--
12 files changed, 79 insertions(+), 150 deletions(-)
diff --git a/CMakeModules/Functions.cmake b/CMakeModules/Functions.cmake
index b926cc0dd..6e7879d70 100644
--- a/CMakeModules/Functions.cmake
+++ b/CMakeModules/Functions.cmake
@@ -33,35 +33,24 @@
function( make_lexer outputTarget inputFile outHeaderFile outCppFile enum )
add_custom_command(
-OUTPUT ${outHeaderFile}
-${outCppFile}
+OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${outHeaderFile}
+${CMAKE_CURRENT_BINARY_DIR}/${outCppFile}
COMMAND ${CMAKE_COMMAND}
-Denum=${enum}
--DinputFile=${inputFile}
--DoutHeaderFile=${outHeaderFile}
--DoutCppFile=${outCppFile}
+-DinputFile=${CMAKE_CURRENT_SOURCE_DIR}/${inputFile}
+-DoutHeaderFile=${CMAKE_CURRENT_BINARY_DIR}/${outHeaderFile}
+-DoutCppFile=${CMAKE_CURRENT_BINARY_DIR}/${outCppFile}
-P ${CMAKE_MODULE_PATH}/TokenList2DsnLexer.cmake
COMMENT "TokenList2DsnLexer.cmake creating:
${outHeaderFile} and
${outCppFile} from
${inputFile}"
-DEPENDS ${inputFile}
-)
-
-add_custom_target( ${outputTarget}
-DEPENDS ${outHeaderFile} ${outCppFile}
+DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/${inputFile}
${CMAKE_MODULE_PATH}/TokenList2DsnLexer.cmake
)
-set_property( GLOBAL PROPERTY ADDITIONAL_MAKE_CLEAN_FILES ${outHeaderFile} ${outCppFile} )
-
-# extra_args, if any, are treated as source files (typically headers) which
-# are known to depend on the generated outHeader.
-foreach( extra_arg ${ARGN} )
-set_source_files_properties( ${extra_arg}
-PROPERTIES OBJECT_DEPENDS ${outHeaderFile}
-)
-endforeach()
+target_sources( ${outputTarget} PRIVATE ${CMAKE_CURRENT_BINARY_DIR}/${outCppFile} )
+target_include_directories( ${outputTarget} PUBLIC ${CMAKE_CURRENT_BINARY_DIR} )
endfunction()
diff --git a/CMakeModules/TokenList2DsnLexer.cmake b/CMakeModules/TokenList2DsnLexer.cmake
index 589ac0c49..8c325e047 100644
--- a/CMakeModules/TokenList2DsnLexer.cmake
+++ b/CMakeModules/TokenList2DsnLexer.cmake
@@ -150,7 +150,7 @@ set( sourceFileHeader
* your DSN lexer.
*/
-#include <${result}_lexer.h>
+#include <${outHeaderFile}>
using namespace ${enum};
diff --git a/common/CMakeLists.txt b/common/CMakeLists.txt
index 2f675467d..10fb73af4 100644
--- a/common/CMakeLists.txt
+++ b/common/CMakeLists.txt
@@ -220,7 +220,6 @@ set( COMMON_PAGE_LAYOUT_SRCS
page_layout/ws_draw_item.cpp
page_layout/ws_proxy_undo_item.cpp
page_layout/ws_proxy_view_item.cpp
-page_layout/page_layout_reader_keywords.cpp
page_layout/page_layout_reader.cpp
)
@@ -312,14 +311,12 @@ set( COMMON_SRCS
languages_menu.cpp
lib_id.cpp
lib_table_base.cpp
-lib_table_keywords.cpp
lib_tree_model.cpp
lib_tree_model_adapter.cpp
lockfile.cpp
marker_base.cpp
md5_hash.cpp
msgpanel.cpp
-netlist_keywords.cpp
observable.cpp
prependpath.cpp
printout.cpp
@@ -427,8 +424,6 @@ set( PCB_COMMON_SRCS
lset.cpp
origin_viewitem.cpp
page_info.cpp
-pcb_keywords.cpp
-pcb_plot_params_keywords.cpp
../pcbnew/pcb_base_frame.cpp
../pcbnew/board_commit.cpp
../pcbnew/board_connected_item.cpp
@@ -502,78 +497,50 @@ target_link_libraries( pcbcommon PUBLIC
# auto-generate netlist_lexer.h and netlist_keywords.cpp
make_lexer(
-netlist_lexer_source_files
[Kicad-developers] [PATCH 0/1] Possible fix for lexer generator dependency ordering
Hi, this might fix the lexer problems. Please test extensively. Simon Simon Richter (1): Fix build order for generated headers and sources CMakeModules/Functions.cmake | 27 CMakeModules/TokenList2DsnLexer.cmake | 2 +- common/CMakeLists.txt | 73 +-- common/page_layout/page_layout_reader.cpp | 2 +- common/page_layout/ws_data_model_io.cpp | 2 +- eeschema/CMakeLists.txt | 47 eeschema/dialogs/dialog_bom.cpp | 2 +- new/CMakeLists.txt| 26 +-- pcb_calculator/CMakeLists.txt | 14 ++ pcbnew/CMakeLists.txt | 27 pcbnew/specctra_import_export/specctra.h | 2 +- qa/eeschema/CMakeLists.txt| 5 +-- 12 files changed, 79 insertions(+), 150 deletions(-) -- 2.11.0 ___ Mailing list: https://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] Bug #1752298: Clean up sorting functions for mixed text and numbers
Hi Pradeepa, We already have a string comparison function that handles this. Take a look at StrNumCmp()[1] in common/string.cpp[2]. We use this function in many places for mixed text and number comparisons so I see no reason not to use it in this case unless there is a bug in StrNumCmp(). Cheers, Wayne [1]: http://docs.kicad-pcb.org/doxygen/kicad__string_8h.html#a76901fb3f83511f8fbc2d60df2213b6c [2]: https://git.launchpad.net/kicad/tree/common/string.cpp On 6/30/2019 2:05 AM, Pradeepa Senanayake wrote: > Hello All, > > I started working on the bug #1752298 and I would like to get an > understanding on the requirements. I feel that this is not a bug, rather > it is a requirement to have a unified function for sorting. > > There can be many requirements for sorting in KiCAD. Therefore, before > jumping into implementation, I'd like to ask what requirements we are after. > > One sorting mechanism can look like below. > > A0, A1, A2, , B0, B1, B2 C1, C2, C3, ... , AA1, AA2, ..., AB0, > AB1, ... etc > > This can possibly be used for pin sorting (PA0, PA1, etc.) and component > sorting. (J1, J2, U1, U2, etc.) > > Also, where do we usually store utility functions? Is there a particular > namespace? > > Thanks! > Best Regards, > Pradeepa Senanayake. > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Bug 1834718
Nope :( #41640 0x6d26fb1d in ?? () from E:\msys64\mingw64\bin\wxmsw30u_core_gcc_custom.dll #41641 0x806e86f7 in WX_PROGRESS_REPORTER::~WX_PROGRESS_REPORTER ( this=0x1288fae0, __in_chrg=) at E:/msys64/home/Wayne/src/kicad-5.1/common/widgets/progress_reporter.cpp:117 #41642 0x806e8735 in WX_PROGRESS_REPORTER::~WX_PROGRESS_REPORTER ( this=0x1288fae0, __in_chrg=) at E:/msys64/home/Wayne/src/kicad-5.1/common/widgets/progress_reporter.cpp:118 #41643 0x809da748 in std::default_delete::operator() (this=0x15177128, __ptr=0x1288fae0) at E:/msys64/mingw64/include/c++/9.1.0/bits/unique_ptr.h:81 #41644 0x80a24404 in std::unique_ptr >::~unique_ptr (this=0x15177128, __in_chrg=) at E:/msys64/mingw64/include/c++/9.1.0/bits/unique_ptr.h:289 #41645 0x802e4adf in ZONE_FILLER_TOOL::ZoneFill (this=0x1473b6b0, aEvent=...) at E:/msys64/home/Wayne/src/kicad-5.1/pcbnew/tools/zone_filler_tool.cpp:104 #41646 0x80bc7baf in std::__invoke_impl (__f= @0x128902a0: (int (ZONE_FILLER_TOOL::*)(class ZONE_FILLER_TOOL * const, const class TOOL_EVENT &)) 0x802e4888 , __t=@0x128902b0: 0x1473b6b0, __args#0=...) at E:/msys64/mingw64/include/c++/9.1.0/bits/invoke.h:73 #41647 0x80c17783 in std::__invoke (__fn= @0x128902a0: (int (ZONE_FILLER_TOOL::*)(class ZONE_FILLER_TOOL * const, const class TOOL_EVENT &)) 0x802e4888 , __args#0=@0x128902b0: 0x1473b6b0, __args#1=...) at E:/msys64/mingw64/include/c++/9.1.0/bits/invoke.h:95 #41648 0x80ab5b7b in std::_Bind))(TOOL_EVENT const&)>::__call(std::tuple&&, std::_Index_tuple<0ull, 1ull>) ( this=0x128902a0, __args=...) at E:/msys64/mingw64/include/c++/9.1.0/functional:400 #41649 0x80ab5ca4 in std::_Bind))(TOOL_EVENT const&)>::operator()(TOOL_EVENT const&) (this=0x128902a0, __args#0=...) at E:/msys64/mingw64/include/c++/9.1.0/functional:484 #41650 0x80a90219 in std::_Function_handler))(TOOL_EVENT const&)> >::_M_invoke(std::_Any_data const&, TOOL_EVENT const&) ( __functor=..., __args#0=...) at E:/msys64/mingw64/include/c++/9.1.0/bits/std_function.h:285 #41651 0x80a01b4b in std::function::operator()(TOOL_EVENT const&) const (this=0x14793998, __args#0=...) at E:/msys64/mingw64/include/c++/9.1.0/bits/std_function.h:690 #41652 0x809591ba in COROUTINE::callerStub ( aData=351771072) at E:/msys64/home/Wayne/src/kicad-5.1/include/tool/coroutine.h:331 #41653 0x807b8efa in make_fcontext () from E:\msys64\mingw64\bin\_pcbnew.kiface #41654 0x14f799c0 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) On 7/1/2019 8:35 AM, Seth Hillbrand wrote: > Hi Wayne- > > Thanks for testing. If you have a chance, can you give the attached > patch a spin? This is in place of the previous attempt. > > Best- > Seth > > On 2019-07-01 07:51, Wayne Stambaugh wrote: >> Hey Seth, >> >> No bueno. Here is the back trace using your patch. >> >> Cheers, >> >> Wayne >> >> #41640 0x6d26fb1d in ?? () >> from E:\msys64\mingw64\bin\wxmsw30u_core_gcc_custom.dll >> #41641 0x806e8747 in >> WX_PROGRESS_REPORTER::~WX_PROGRESS_REPORTER ( >> this=0x12884860, __in_chrg=) >> at >> E:/msys64/home/Wayne/src/kicad-5.1/common/widgets/progress_reporter.cpp:117 >> >> #41642 0x806e8785 in >> WX_PROGRESS_REPORTER::~WX_PROGRESS_REPORTER ( >> this=0x12884860, __in_chrg=) >> at >> E:/msys64/home/Wayne/src/kicad-5.1/common/widgets/progress_reporter.cpp:118 >> >> #41643 0x809da798 in >> std::default_delete::operator() (this=0x1539f138, >> __ptr=0x12884860) >> at E:/msys64/mingw64/include/c++/9.1.0/bits/unique_ptr.h:81 >> #41644 0x80a24454 in std::unique_ptr> std::default_delete >::~unique_ptr >> (this=0x1539f138, >> __in_chrg=) >> at E:/msys64/mingw64/include/c++/9.1.0/bits/unique_ptr.h:289 >> #41645 0x802e4b26 in ZONE_FILLER_TOOL::ZoneFill (this=0x14338300, >> aEvent=...) >> at >> E:/msys64/home/Wayne/src/kicad-5.1/pcbnew/tools/zone_filler_tool.cpp:103 >> #41646 0x80bc7b4f in std::__invoke_impl> (ZONE_FILLER_TOOL::*&)(TOOL_EVENT const&), ZONE_FILLER_TOOL*&, >> TOOL_EVENT const&> (__f= >> @0x182d4800: (int (ZONE_FILLER_TOOL::*)(class ZONE_FILLER_TOOL * >> const, const class TOOL_EVENT &)) 0x802e4888 >> , __t=@0x182d4810: >> 0x14338300, __args#0=...) >> at E:/msys64/mingw64/include/c++/9.1.0/bits/invoke.h:73 >> #41647 0x80c17723 in std::__invoke> (ZONE_FILLER_TOOL::*&)(TOOL_EVENT const&), ZONE_FILLER_TOOL*&, >> TOOL_EVENT const&> (__fn= >> @0x182d4800: (int (ZONE_FILLER_TOOL::*)(class ZONE_FILLER_TOOL * >> const, const class TOOL_EVENT &)) 0x802e4888 >> , __args#0=@0x182d4810: >> 0x14338300, __args#1=...) >> at E:/msys64/mingw64/include/c++/9.1.0/bits/invoke.h:95 >> #41648 0x80ab5bcb in std::_Bind> (ZONE_FILLER_TOOL::*(ZONE_FILLER_TOOL*, >> std::_Placeholder<1>))(TOOL_EVENT const&)>::__call> const&, 0ull, 1ull
Re: [Kicad-developers] Bug #1752298: Clean up sorting functions for mixed text and numbers
On 2019-06-30 02:05, Pradeepa Senanayake wrote:
Hello All,
I started working on the bug #1752298 and I would like to get an
understanding on the requirements. I feel that this is not a bug,
rather it is a requirement to have a unified function for sorting.
There can be many requirements for sorting in KiCAD. Therefore, before
jumping into implementation, I'd like to ask what requirements we are
after.
Hi Pradeepa-
You might get faster responses in the bug report. It's sometimes
helpful to keep the discussion archived there for future reference.
This report looks like a clean-up job. I think implementations exist
for each requirement scattered through the codebase. The bug asks that
these are centralized (and, I would add, it would be extremely useful
for test cases to be added to our unit test framework under 'qa').
Generally, I would suggest that these live in the UTIL namespace. We
have a cmp implementation there already in common/refdes_utils.cpp. It
might not hit all requirements though so it would be good to
check/verify. There are also some functions in common/string.{h,cpp}.
Then there are the various ones scattered through the code.
We probably can't unify every one of them. But there's likely
substantial overlap. Even the ones that can't be unified should live in
the same file or namespace so that we can unit test them. A couple are
listed in the bug report but the rest will be found by grepping.
Best-
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
Re: [Kicad-developers] Bug 1834718
Hi Wayne- Thanks for testing. If you have a chance, can you give the attached patch a spin? This is in place of the previous attempt. Best- Seth On 2019-07-01 07:51, Wayne Stambaugh wrote: Hey Seth, No bueno. Here is the back trace using your patch. Cheers, Wayne #41640 0x6d26fb1d in ?? () from E:\msys64\mingw64\bin\wxmsw30u_core_gcc_custom.dll #41641 0x806e8747 in WX_PROGRESS_REPORTER::~WX_PROGRESS_REPORTER ( this=0x12884860, __in_chrg=) at E:/msys64/home/Wayne/src/kicad-5.1/common/widgets/progress_reporter.cpp:117 #41642 0x806e8785 in WX_PROGRESS_REPORTER::~WX_PROGRESS_REPORTER ( this=0x12884860, __in_chrg=) at E:/msys64/home/Wayne/src/kicad-5.1/common/widgets/progress_reporter.cpp:118 #41643 0x809da798 in std::default_delete::operator() (this=0x1539f138, __ptr=0x12884860) at E:/msys64/mingw64/include/c++/9.1.0/bits/unique_ptr.h:81 #41644 0x80a24454 in std::unique_ptrstd::default_delete >::~unique_ptr (this=0x1539f138, __in_chrg=) at E:/msys64/mingw64/include/c++/9.1.0/bits/unique_ptr.h:289 #41645 0x802e4b26 in ZONE_FILLER_TOOL::ZoneFill (this=0x14338300, aEvent=...) at E:/msys64/home/Wayne/src/kicad-5.1/pcbnew/tools/zone_filler_tool.cpp:103 #41646 0x80bc7b4f in std::__invoke_impl (__f= @0x182d4800: (int (ZONE_FILLER_TOOL::*)(class ZONE_FILLER_TOOL * const, const class TOOL_EVENT &)) 0x802e4888 , __t=@0x182d4810: 0x14338300, __args#0=...) at E:/msys64/mingw64/include/c++/9.1.0/bits/invoke.h:73 #41647 0x80c17723 in std::__invoke (__fn= @0x182d4800: (int (ZONE_FILLER_TOOL::*)(class ZONE_FILLER_TOOL * const, const class TOOL_EVENT &)) 0x802e4888 , __args#0=@0x182d4810: 0x14338300, __args#1=...) at E:/msys64/mingw64/include/c++/9.1.0/bits/invoke.h:95 #41648 0x80ab5bcb in std::_Bind))(TOOL_EVENT const&)>::__call(std::tuple&&, std::_Index_tuple<0ull, 1ull>) ( this=0x182d4800, __args=...) at E:/msys64/mingw64/include/c++/9.1.0/functional:400 #41649 0x80ab5cf4 in std::_Bind))(TOOL_EVENT const&)>::operator()(TOOL_EVENT const&) (this=0x182d4800, __args#0=...) at E:/msys64/mingw64/include/c++/9.1.0/functional:484 #41650 0x80a90269 in std::_Function_handler))(TOOL_EVENT const&)> >::_M_invoke(std::_Any_data const&, TOOL_EVENT const&) ( __functor=..., __args#0=...) at E:/msys64/mingw64/include/c++/9.1.0/bits/std_function.h:285 #41651 0x80a01b9b in std::function::operator()(TOOL_EVENT const&) const (this=0x182d2db8, __args#0=...) at E:/msys64/mingw64/include/c++/9.1.0/bits/std_function.h:690 #41652 0x8095920a in COROUTINEconst&>::callerStub ( aData=354023872) at E:/msys64/home/Wayne/src/kicad-5.1/include/tool/coroutine.h:331 #41653 0x807b8f4a in make_fcontext () from E:\msys64\mingw64\bin\_pcbnew.kiface #41654 0x1519f9c0 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) On 6/29/2019 3:17 PM, Seth Hillbrand wrote: Hi Wayne- That actually helps a lot. It also explains why this is MSW-only behavior. I'm attaching a patch that should address this. Let me know if it doesn't help. Best- Seth On 2019-06-29 11:48, Wayne Stambaugh wrote: Seth, I managed to let the gdb back trace finish. It took a while but here is the last of the stack up to the last progress dialog dtor iteration. I'm not sure how much good it's going to do. It looks like there was a context switch or something that corrupted the previous stack frame so any useful information in that stack frame is lost :( Wayne #83262 0x6d26fb1d in ?? () from E:\msys64\mingw64\bin\wxmsw30u_core_gcc_custom.dll #83263 0x806e8547 in WX_PROGRESS_REPORTER::~WX_PROGRESS_REPORTER ( this=0x1751aca0, __in_chrg=) at E:/msys64/home/Wayne/src/kicad-5.1/common/widgets/progress_reporter.cpp:117 #83264 0x802d2d88 in POINT_EDITOR::finishItem (this=0x12a8a3a0) at E:/msys64/home/Wayne/src/kicad-5.1/pcbnew/tools/point_editor.cpp:650 #83265 0x802d15a0 in POINT_EDITOR::OnSelectionChange ( this=0x12a8a3a0, aEvent=...) at E:/msys64/home/Wayne/src/kicad-5.1/pcbnew/tools/point_editor.cpp:427 #83266 0x80bc764f in std::__invoke_impl (__f= @0x190138a0: (int (POINT_EDITOR::*)(class POINT_EDITOR * const, const class TOOL_EVENT &)) 0x802d0b22 , __t=@0x190138b0: 0x12a8a3a0, __args#0=...) at E:/msys64/mingw64/include/c++/9.1.0/bits/invoke.h:73 #83267 0x80c172b3 in std::__invoke (__fn= @0x190138a0: (int (POINT_EDITOR::*)(class POINT_EDITOR * const, const class TOOL_EVENT &)) 0x802d0b22 , __args#0=@0x190138b0: 0x12a8a3a0, __args#1=...) at E:/msys64/mingw64/include/c++/9.1.0/bits/invoke.h:95 #83268 0x80ab4fcb in std::_Bind))(TOOL_EVENT const&)>::__call1ull>(std::tuple&&, std::_Index_tuple<0ull, 1ull>) ( this=0x190138a0, __args=...) at E:/msys64/mingw64/include/c++/9.1.0/functional:400 #83269 0x80ab50f4 in std::_Bind
Re: [Kicad-developers] [PATCH 9/9] Define compiler flags for MSVC
Hi, > +if( USE_WX_OVERLAY OR APPLE ) > +add_definitions( -DUSE_WX_OVERLAY ) > +endif() > + That is a merge error, I'll remove that. 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
[Kicad-developers] [PATCH 4/9] Turn off compiler extensions
We want to be somewhat standards compliant if we can.
There is a small complication, which we work around:
gcc sets __STRICT_ANSI__ in "c++11" mode (the non-strict mode would be
"gnu++11"), which causes the "strdup" definition to go away. If wx < 3.1 is
compiled with GNU extensions, it just forwards the wxCRT strdup function to
system strdup and doesn't create a definition for the wxCRT function, and
when a program is then compiled in strict mode against that, the wxCRT
function is missing.
>From 3.1 onwards, the function is provided unconditionally in wx, so the
workaround is no longer needed there.
---
CMakeLists.txt | 7 +++
1 file changed, 7 insertions(+)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index c73c86a29..676733664 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -142,6 +142,7 @@ set( CMAKE_POSITION_INDEPENDENT_CODE ON )
# Global setting: Use C++11
set(CMAKE_CXX_STANDARD 11)
+set(CMAKE_CXX_EXTENSIONS OFF)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
@@ -788,6 +789,12 @@ if( KICAD_SCRIPTING_WXPYTHON AND NOT KICAD_SCRIPTING_WXPYTHON_PHOENIX )
endif()
endif()
+if( MINGW AND ( ${wxWidgets_VERSION_STRING} VERSION_LESS 3.1 ) )
+# Work around a bug in wx < 3.1 -- when wx itself is compiled with
+# compiler extensions enabled, it assumes these are also available for
+# applications.
+add_definitions( -U__STRICT_ANSI__ )
+endif()
if( APPLE )
# Remove app bundles in ${KICAD_BIN} before installing anything new.
___
Mailing list: https://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] [PATCH 1/9] pcbnew: can't return a copy of ptr_vector if items are polymorphic and have no clone() methods. Work it around.
---
pcbnew/pcb_edit_frame.h | 3 ++-
pcbnew/pcbnew_config.cpp | 12 ++--
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/pcbnew/pcb_edit_frame.h b/pcbnew/pcb_edit_frame.h
index 705f5f7f4..dadb6cba0 100644
--- a/pcbnew/pcb_edit_frame.h
+++ b/pcbnew/pcb_edit_frame.h
@@ -93,6 +93,7 @@ protected:
PCB_LAYER_WIDGET* m_Layers;
PARAM_CFG_ARRAY m_configParams; ///< List of Pcbnew configuration settings.
+PARAM_CFG_ARRAY m_projectFileParams;
wxString m_lastNetListRead;///< Last net list read with relative path.
@@ -379,7 +380,7 @@ public:
* @return PARAM_CFG_ARRAY - it is only good until SetBoard() is called, so
* don't keep it around past that event.
*/
-PARAM_CFG_ARRAY GetProjectFileParameters();
+PARAM_CFG_ARRAY& GetProjectFileParameters();
/**
* Function SaveProjectSettings
diff --git a/pcbnew/pcbnew_config.cpp b/pcbnew/pcbnew_config.cpp
index ff1cb5742..8b577538e 100644
--- a/pcbnew/pcbnew_config.cpp
+++ b/pcbnew/pcbnew_config.cpp
@@ -125,21 +125,21 @@ void PCB_EDIT_FRAME::SaveProjectSettings( bool aAskForSave )
}
-PARAM_CFG_ARRAY PCB_EDIT_FRAME::GetProjectFileParameters()
+PARAM_CFG_ARRAY& PCB_EDIT_FRAME::GetProjectFileParameters()
{
-PARAM_CFG_ARRAY pca;
+m_projectFileParams.clear();
// This one cannot be cached because some settings are going to/from the BOARD,
// so pointers into that cannot be saved for long.
-pca.push_back( new PARAM_CFG_FILENAME( wxT( "PageLayoutDescrFile" ),
+m_projectFileParams.push_back( new PARAM_CFG_FILENAME( wxT( "PageLayoutDescrFile" ),
&BASE_SCREEN::m_PageLayoutDescrFileName ) );
-pca.push_back( new PARAM_CFG_FILENAME( wxT( "LastNetListRead" ), &m_lastNetListRead ) );
+m_projectFileParams.push_back( new PARAM_CFG_FILENAME( wxT( "LastNetListRead" ), &m_lastNetListRead ) );
-GetBoard()->GetDesignSettings().AppendConfigs( GetBoard(), &pca );
+GetBoard()->GetDesignSettings().AppendConfigs( GetBoard(), &m_projectFileParams);
-return pca;
+return m_projectFileParams;
}
___
Mailing list: https://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] [PATCH 3/9] Set _USE_MATH_DEFINES on Windows
All compilers need this in standards-compliant mode. --- CMakeLists.txt | 4 1 file changed, 4 insertions(+) diff --git a/CMakeLists.txt b/CMakeLists.txt index ee43d9eb9..c73c86a29 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -245,6 +245,10 @@ if( WIN32 ) # define UNICODE and_UNICODE definition on Windows. KiCad uses unicode. # Both definitions are required add_definitions(-DUNICODE -D_UNICODE) + +# In fully standards-compliant mode, M_PI et al. are defined only if +# _USE_MATH_DEFINES is set. +add_definitions( -D_USE_MATH_DEFINES ) endif() ___ Mailing list: https://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] [PATCH 6/9] Work around missing min/max in Windows headers
Windows headers assume min/max to be macros, but we set NOMINMAX to hide the macro definitions. This pulls in an alternative implementation. --- common/gal/cairo/cairo_print.cpp | 6 ++ 1 file changed, 6 insertions(+) diff --git a/common/gal/cairo/cairo_print.cpp b/common/gal/cairo/cairo_print.cpp index 0204c6970..6cef33e9b 100644 --- a/common/gal/cairo/cairo_print.cpp +++ b/common/gal/cairo/cairo_print.cpp @@ -25,6 +25,12 @@ #include #include +#ifdef NOMINMAX /* workaround for gdiplus.h */ +#include +using std::min; +using std::max; +#endif + #ifdef __WXMSW__ #include #include ___ Mailing list: https://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] [PATCH 9/9] Define compiler flags for MSVC
Defines:
- inhibit generation of #pragma comment(lib, ...) from boost
- inhibit warnings about "unsafe" containers
- inhibit warnings about "unsafe" C functions
- inhibit warnings about "deprecated" POSIX functions
- ask for macros from math.h
- suppress min/max macros from windows.h
Flags:
- suppress warnings about throw() not being fully supported in the compiler
- suppress warnings about values being explicitly cast to bool
- enable string pooling
- enable unreferenced code removal
- enable COMDAT folding
- generate PDB debug information
In addition, remove one explicit define that is now covered by the compiler
flags.
---
CMakeLists.txt | 38 ++
1 file changed, 38 insertions(+)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 676733664..7cbaecd5b 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -108,6 +108,10 @@ option( KICAD_SPICE
"Build KiCad with internal Spice simulator."
ON )
+option( KICAD_BUILD_PARALLEL_CL_MP
+"Build in parallel using the /MP compiler option (default OFF for safety reasons)"
+OFF )
+
# when option KICAD_SCRIPTING OR KICAD_SCRIPTING_MODULES is enabled:
# PYTHON_EXECUTABLE can be defined when invoking cmake
# ( use -DPYTHON_EXECUTABLE=/python.exe or python2 )
@@ -362,6 +366,40 @@ if( CMAKE_COMPILER_IS_GNUCXX OR CMAKE_CXX_COMPILER_ID MATCHES "Clang" )
endif( CMAKE_COMPILER_IS_GNUCXX OR CMAKE_CXX_COMPILER_ID MATCHES "Clang" )
+if( MSVC )
+# Disallow implicit linking for Boost
+add_definitions( -DBOOST_ALL_NO_LIB )
+# Disable MSVC's deprecation warnings
+add_definitions( -D_CRT_SECURE_NO_WARNINGS -D_CRT_NONSTDC_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS )
+# Hide Windows's min() and max() macros
+add_definitions( -DNOMINMAX )
+# C4290: throw() is interpreted as declspec(nothrow)
+string( APPEND CMAKE_CXX_FLAGS " /wd4290" )
+# C4800: non-bool is explicitly cast to bool, forcing value of 0 or 1
+string( APPEND CMAKE_CXX_FLAGS " /wd4800" )
+# /Zi: create PDB
+string( APPEND CMAKE_CXX_FLAGS " /Zi" )
+# /GF: enable string pooling
+string( APPEND CMAKE_CXX_FLAGS_RELEASE " /GF" )
+foreach( type EXE SHARED MODULE)
+# /DEBUG: create PDB
+string( APPEND CMAKE_${type}_LINKER_FLAGS " /DEBUG" )
+# /OPT:REF: omit unreferenced code
+string( APPEND CMAKE_${type}_LINKER_FLAGS_RELEASE " /OPT:REF" )
+# /OPT:ICF: fold common data
+string( APPEND CMAKE_${type}_LINKER_FLAGS_RELEASE " /OPT:ICF" )
+endforeach()
+
+# Let cl.exe parallelize builds
+if( KICAD_BUILD_PARALLEL_CL_MP )
+string( APPEND CMAKE_CXX_FLAGS " /MP" )
+endif()
+endif()
+
+if( USE_WX_OVERLAY OR APPLE )
+add_definitions( -DUSE_WX_OVERLAY )
+endif()
+
if( KICAD_SCRIPTING )
add_definitions( -DKICAD_SCRIPTING )
endif()
___
Mailing list: https://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] [PATCH 5/9] Remove own copy of FindOpenSSL.cmake
---
CMakeModules/FindOpenSSL.cmake | 342 -
1 file changed, 342 deletions(-)
delete mode 100644 CMakeModules/FindOpenSSL.cmake
diff --git a/CMakeModules/FindOpenSSL.cmake b/CMakeModules/FindOpenSSL.cmake
deleted file mode 100644
index de91787c1..0
--- a/CMakeModules/FindOpenSSL.cmake
+++ /dev/null
@@ -1,342 +0,0 @@
-#.rst:
-# FindOpenSSL
-# ---
-#
-# Try to find the OpenSSL encryption library
-#
-# Once done this will define
-#
-# ::
-#
-# OPENSSL_ROOT_DIR - Set this variable to the root installation of OpenSSL
-#
-#
-#
-# Read-Only variables:
-#
-# ::
-#
-# OPENSSL_FOUND - system has the OpenSSL library
-# OPENSSL_INCLUDE_DIR - the OpenSSL include directory
-# OPENSSL_LIBRARIES - The libraries needed to use OpenSSL
-# OPENSSL_VERSION - This is set to $major.$minor.$revision$path (eg. 0.9.8s)
-
-#=
-# Copyright 2006-2009 Kitware, Inc.
-# Copyright 2006 Alexander Neundorf
-# Copyright 2009-2011 Mathieu Malaterre
-#
-# Distributed under the OSI-approved BSD License (the "License");
-# see accompanying file Copyright.txt for details.
-#
-# This software is distributed WITHOUT ANY WARRANTY; without even the
-# implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
-# See the License for more information.
-#=
-# (To distribute this file outside of CMake, substitute the full
-# License text for the above reference.)
-
-if (UNIX)
- find_package(PkgConfig QUIET)
- pkg_check_modules(_OPENSSL QUIET openssl)
-endif ()
-
-if (WIN32)
- # http://www.slproweb.com/products/Win32OpenSSL.html
- set(_OPENSSL_ROOT_HINTS
-${OPENSSL_ROOT_DIR}
-"[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\OpenSSL (32-bit)_is1;Inno Setup: App Path]"
-"[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\OpenSSL (64-bit)_is1;Inno Setup: App Path]"
-ENV OPENSSL_ROOT_DIR
-)
- file(TO_CMAKE_PATH "$ENV{PROGRAMFILES}" _programfiles)
- set(_OPENSSL_ROOT_PATHS
-"${_programfiles}/OpenSSL"
-"${_programfiles}/OpenSSL-Win32"
-"${_programfiles}/OpenSSL-Win64"
-"C:/OpenSSL/"
-"C:/OpenSSL-Win32/"
-"C:/OpenSSL-Win64/"
-)
- unset(_programfiles)
-else ()
- set(_OPENSSL_ROOT_HINTS
-${OPENSSL_ROOT_DIR}
-ENV OPENSSL_ROOT_DIR
-)
-endif ()
-
-set(_OPENSSL_ROOT_HINTS_AND_PATHS
-HINTS ${_OPENSSL_ROOT_HINTS}
-PATHS ${_OPENSSL_ROOT_PATHS}
-)
-
-find_path(OPENSSL_INCLUDE_DIR
- NAMES
-openssl/ssl.h
-${_OPENSSL_ROOT_HINTS_AND_PATHS}
- HINTS
-${_OPENSSL_INCLUDEDIR}
- PATH_SUFFIXES
-include
-)
-
-if(WIN32 AND NOT CYGWIN)
- if(MSVC)
-# /MD and /MDd are the standard values - if someone wants to use
-# others, the libnames have to change here too
-# use also ssl and ssleay32 in debug as fallback for openssl < 0.9.8b
-# TODO: handle /MT and static lib
-# In Visual C++ naming convention each of these four kinds of Windows libraries has it's standard suffix:
-# * MD for dynamic-release
-# * MDd for dynamic-debug
-# * MT for static-release
-# * MTd for static-debug
-
-# Implementation details:
-# We are using the libraries located in the VC subdir instead of the parent directory eventhough :
-# libeay32MD.lib is identical to ../libeay32.lib, and
-# ssleay32MD.lib is identical to ../ssleay32.lib
-find_library(LIB_EAY_DEBUG
- NAMES
-libeay32MDd
-libeay32d
-${_OPENSSL_ROOT_HINTS_AND_PATHS}
- PATH_SUFFIXES
-"lib"
-"VC"
-"lib/VC"
-)
-
-find_library(LIB_EAY_RELEASE
- NAMES
-libeay32MD
-libeay32
-${_OPENSSL_ROOT_HINTS_AND_PATHS}
- PATH_SUFFIXES
-"lib"
-"VC"
-"lib/VC"
-)
-
-find_library(SSL_EAY_DEBUG
- NAMES
-ssleay32MDd
-ssleay32d
-${_OPENSSL_ROOT_HINTS_AND_PATHS}
- PATH_SUFFIXES
-"lib"
-"VC"
-"lib/VC"
-)
-
-find_library(SSL_EAY_RELEASE
- NAMES
-ssleay32MD
-ssleay32
-ssl
-${_OPENSSL_ROOT_HINTS_AND_PATHS}
- PATH_SUFFIXES
-"lib"
-"VC"
-"lib/VC"
-)
-
-set(LIB_EAY_LIBRARY_DEBUG "${LIB_EAY_DEBUG}")
-set(LIB_EAY_LIBRARY_RELEASE "${LIB_EAY_RELEASE}")
-set(SSL_EAY_LIBRARY_DEBUG "${SSL_EAY_DEBUG}")
-set(SSL_EAY_LIBRARY_RELEASE "${SSL_EAY_RELEASE}")
-
-include(${CMAKE_CURRENT_LIST_DIR}/SelectLibraryConfigurations.cmake)
-select_library_configurations(LIB_EAY)
-select_library_configurations(SSL_EAY)
-
-mark_as_advanced(LIB_EAY_LIBRARY_DEBUG LIB_EAY_LIBRARY_RELEASE
- SSL_EAY_LIBRARY_DEBUG SSL_EAY_LIBRARY_RELEASE)
-set( OPENSSL_LIBRARIES ${SSL_EAY_LIBRARY} ${LIB_EAY_LIBRARY} )
- elseif(MINGW)
-message( STATUS "Searching for O
[Kicad-developers] [PATCH 7/9] MSVC support for libcontext
This uses the Windows native Fiber API.
---
common/system/libcontext.cpp | 66
include/system/libcontext.h | 16 ++-
include/tool/coroutine.h | 8 --
3 files changed, 87 insertions(+), 3 deletions(-)
diff --git a/common/system/libcontext.cpp b/common/system/libcontext.cpp
index f6f83ceae..57478f12c 100644
--- a/common/system/libcontext.cpp
+++ b/common/system/libcontext.cpp
@@ -13,6 +13,8 @@
http://www.boost.org/LICENSE_1_0.txt)
*/
+#include
+#include
#include
#if defined(LIBCONTEXT_PLATFORM_windows_i386) && defined(LIBCONTEXT_COMPILER_gcc)
@@ -1268,3 +1270,67 @@ __asm (
);
#endif
+
+#if defined(LIBCONTEXT_PLATFORM_msvc_x86_64) || defined(LIBCONTEXT_PLATFORM_msvc_i386)
+
+#include
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include
+
+namespace libcontext
+{
+
+static int threadHasFibers = 0;
+
+struct FiberData
+{
+ intptr_t inValue;
+ intptr_t outValue;
+ void(*entry)(intptr_t);
+};
+
+static std::map fiberParams;
+
+static void fiberEntry(LPVOID params)
+{
+ auto ctx = (fcontext_t) GetCurrentFiber();
+ auto& d = fiberParams[ctx];
+ d.entry(d.inValue);
+}
+
+fcontext_t LIBCONTEXT_CALL_CONVENTION make_fcontext(void* sp, size_t size, void(*fn)(intptr_t))
+{
+ if (!threadHasFibers)
+ {
+ ConvertThreadToFiber(nullptr);
+ threadHasFibers = 1;
+ }
+
+ fcontext_t ctx = CreateFiber(size, (LPFIBER_START_ROUTINE) fiberEntry, nullptr );
+ fiberParams[ctx].entry = fn;
+
+ return ctx;
+}
+
+intptr_t LIBCONTEXT_CALL_CONVENTION jump_fcontext(fcontext_t* ofc, fcontext_t nfc,
+ intptr_t vp, bool preserve_fpu)
+{
+ auto current = (void*)GetCurrentFiber();
+ fiberParams[current].outValue = vp;
+ *ofc = GetCurrentFiber();
+ fiberParams[nfc].inValue = vp;
+ SwitchToFiber(nfc);
+ return fiberParams[*ofc].outValue;
+}
+
+}; // namespace libcontext
+
+#ifdef __cplusplus
+};
+#endif
+
+#endif
diff --git a/include/system/libcontext.h b/include/system/libcontext.h
index 8045fa2b7..dfa323dcd 100644
--- a/include/system/libcontext.h
+++ b/include/system/libcontext.h
@@ -24,6 +24,8 @@
#if defined(__GNUC__) || defined(__APPLE__) || defined(__FreeBSD__)
+#undef LIBCONTEXT_HAS_OWN_STACK
+
#define LIBCONTEXT_COMPILER_gcc
#if defined(__linux__) || defined(__FreeBSD__)
@@ -46,7 +48,8 @@
#ifdef _ARCH_PPC64
#define LIBCONTEXT_PLATFORM_linux_ppc64
#define LIBCONTEXT_CALL_CONVENTION
-#elif defined _ARCH_PPC
+#endif
+#ifdef _ARCH_PPC
#define LIBCONTEXT_PLATFORM_linux_ppc32
#define LIBCONTEXT_CALL_CONVENTION
#endif
@@ -73,6 +76,17 @@
#define LIBCONTEXT_CALL_CONVENTION
#endif
#endif
+#elif defined (_MSC_VER)
+
+#define LIBCONTEXT_HAS_OWN_STACK
+
+#define LIBCONTEXT_CALL_CONVENTION __cdecl
+
+#if defined(_WIN64)
+ #define LIBCONTEXT_PLATFORM_msvc_x86_64
+#elif defined(_WIN32)
+ #define LIBCONTEXT_PLATFORM_msvc_i386
+#endif
#endif
#ifdef __cplusplus
diff --git a/include/tool/coroutine.h b/include/tool/coroutine.h
index 7be173adb..60144ebc0 100644
--- a/include/tool/coroutine.h
+++ b/include/tool/coroutine.h
@@ -294,15 +294,19 @@ private:
assert( m_stack == nullptr );
-// fixme: Clean up stack stuff. Add a guard
size_t stackSize = c_defaultStackSize;
+void* sp = nullptr;
+
+#ifndef LIBCONTEXT_HAS_OWN_STACK
+// fixme: Clean up stack stuff. Add a guard
m_stack.reset( new char[stackSize] );
// align to 16 bytes
-void* sp = (void*)ptrdiff_t) m_stack.get()) + stackSize - 0xf) & (~0x0f));
+sp = (void*)ptrdiff_t) m_stack.get()) + stackSize - 0xf) & (~0x0f));
// correct the stack size
stackSize -= size_t( ( (ptrdiff_t) m_stack.get() + stackSize ) - (ptrdiff_t) sp );
+#endif
m_callee = libcontext::make_fcontext( sp, stackSize, callerStub );
m_running = true;
___
Mailing list: https://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] [PATCH 0/9] MSVC build support
Hi, this is a rework of Tom's rework of my MSVC branch, compile-tested on Linux, MSYS2 and MSVC. The full branch is on Launchpad, as https://git.launchpad.net/~sjr/kicad/msvc-new . Before we can merge this, this needs more extensive testing, and a few reviews. If you want to try binaries from MSVC, get them from the build artifacts of the appropriate configuration below https://jenkins.simonrichter.eu/job/windows-kicad-msvc-tom/ I've snuck in the "Turn off compiler extensions" patch again, that one is optional (and breaks MSYS2 without a particular workaround, so we need to decide if we want it). The other patches are fairly straightforward. Including probably makes sense everywhere, not just in the files where we need strncasecmp. Simon Simon Richter (6): Set _USE_MATH_DEFINES on Windows Turn off compiler extensions Remove own copy of FindOpenSSL.cmake Work around missing min/max in Windows headers Pull in macro definition for strncasecmp on MSVC Define compiler flags for MSVC Tomasz Wlostowski (3): pcbnew: can't return a copy of ptr_vector if items are polymorphic and have no clone() methods. Work it around. Export LIB_TREE_ITEM MSVC support for libcontext CMakeLists.txt | 49 ++ CMakeModules/FindOpenSSL.cmake | 342 --- common/gal/cairo/cairo_print.cpp | 6 + common/system/libcontext.cpp | 66 eeschema/sim/ngspice.cpp | 1 + include/lib_tree_item.h | 4 +- include/system/libcontext.h | 16 +- include/tool/coroutine.h | 8 +- pcbnew/pcb_edit_frame.h | 3 +- pcbnew/pcbnew_config.cpp | 12 +- 10 files changed, 153 insertions(+), 354 deletions(-) delete mode 100644 CMakeModules/FindOpenSSL.cmake -- 2.11.0 ___ Mailing list: https://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] [PATCH 2/9] Export LIB_TREE_ITEM
---
include/lib_tree_item.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/lib_tree_item.h b/include/lib_tree_item.h
index 5ad5ef4bd..28f69b7c0 100644
--- a/include/lib_tree_item.h
+++ b/include/lib_tree_item.h
@@ -27,7 +27,7 @@
#include
#include
-
+#include
/**
* A mix-in to provide polymorphism between items stored in libraries (symbols, aliases
@@ -36,7 +36,7 @@
* It is used primarily to drive the component tree for library browsing and editing.
*/
-class LIB_TREE_ITEM
+class APIEXPORT LIB_TREE_ITEM
{
public:
virtual LIB_ID GetLibId() const = 0;
___
Mailing list: https://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] [PATCH 8/9] Pull in macro definition for strncasecmp on MSVC
--- eeschema/sim/ngspice.cpp | 1 + 1 file changed, 1 insertion(+) diff --git a/eeschema/sim/ngspice.cpp b/eeschema/sim/ngspice.cpp index fa1d3e3a9..4b173ef7a 100644 --- a/eeschema/sim/ngspice.cpp +++ b/eeschema/sim/ngspice.cpp @@ -28,6 +28,7 @@ #include "ngspice.h" #include "spice_reporter.h" +#include #include // LOCALE_IO #include #include ___ Mailing list: https://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] Bug 1834718
Hey Seth, No bueno. Here is the back trace using your patch. Cheers, Wayne #41640 0x6d26fb1d in ?? () from E:\msys64\mingw64\bin\wxmsw30u_core_gcc_custom.dll #41641 0x806e8747 in WX_PROGRESS_REPORTER::~WX_PROGRESS_REPORTER ( this=0x12884860, __in_chrg=) at E:/msys64/home/Wayne/src/kicad-5.1/common/widgets/progress_reporter.cpp:117 #41642 0x806e8785 in WX_PROGRESS_REPORTER::~WX_PROGRESS_REPORTER ( this=0x12884860, __in_chrg=) at E:/msys64/home/Wayne/src/kicad-5.1/common/widgets/progress_reporter.cpp:118 #41643 0x809da798 in std::default_delete::operator() (this=0x1539f138, __ptr=0x12884860) at E:/msys64/mingw64/include/c++/9.1.0/bits/unique_ptr.h:81 #41644 0x80a24454 in std::unique_ptr >::~unique_ptr (this=0x1539f138, __in_chrg=) at E:/msys64/mingw64/include/c++/9.1.0/bits/unique_ptr.h:289 #41645 0x802e4b26 in ZONE_FILLER_TOOL::ZoneFill (this=0x14338300, aEvent=...) at E:/msys64/home/Wayne/src/kicad-5.1/pcbnew/tools/zone_filler_tool.cpp:103 #41646 0x80bc7b4f in std::__invoke_impl (__f= @0x182d4800: (int (ZONE_FILLER_TOOL::*)(class ZONE_FILLER_TOOL * const, const class TOOL_EVENT &)) 0x802e4888 , __t=@0x182d4810: 0x14338300, __args#0=...) at E:/msys64/mingw64/include/c++/9.1.0/bits/invoke.h:73 #41647 0x80c17723 in std::__invoke (__fn= @0x182d4800: (int (ZONE_FILLER_TOOL::*)(class ZONE_FILLER_TOOL * const, const class TOOL_EVENT &)) 0x802e4888 , __args#0=@0x182d4810: 0x14338300, __args#1=...) at E:/msys64/mingw64/include/c++/9.1.0/bits/invoke.h:95 #41648 0x80ab5bcb in std::_Bind))(TOOL_EVENT const&)>::__call(std::tuple&&, std::_Index_tuple<0ull, 1ull>) ( this=0x182d4800, __args=...) at E:/msys64/mingw64/include/c++/9.1.0/functional:400 #41649 0x80ab5cf4 in std::_Bind))(TOOL_EVENT const&)>::operator()(TOOL_EVENT const&) (this=0x182d4800, __args#0=...) at E:/msys64/mingw64/include/c++/9.1.0/functional:484 #41650 0x80a90269 in std::_Function_handler))(TOOL_EVENT const&)> >::_M_invoke(std::_Any_data const&, TOOL_EVENT const&) ( __functor=..., __args#0=...) at E:/msys64/mingw64/include/c++/9.1.0/bits/std_function.h:285 #41651 0x80a01b9b in std::function::operator()(TOOL_EVENT const&) const (this=0x182d2db8, __args#0=...) at E:/msys64/mingw64/include/c++/9.1.0/bits/std_function.h:690 #41652 0x8095920a in COROUTINE::callerStub ( aData=354023872) at E:/msys64/home/Wayne/src/kicad-5.1/include/tool/coroutine.h:331 #41653 0x807b8f4a in make_fcontext () from E:\msys64\mingw64\bin\_pcbnew.kiface #41654 0x1519f9c0 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) On 6/29/2019 3:17 PM, Seth Hillbrand wrote: > Hi Wayne- > > That actually helps a lot. It also explains why this is MSW-only behavior. > > I'm attaching a patch that should address this. Let me know if it > doesn't help. > > Best- > Seth > > On 2019-06-29 11:48, Wayne Stambaugh wrote: >> Seth, >> >> I managed to let the gdb back trace finish. It took a while but here is >> the last of the stack up to the last progress dialog dtor iteration. >> I'm not sure how much good it's going to do. It looks like there was a >> context switch or something that corrupted the previous stack frame so >> any useful information in that stack frame is lost :( >> >> Wayne >> >> #83262 0x6d26fb1d in ?? () >> from E:\msys64\mingw64\bin\wxmsw30u_core_gcc_custom.dll >> #83263 0x806e8547 in >> WX_PROGRESS_REPORTER::~WX_PROGRESS_REPORTER ( >> this=0x1751aca0, __in_chrg=) >> at >> E:/msys64/home/Wayne/src/kicad-5.1/common/widgets/progress_reporter.cpp:117 >> >> #83264 0x802d2d88 in POINT_EDITOR::finishItem (this=0x12a8a3a0) >> at >> E:/msys64/home/Wayne/src/kicad-5.1/pcbnew/tools/point_editor.cpp:650 >> #83265 0x802d15a0 in POINT_EDITOR::OnSelectionChange ( >> this=0x12a8a3a0, aEvent=...) >> at >> E:/msys64/home/Wayne/src/kicad-5.1/pcbnew/tools/point_editor.cpp:427 >> #83266 0x80bc764f in std::__invoke_impl> (POINT_EDITOR::*&)(TOOL_EVENT const&), POINT_EDITOR*&, TOOL_EVENT >> const&> (__f= >> @0x190138a0: (int (POINT_EDITOR::*)(class POINT_EDITOR * const, >> const class TOOL_EVENT &)) 0x802d0b22 >> , __t=@0x190138b0: >> 0x12a8a3a0, __args#0=...) >> at E:/msys64/mingw64/include/c++/9.1.0/bits/invoke.h:73 >> #83267 0x80c172b3 in std::__invoke> (POINT_EDITOR::*&)(TOOL_EVENT const&), POINT_EDITOR*&, TOOL_EVENT >> const&> (__fn= >> @0x190138a0: (int (POINT_EDITOR::*)(class POINT_EDITOR * const, >> const class TOOL_EVENT &)) 0x802d0b22 >> , >> __args#0=@0x190138b0: 0x12a8a3a0, __args#1=...) >> at E:/msys64/mingw64/include/c++/9.1.0/bits/invoke.h:95 >> #83268 0x80ab4fcb in std::_Bind> (POINT_EDITOR::*(POINT_EDITOR*, std::_Placeholder<1>))(TOOL_EVENT >> const&)>::__call> 1ull>(std::tuple&&, std::_Index_tuple<0ull, 1ull>) ( >> this=0x190138a0, __args=
Re: [Kicad-developers] Arc editing in LibEdit
It’s on master (and so is in nightlies). Cheers, Jeff. > On 30 Jun 2019, at 22:36, Kevin Cozens wrote: > > On 6/29/19 11:12 AM, Jeff Young wrote: >> So Ive rewritten the LibEdit arc point handling to keep the >> end-points invariant when editing other points. > > Which branch of code includes the changes to LibEdit? > > -- > Cheers! > > Kevin. > > http://www.ve3syb.ca/ | "Nerds make the shiny things that > https://www.patreon.com/KevinCozens | distract the mouth-breathers, and >| that's why we're powerful" > Owner of Elecraft K2 #2172 | > #include | --Chris Hardwick > > ___ > Mailing list: https://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] Bug 1833851 - Massively Parallel Builds
Hi, > The background is the GNU make is not intelligent about parallel > builds and doesn't merge generated targets. FWIW we have the same problem on MSBuild. The problem we have is that we use the same generated file from two different projects, and CMake's paradigm is that generated files belong to the project that uses them, so project-to-project dependencies are used to lock out parallel generation. For both Make and MSBuild, the same target inside the same project is merged and handled correctly. The Makefile generator uses sub-make invocations for the separate projects, and each of these only sees the dependency tree for its project, which causes the problem. > 1) Build the header file into a target directory instead of the > source directory. Then everyone gets to build their own with no > conflict. We end up building lots and lots of header/lexer files. > Developers won't see the files in the usual location. This is a good idea anyway. When building in a separate directory, the source tree should not be touched. If you keep the source tree in a subdirectory "src" below a directory containing a Makefile like all: build-1 build-2 build-3 build-4 build-%: mkdir -p build/$@ (cd build/$@ && cmake ../../src) $(MAKE) -C build/$@ this should be safe to build in parallel (and might be useful if you want to build several configurations, because the toplevel make has the jobserver). In principle, the original "generated files live in a separate project" approach should work, but that project needs to be a library which consumes the generated cpp file (so ownership of the custom rule is clear) and exports the header file to other projects. We'd have to clarify whether this is safe with the generated dependencies for headers if the token list changes, but I think it should be. I might be able to experiment with that a bit tonight if noone beats me to it. 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
