Re: [Kicad-developers] [PATCH] Fixes for Visual Studio / vcpkg build

[Brian Piccioni]

Jon Despite MSVC Community being from MS, I see some advantages in using it, namely that it is basically a one-package solution: no msys2, no loads of other tools that have to be updated, etc..  My lack of cmake-foo meant I hit a roadblock when trying to build an MSVC recipe. One time I got so far as to have it crap out on SSL or something like that but now I’m stuck much earlier. In any event I’m more than happy to experiment with whatever you’ve got, especially if you can provide some guidance. Brian From: Jon EvansSent: November 24, 2019 12:41 PMTo: KiCad DevelopersSubject: [Kicad-developers] [PATCH] Fixes for Visual Studio / vcpkg build Hi all, I got a build working using Visual Studio 2019 and vcpkg.Attached are three patches I needed to make so far.I'd appreciate some double-checking on these since cmake and wxwidgets can be a bit perilous. Thanks,-Jon 

___
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] Librarians, Doc Devs and Code Devs

[Seth Hillbrand]

Hi All-

This is a friendly request for you (yes, you!) to create a user account 
at GitLab.  This can either be signing in with your existing GitHub 
account over OAuth or creating a new account with the same e-mail as 
your public GitHub email address.


We're not moving over to GitLab yet, but the import process leaves a lot 
of dangling issue reports and PRs if the user e-mail does not exist in 
the GitLab system at the time the import is first run.


Thanks and we're looking forward to seeing everyone at GitLab.

-Seth

Seth Hillbrand
KiCad Services Corporation
https://www.kipro-pcb.com
+1 530 302 5483 | +1 212 603 9372

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

Re: [Kicad-developers] [PATCH] Fixes for Visual Studio / vcpkg build

[Jon Evans]

I have not tried to get those working yet, I have them disabled by flags.
I can try to see what was involved in adding new packages.

-Jon

On Sun, Nov 24, 2019 at 5:17 PM Wayne Stambaugh 
wrote:

> Hey Jon,
>
> I was playing around with vcpkg a couple of weeks ago and it's works
> surprisingly well.  There is finally a sane way to build dependencies
> and compile and link against them on windows.  The dependencies I could
> not find in vcpkg are ngspice and wxPhoenix/wxWidgets which means that
> we could not build and debug the simulator code and the wx python
> extension support.  Did someone recently add ngspice and wxPhoneix to
> vcpkg?  The Python code is also somewhat different as I assume that you
> would use the default python install to build the Python extensions.
>
> Cheers,
>
> Wayne
>
> On 11/24/19 12:40 PM, Jon Evans wrote:
> > Hi all,
> >
> > I got a build working using Visual Studio 2019 and vcpkg.
> > Attached are three patches I needed to make so far.
> > I'd appreciate some double-checking on these since cmake and wxwidgets
> > can be a bit perilous.
> >
> > Thanks,
> > -Jon
> >
> > ___
> > 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] Fixes for Visual Studio / vcpkg build

[Wayne Stambaugh]

Once all of the dependencies for vcpkg are in place, I could see
actually using VS for development (I can't beleive I'm actually typing
this) on windows.  Who knew?

On 11/24/19 5:23 PM, Ian McInerney wrote:
> I think it is still missing the OCC/OCE package as well:
> https://github.com/microsoft/vcpkg/issues/4968
> 
> -Ian
> 
> On Sun, 24 Nov 2019, 22:17 Wayne Stambaugh,  > wrote:
> 
> Hey Jon,
> 
> I was playing around with vcpkg a couple of weeks ago and it's works
> surprisingly well.  There is finally a sane way to build dependencies
> and compile and link against them on windows.  The dependencies I could
> not find in vcpkg are ngspice and wxPhoenix/wxWidgets which means that
> we could not build and debug the simulator code and the wx python
> extension support.  Did someone recently add ngspice and wxPhoneix to
> vcpkg?  The Python code is also somewhat different as I assume that you
> would use the default python install to build the Python extensions.
> 
> Cheers,
> 
> Wayne
> 
> On 11/24/19 12:40 PM, Jon Evans wrote:
> > Hi all,
> >
> > I got a build working using Visual Studio 2019 and vcpkg.
> > Attached are three patches I needed to make so far.
> > I'd appreciate some double-checking on these since cmake and wxwidgets
> > can be a bit perilous.
> >
> > Thanks,
> > -Jon
> >
> > ___
> > 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] Fixes for Visual Studio / vcpkg build

[Ian McInerney]

I think it is still missing the OCC/OCE package as well:
https://github.com/microsoft/vcpkg/issues/4968

-Ian

On Sun, 24 Nov 2019, 22:17 Wayne Stambaugh,  wrote:

> Hey Jon,
>
> I was playing around with vcpkg a couple of weeks ago and it's works
> surprisingly well.  There is finally a sane way to build dependencies
> and compile and link against them on windows.  The dependencies I could
> not find in vcpkg are ngspice and wxPhoenix/wxWidgets which means that
> we could not build and debug the simulator code and the wx python
> extension support.  Did someone recently add ngspice and wxPhoneix to
> vcpkg?  The Python code is also somewhat different as I assume that you
> would use the default python install to build the Python extensions.
>
> Cheers,
>
> Wayne
>
> On 11/24/19 12:40 PM, Jon Evans wrote:
> > Hi all,
> >
> > I got a build working using Visual Studio 2019 and vcpkg.
> > Attached are three patches I needed to make so far.
> > I'd appreciate some double-checking on these since cmake and wxwidgets
> > can be a bit perilous.
> >
> > Thanks,
> > -Jon
> >
> > ___
> > 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] Fixes for Visual Studio / vcpkg build

[Wayne Stambaugh]

Hey Jon,

I was playing around with vcpkg a couple of weeks ago and it's works
surprisingly well.  There is finally a sane way to build dependencies
and compile and link against them on windows.  The dependencies I could
not find in vcpkg are ngspice and wxPhoenix/wxWidgets which means that
we could not build and debug the simulator code and the wx python
extension support.  Did someone recently add ngspice and wxPhoneix to
vcpkg?  The Python code is also somewhat different as I assume that you
would use the default python install to build the Python extensions.

Cheers,

Wayne

On 11/24/19 12:40 PM, Jon Evans wrote:
> Hi all,
> 
> I got a build working using Visual Studio 2019 and vcpkg.
> Attached are three patches I needed to make so far.
> I'd appreciate some double-checking on these since cmake and wxwidgets
> can be a bit perilous.
> 
> Thanks,
> -Jon
> 
> ___
> 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] Using OPT types

[Tomasz Wlostowski]

On 24/11/2019 18:20, Seth Hillbrand wrote:
> 
> I generally like both of these.  But part of that is because my IDE (VS
> Code and sometimes Eclipse) shows me the underlying type(...)

I second Seth. Also use VScode, great editor ;-)

T.


___
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] GitLab migration

[Seth Hillbrand]

On 2019-11-24 13:13, Mark Roszko wrote:

Can the use of 2FA be mandated across the entire group since we have a 
fresh start?


It's been killing me that it's not required for GitHub and it really is 
a vulnerability to not enforce. KiCad is a decent value target for 
malicious code placement since it is a desktop app.


https://docs.gitlab.com/ee/security/two_factor_authentication.html#enforcing-2fa-for-all-users-in-a-group



Hi Mark-

Can you open an issue for this in the transition repository[1]?  It 
makes sense to me but it would be good to track that in the transition 
in case other issues arise from it.


Best-
Seth


[1] https://gitlab.com/kicad_pcb/kicad_migration

Seth Hillbrand
KiCad Services Corporation
https://www.kipro-pcb.com
+1 530 302 5483 | +1 212 603 9372

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

Re: [Kicad-developers] GitLab migration

[Mark Roszko]

Can the use of 2FA be mandated across the entire group since we have a
fresh start?

It's been killing me that it's not required for GitHub and it really is a
vulnerability to not enforce. KiCad is a decent value target for malicious
code placement since it is a desktop app.

https://docs.gitlab.com/ee/security/two_factor_authentication.html#enforcing-2fa-for-all-users-in-a-group


On Tue, Nov 12, 2019 at 7:58 AM Wayne Stambaugh 
wrote:

> Hey Orson,
>
> I'm on the fence on this one.  I remember similar issues when we
> migrated from SourceForge.  It would be nice if we could migrate just
> the bug reports that were fixed for 5.1 and later but I'm sure that is
> not going to be possible because we did not do a great job in the past
> of setting the bug report milestone.  This would at least make it
> possible to search for bugs that have already been fixed in the current
> stable branch without having to fall back to launchpad.  I'm not
> concerned about closed bug reports for 5.0 and earlier since we no
> longer support those branches.  We could migrate all the closed reports
> with a milestone of 5.1.0 or later.  I know this wont be a complete
> solution but it may be good enough.
>
> Cheers,
>
> Wayne
>
> On 11/12/19 2:37 AM, Maciej Suminski wrote:
> > Hi Andrew,
> >
> > I deliberately skipped the closed bugs, as I thought they do not carry
> > much value, and they would still be available in the Launchpad tracker.
> > If majority prefers to migrate the closed bugs, then there is nothing in
> > the way.
> >
> > Cheers,
> > Orson
> >
> > On 11/11/19 11:54 PM, Andrew Lutsenko wrote:
> >> Is it possible to migrate closed bugs as well? I think gitlab search
> >> indexing is much more useful, having history conserved there will likely
> >> be handy.
> >>
> >> On Mon, Nov 11, 2019 at 2:31 AM Maciej Suminski <
> maciej.sumin...@cern.ch
> >> > wrote:
> >>
> >> Excellent, thanks for the verification! I have also checked a few
> other
> >> reports that had original authors incorrectly assigned, so I
> believe the
> >> bug has been fixed.
> >>
> >> Cheers,
> >> Orson
> >>
> >> On 11/11/19 10:29 AM, Eeli Kaikkonen wrote:
> >> > Now the example bug report ("Implicit 4-way junction" etc.) is
> >> correctly
> >> > attributed to "eelik".
> >> >
> >> > Eeli Kaikkonen
> >> >
> >> > su 10. marrask. 2019 klo 19.44 Maciej Suminski
> >> (maciej.sumin...@cern.ch 
> >> >  >>)
> >> kirjoitti:
> >> >
> >> > On 11/10/19 5:54 PM, Seth Hillbrand wrote:
> >> > > On 2019-11-10 08:43, Seth Hillbrand wrote:
> >> > >
> >> > >> On 2019-11-10 08:33, Eeli Kaikkonen wrote:
> >> > >>
> >> > >>> OK. Would it be worth re-importing everything even for
> >> this test
> >> > database to avoid false impressions?
> >> > >>>
> >> > >>> Eeli Kaikkonen
> >> > >>
> >> > >> What false impression?  Is there a report that is listed as
> >> being
> >> > created by different people in launchpad vs. GitLab?
> >> > >
> >> > > Oops.  Disregard.  I see a broken report here:
> >> > > https://gitlab.com/orsonmmz/kicad-bug-tracker/issues/7367
> >> > >
> >> > > Looks like the Launchpad API doesn't handle users who have
> since
> >> > deleted
> >> > > their accounts nicely and the script is falling back on
> Fabien's
> >> > > account, probably because his is index 0.
> >> >
> >> > Good catch, thanks! I think I have already found the bug, I
> >> will let you
> >> > know after the next run is finished.
> >> >
> >> > Cheers,
> >> > Orson
> >> >
> >> > ___
> >> > 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
> >> 

[Kicad-developers] Launchpad Bug that are "Fix Released" for Milestone KiCad 6.0.0-rc1

[Ronnie Gaensli]

Hi Devs,

I'd like to bring to your attention following bugs that are marked as
released for milestone KiCad 6.0.0-rc1, something that IMHO is not quite
possible yet. (Note: I'm concerned about status released, not committed):
https://bugs.launchpad.net/kicad/+bugs?field.status%3Alist=FIXRELEASED%3Alist=84788

I'd guess that either they are fix commited for 6.0 or they are released
for an earlier milestone.

Best regards,
Ronnie
___
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] Using OPT types

[Eeli Kaikkonen]

A good IDE should be able to open up auto and typedef in a tooltip. Clang
library helps here, for example Qt Creator uses it and shows the actual
type when I hover over auto.

Eeli Kaikkonen

su 24. marrask. 2019 klo 19.10 Wayne Stambaugh (stambau...@gmail.com)
kirjoitti:

> On 11/24/19 7:12 AM, Jeff Young wrote:
> > Personally I hate OPT (because it’s somewhat harder to read and
> more-than-somewhat harder to debug).
>
> I tend to agree with Jeff.  The older I get, the less I like having to
> dig around the code base to figure out what is going on because
> templated code does tend to be less fun to debug.
> >
> > I also dislike auto, except in the case of stl::’s overly-verbose
> iterators.  Again, they make the code harder to read more often than not.
>
> I'm seriously rethinking typedefs as well.  I can never seem to remember
> the type they represent so I have to dig around the source to figure out
> the actual type.  I'm thinking just typing out the full type is easier
> in the shortened typedefed version which was most likely only created to
> save some typing.
>
> >
> > Maybe I’m just showing my age….
>
> Funny how age changes your perspective.
>
> >
> >> On 24 Nov 2019, at 11:13, Ian McInerney 
> wrote:
> >>
> >> What is the current consensus on using OPT types in the code? I know
> there are some instances where we are already using them from the Boost
> library (since our C++ version isn't high enough to include them), but is
> that considered a good type to use more of?
> >>
> >> I am curious, because I am thinking of replumbing the position storage
> in the tool events to use OPTs for the position, because that will allow
> for cleaner handling of the position in the tools, and also because I need
> to pass the positions into the selection routines, and being able to pass
> an OPT will greatly simplify things (I think).
> >>
> >> -Ian
> >> ___
> >> 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] Who controls gitlab.com/kicad?

[Nick Østergaard]

I don't know, but I have https://gitlab.com/kicad_eda that I have been
using as a playground.

søn. 24. nov. 2019 15.42 skrev Seth Hillbrand :

> Hi All-
>
> As you have heard, we are moving from Launchpad to GitLab.  However, we
> have been unable to secure the https://www.gitlab.com/kicad group name
> for the project.  The name appears to already be taken.  However, this is
> not a public group or user, so we don't know who controls the name.
>
> Does anyone on the list control the "kicad" name at GitLab?  In the
> interim, we've registered https://www.gitlab.com/kicad_pcb but it would
> be much better if we could use the shorter name.
>
>
> Thanks-
> Seth
>
>
> KiCad Services Corporation [image: KiCad Services Corporation Logo]
> Seth Hillbrand
> *Lead Developer*
> +1-530-302-5483‬ <+12126039372>
> Davis, CA
> www.kipro-pcb.comi...@kipro-pcb.com
> https://twitter.com/KiProEDA 
> https://www.linkedin.com/company/kicad
> 
> ___
> 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] [PATCH] Fixes for Visual Studio / vcpkg build

[Jon Evans]

Hi all,

I got a build working using Visual Studio 2019 and vcpkg.
Attached are three patches I needed to make so far.
I'd appreciate some double-checking on these since cmake and wxwidgets can
be a bit perilous.

Thanks,
-Jon
From 87674cb5a87b4d77683248b65994ef625f8a7c47 Mon Sep 17 00:00:00 2001
From: Jon Evans 
Date: Sun, 24 Nov 2019 12:30:29 -0500
Subject: [PATCH 1/3] Use wxArrayString instead of vector in
 BUS_ALIAS

Fixes linker errors on Windows/VC
See: https://trac.wxwidgets.org/ticket/10884
---
 eeschema/bus_alias.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/eeschema/bus_alias.h b/eeschema/bus_alias.h
index 43073277f..b1e534007 100644
--- a/eeschema/bus_alias.h
+++ b/eeschema/bus_alias.h
@@ -22,8 +22,8 @@
 #define _BUS_ALIAS_H
 
 #include 
-#include 
 #include 
+#include 
 
 
 class SCH_SCREEN;
@@ -66,7 +66,7 @@ public:
 return m_members.size();
 }
 
-std::vector< wxString >& Members()
+wxArrayString& Members()
 {
 return m_members;
 }
@@ -87,7 +87,7 @@ protected:
 
 wxString m_name;
 
-std::vector< wxString > m_members;
+wxArrayString m_members;
 
 /**
  * The bus alias editor dialog can edit aliases from all open sheets.
-- 
2.23.0.windows.1

From 913f66479a59b39e8b9f62c2c7738a5d4fa32c26 Mon Sep 17 00:00:00 2001
From: Jon Evans 
Date: Sun, 24 Nov 2019 12:31:44 -0500
Subject: [PATCH 2/3] Mark ERC compare operators as const

Not including these is a compile error on MSW/VC
---
 eeschema/erc.cpp | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/eeschema/erc.cpp b/eeschema/erc.cpp
index bf876c191..e7b01998a 100644
--- a/eeschema/erc.cpp
+++ b/eeschema/erc.cpp
@@ -664,7 +664,7 @@ void NETLIST_OBJECT_LIST::TestforNonOrphanLabel( unsigned 
aNetItemRef, unsigned
 // the full text is "sheetpath+label" for local labels and "label" for global 
labels
 struct compare_labels
 {
-bool operator() ( const NETLIST_OBJECT* lab1, const NETLIST_OBJECT* lab2 )
+bool operator() ( const NETLIST_OBJECT* lab1, const NETLIST_OBJECT* lab2 ) 
const
 {
 wxString str1 = lab1->m_SheetPath.Path() + lab1->m_Label;
 wxString str2 = lab2->m_SheetPath.Path() + lab2->m_Label;
@@ -675,7 +675,7 @@ struct compare_labels
 
 struct compare_label_names
 {
-bool operator() ( const NETLIST_OBJECT* lab1, const NETLIST_OBJECT* lab2 )
+bool operator() ( const NETLIST_OBJECT* lab1, const NETLIST_OBJECT* lab2 ) 
const
 {
 return lab1->m_Label.Cmp( lab2->m_Label ) < 0;
 }
@@ -683,7 +683,7 @@ struct compare_label_names
 
 struct compare_paths
 {
-bool operator() ( const NETLIST_OBJECT* lab1, const NETLIST_OBJECT* lab2 )
+bool operator() ( const NETLIST_OBJECT* lab1, const NETLIST_OBJECT* lab2 ) 
const
 {
 return lab1->m_SheetPath.Path().Cmp( lab2->m_SheetPath.Path() ) < 0;
 }
-- 
2.23.0.windows.1

From 5faf8f7894c2fcb25ce9b1f13db5dc268c425d2b Mon Sep 17 00:00:00 2001
From: Jon Evans 
Date: Sun, 24 Nov 2019 12:35:32 -0500
Subject: [PATCH 3/3] Update FindwxWidgets.cmake to work under MSW/vcpkg

Taken from: 
https://github.com/CaeruleusAqua/vcpkg-wx-find/blob/master/FindwxWidgets.cmake
---
 CMakeModules/FindwxWidgets.cmake | 140 +++
 1 file changed, 105 insertions(+), 35 deletions(-)

diff --git a/CMakeModules/FindwxWidgets.cmake b/CMakeModules/FindwxWidgets.cmake
index 6a8dc90e7..8263d2c44 100644
--- a/CMakeModules/FindwxWidgets.cmake
+++ b/CMakeModules/FindwxWidgets.cmake
@@ -509,41 +509,111 @@ if(wxWidgets_FIND_STYLE STREQUAL "win32")
 else()
   set(WX_LIB_DIR_PREFIX vc)
 endif()
-if(BUILD_SHARED_LIBS)
-  find_path(wxWidgets_LIB_DIR
-NAMES
-  msw/wx/setup.h
-  mswd/wx/setup.h
-  mswu/wx/setup.h
-  mswud/wx/setup.h
-  mswuniv/wx/setup.h
-  mswunivd/wx/setup.h
-  mswunivu/wx/setup.h
-  mswunivud/wx/setup.h
-PATHS
-${WX_ROOT_DIR}/lib/${WX_LIB_DIR_PREFIX}_dll   # prefer shared
-${WX_ROOT_DIR}/lib/${WX_LIB_DIR_PREFIX}_lib
-DOC "Path to wxWidgets libraries"
-NO_DEFAULT_PATH
-)
-else()
-  find_path(wxWidgets_LIB_DIR
-NAMES
-  msw/wx/setup.h
-  mswd/wx/setup.h
-  mswu/wx/setup.h
-  mswud/wx/setup.h
-  mswuniv/wx/setup.h
-  mswunivd/wx/setup.h
-  mswunivu/wx/setup.h
-  mswunivud/wx/setup.h
-PATHS
-${WX_ROOT_DIR}/lib/${WX_LIB_DIR_PREFIX}_lib   # prefer static
-${WX_ROOT_DIR}/lib/${WX_LIB_DIR_PREFIX}_dll
-DOC "Path to wxWidgets libraries"
-NO_DEFAULT_PATH
-)
-endif()
+   
+   if(VCPKG_TOOLCHAIN)
+   set(wxWidgets_FOUND TRUE)
+   find_path(wxWidgets_ROOT_DIR
+   NAMES include/wx/wx.h
+   PATHS
+   ENV wxWidgets_ROOT_DIR
+   DOC "wxWidgets base/installation directory"
+   

Re: [Kicad-developers] Using OPT types

[jp charras]

Le 24/11/2019 à 18:09, Wayne Stambaugh a écrit :
> On 11/24/19 7:12 AM, Jeff Young wrote:
>> Personally I hate OPT (because it’s somewhat harder to read and 
>> more-than-somewhat harder to debug).
> 
> I tend to agree with Jeff.  The older I get, the less I like having to
> dig around the code base to figure out what is going on because
> templated code does tend to be less fun to debug.
>>
>> I also dislike auto, except in the case of stl::’s overly-verbose iterators. 
>>  Again, they make the code harder to read more often than not.
> 
> I'm seriously rethinking typedefs as well.  I can never seem to remember
> the type they represent so I have to dig around the source to figure out
> the actual type.  I'm thinking just typing out the full type is easier
> in the shortened typedefed version which was most likely only created to
> save some typing.
> 
>>
>> Maybe I’m just showing my age….
> 
> Funny how age changes your perspective.
> 

I full agree with Jeff and Wayne:
auto (and OPT) obfuscate the code.
As Jeff said, auto is useful only in the case of stl::’s overly-verbose
iterators.

I already had to fix bugs in code using auto due to this obfuscation.

>>
>>> On 24 Nov 2019, at 11:13, Ian McInerney  wrote:
>>>
>>> What is the current consensus on using OPT types in the code? I know there 
>>> are some instances where we are already using them from the Boost library 
>>> (since our C++ version isn't high enough to include them), but is that 
>>> considered a good type to use more of?
>>>
>>> I am curious, because I am thinking of replumbing the position storage in 
>>> the tool events to use OPTs for the position, because that will allow for 
>>> cleaner handling of the position in the tools, and also because I need to 
>>> pass the positions into the selection routines, and being able to pass an 
>>> OPT will greatly simplify things (I think).
>>>
>>> -Ian


-- 
Jean-Pierre CHARRAS

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

Re: [Kicad-developers] Using OPT types

[Seth Hillbrand]

On 2019-11-24 09:09, Wayne Stambaugh wrote:

I also dislike auto, except in the case of stl::’s overly-verbose 
iterators.  Again, they make the code harder to read more often than 
not.


I'm seriously rethinking typedefs as well.  I can never seem to 
remember
the type they represent so I have to dig around the source to figure 
out

the actual type.  I'm thinking just typing out the full type is easier
in the shortened typedefed version which was most likely only created 
to

save some typing.


I generally like both of these.  But part of that is because my IDE (VS 
Code and sometimes Eclipse) shows me the underlying type when I mouse 
hover over the auto variable.  Same thing with type aliases.  If I 
needed to dig for them or remember, I would definitely come down in the 
other camp.


-Seth

Seth Hillbrand
KiCad Services Corporation
https://www.kipro-pcb.com
+1 530 302 5483 | +1 212 603 9372

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

Re: [Kicad-developers] Using OPT types

[Wayne Stambaugh]

On 11/24/19 7:12 AM, Jeff Young wrote:
> Personally I hate OPT (because it’s somewhat harder to read and 
> more-than-somewhat harder to debug).

I tend to agree with Jeff.  The older I get, the less I like having to
dig around the code base to figure out what is going on because
templated code does tend to be less fun to debug.
> 
> I also dislike auto, except in the case of stl::’s overly-verbose iterators.  
> Again, they make the code harder to read more often than not.

I'm seriously rethinking typedefs as well.  I can never seem to remember
the type they represent so I have to dig around the source to figure out
the actual type.  I'm thinking just typing out the full type is easier
in the shortened typedefed version which was most likely only created to
save some typing.

> 
> Maybe I’m just showing my age….

Funny how age changes your perspective.

> 
>> On 24 Nov 2019, at 11:13, Ian McInerney  wrote:
>>
>> What is the current consensus on using OPT types in the code? I know there 
>> are some instances where we are already using them from the Boost library 
>> (since our C++ version isn't high enough to include them), but is that 
>> considered a good type to use more of?
>>
>> I am curious, because I am thinking of replumbing the position storage in 
>> the tool events to use OPTs for the position, because that will allow for 
>> cleaner handling of the position in the tools, and also because I need to 
>> pass the positions into the selection routines, and being able to pass an 
>> OPT will greatly simplify things (I think).
>>
>> -Ian
>> ___
>> 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

[Kicad-developers] Who controls gitlab.com/kicad?

[Seth Hillbrand]

Hi All- 

As you have heard, we are moving from Launchpad to GitLab.  However, we
have been unable to secure the https://www.gitlab.com/kicad group name
for the project.  The name appears to already be taken.  However, this
is not a public group or user, so we don't know who controls the name. 

Does anyone on the list control the "kicad" name at GitLab?  In the
interim, we've registered https://www.gitlab.com/kicad_pcb but it would
be much better if we could use the shorter name. 

Thanks-
Seth 

KiCad Services Corporation 

Seth Hillbrand

LEAD DEVELOPER

+1-530-302-5483‬ [1]

Davis, CA

www.kipro-pcb.com [2]i...@kipro-pcb.com

https://twitter.com/KiProEDA [3]
https://www.linkedin.com/company/kicad [4]

 

Links:
--
[1] tel:+12126039372
[2] http://www.kipro-pcb.com/
[3] https://twitter.com/KiProEDA
[4] https://www.linkedin.com/company/kicad___
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] Back annotate references from PCB

[Alexander Shuklin]

Hi Eeli,
no, you are actually right.
I just don't want to make a new dialog before we will be sure that we
definitely need it. But in case that you will propagate not only
references you suppose to have new one.

On Sun, 24 Nov 2019 at 12:27, Eeli Kaikkonen  wrote:
>
> I probably don't understand everything which has been said, but as far as I 
> can see there are actually two things going on which could and should be 
> independent.
>
> 1. Doing geographical reannotation in pcb.
> 2. Propagating changes made in the pcb back to the schematic.
>
> I believe they should be completely different, and number 2 should be 
> generic, taking care of all changes which reasonably can be propagated from 
> the board to the schematic. Basically Update PCB from Schematic backwards, 
> i.e. Update Schematic from Board. With a similar UI dialog, of course. Undo 
> could also be similar. Or do I just think it's so "simple" and can't see 
> something?
>
> It's easy to see that number 1 isn't difficult and could be done with a 
> python script (although many people would like to see it in the main KiCad, I 
> think).
>
> Eeli Kaikkonen
>
> su 24. marrask. 2019 klo 8.57 Alexander Shuklin (jasura...@gmail.com) 
> kirjoitti:
>>
>> Hi Eeli and Brian,
>> Sorry for delay, unfortunately I cannot answer too often.
>>
>> > It has occurred to me (Alexander please chime in) that once back 
>> > annotation has been solved subject to all the issues raised by Wayne and 
>> > others that it would be a general solution.
>>
>> Unfortunately no. All stuff mentioned by Wayne is has to be
>> implemented in back-annotation, that's situations which back
>> annotation will have to care about, otherwise it will be crap. I meant
>> I see some general tool as geometrical (geographical?) re-annotation
>> in pcbnew, which do left->right top->down or opposite directions being
>> in C++ GUI, but if you want re-annotate in some different manner, you
>> are free to use python scripts, as you could easily back annotate
>> after that.
>>
>> > Can this do other kinds of changes than just annotation? I'm thinking of 
>> > changing the footprint or value
>>
>> Of course that's possible, and not a big deal to add this into
>> back-annotation algorithm. I just think how to do it better. I would
>> say we will need to have some GUI for that then. I mean, you probably
>> want to choose what do you want to back-annotate... or maybe not. And
>> unfortunately at this point you cannot do that with python, as there
>> no python scripts in schematic editor. If it will be useful, I can do
>> that of course. Eeli, what I would suggest, I believe in few days I
>> will make draft commit and mark it (Work In Progress) to show how It
>> works, and we could discuss how it's gonna work with values and
>> footprints it will not be a big deal to change it.
>>
>> On Sat, 23 Nov 2019 at 21:03, Brian Piccioni
>>  wrote:
>> >
>> > It has occurred to me (Alexander please chime in) that once back 
>> > annotation has been solved subject to all the issues raised by Wayne and 
>> > others that it would be a general solution.
>> >
>> >
>> >
>> > Of course, this would end up being a sizeable change to Kicad since the 
>> > various edit functions, etc., who have to be modified to incorporate the 
>> > feature.
>> >
>> >
>> >
>> > Like you I often fiddle with different packages and values and I typically 
>> > switch to eeSchema, make the change, then hit F8 to update the PCB. It 
>> > seems to me it would be easier for the appropriate changes to simply be 
>> > reflected back to the schematic.
>> >
>> >
>> >
>> > Brian
>> >
>> >
>> >
>> > From: Eeli Kaikkonen
>> > Sent: November 23, 2019 12:56 PM
>> > To: kicad-developers
>> > Subject: Re: [Kicad-developers] Back annotate references from PCB
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > la 23. marrask. 2019 klo 14.52 Brian Piccioni 
>> > (br...@documenteddesigns.com) kirjoitti:
>> >
>> > By having a single integrated tool analogous to “Update PCB From 
>> > Schematic” can ensure coherency.
>> >
>> > Can this do other kinds of changes than just annotation? I'm thinking of 
>> > changing the footprint or value. For example I could use Change Footprint 
>> > feature in pcbnew and propagate that change to eeschema. That's not so 
>> > difficult to do in eeshcema and update the board, but often it would feel 
>> > much more natural to e.g. test if 0402 R package would be physically 
>> > better for some situation than 0603 and then update the shcematic based on 
>> > the board if it fits.
>> >
>> >
>> >
>> > Eeli Kaikkonen
>> >
>> >
>> >
>> > ___
>> > Mailing list: https://launchpad.net/~kicad-developers
>> > Post to : kicad-developers@lists.launchpad.net
>> > Unsubscribe : https://launchpad.net/~kicad-developers
>> > More help   : https://help.launchpad.net/ListHelp
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : 

Re: [Kicad-developers] Using OPT types

[Jeff Young]

Personally I hate OPT (because it’s somewhat harder to read and 
more-than-somewhat harder to debug).

I also dislike auto, except in the case of stl::’s overly-verbose iterators.  
Again, they make the code harder to read more often than not.

Maybe I’m just showing my age….

> On 24 Nov 2019, at 11:13, Ian McInerney  wrote:
> 
> What is the current consensus on using OPT types in the code? I know there 
> are some instances where we are already using them from the Boost library 
> (since our C++ version isn't high enough to include them), but is that 
> considered a good type to use more of?
> 
> I am curious, because I am thinking of replumbing the position storage in the 
> tool events to use OPTs for the position, because that will allow for cleaner 
> handling of the position in the tools, and also because I need to pass the 
> positions into the selection routines, and being able to pass an OPT will 
> greatly simplify things (I think).
> 
> -Ian
> ___
> 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] Using OPT types

[Ian McInerney]

What is the current consensus on using OPT types in the code? I know there
are some instances where we are already using them from the Boost library
(since our C++ version isn't high enough to include them), but is that
considered a good type to use more of?

I am curious, because I am thinking of replumbing the position storage in
the tool events to use OPTs for the position, because that will allow for
cleaner handling of the position in the tools, and also because I need to
pass the positions into the selection routines, and being able to pass an
OPT will greatly simplify things (I think).

-Ian
___
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] Back annotate references from PCB

[Eeli Kaikkonen]

I probably don't understand everything which has been said, but as far as I
can see there are actually two things going on which could and should be
independent.

1. Doing geographical reannotation in pcb.
2. Propagating changes made in the pcb back to the schematic.

I believe they should be completely different, and number 2 should be
generic, taking care of all changes which reasonably can be propagated from
the board to the schematic. Basically Update PCB from Schematic backwards,
i.e. Update Schematic from Board. With a similar UI dialog, of course. Undo
could also be similar. Or do I just think it's so "simple" and can't see
something?

It's easy to see that number 1 isn't difficult and could be done with a
python script (although many people would like to see it in the main KiCad,
I think).

Eeli Kaikkonen

su 24. marrask. 2019 klo 8.57 Alexander Shuklin (jasura...@gmail.com)
kirjoitti:

> Hi Eeli and Brian,
> Sorry for delay, unfortunately I cannot answer too often.
>
> > It has occurred to me (Alexander please chime in) that once back
> annotation has been solved subject to all the issues raised by Wayne and
> others that it would be a general solution.
>
> Unfortunately no. All stuff mentioned by Wayne is has to be
> implemented in back-annotation, that's situations which back
> annotation will have to care about, otherwise it will be crap. I meant
> I see some general tool as geometrical (geographical?) re-annotation
> in pcbnew, which do left->right top->down or opposite directions being
> in C++ GUI, but if you want re-annotate in some different manner, you
> are free to use python scripts, as you could easily back annotate
> after that.
>
> > Can this do other kinds of changes than just annotation? I'm thinking of
> changing the footprint or value
>
> Of course that's possible, and not a big deal to add this into
> back-annotation algorithm. I just think how to do it better. I would
> say we will need to have some GUI for that then. I mean, you probably
> want to choose what do you want to back-annotate... or maybe not. And
> unfortunately at this point you cannot do that with python, as there
> no python scripts in schematic editor. If it will be useful, I can do
> that of course. Eeli, what I would suggest, I believe in few days I
> will make draft commit and mark it (Work In Progress) to show how It
> works, and we could discuss how it's gonna work with values and
> footprints it will not be a big deal to change it.
>
> On Sat, 23 Nov 2019 at 21:03, Brian Piccioni
>  wrote:
> >
> > It has occurred to me (Alexander please chime in) that once back
> annotation has been solved subject to all the issues raised by Wayne and
> others that it would be a general solution.
> >
> >
> >
> > Of course, this would end up being a sizeable change to Kicad since the
> various edit functions, etc., who have to be modified to incorporate the
> feature.
> >
> >
> >
> > Like you I often fiddle with different packages and values and I
> typically switch to eeSchema, make the change, then hit F8 to update the
> PCB. It seems to me it would be easier for the appropriate changes to
> simply be reflected back to the schematic.
> >
> >
> >
> > Brian
> >
> >
> >
> > From: Eeli Kaikkonen
> > Sent: November 23, 2019 12:56 PM
> > To: kicad-developers
> > Subject: Re: [Kicad-developers] Back annotate references from PCB
> >
> >
> >
> >
> >
> >
> >
> > la 23. marrask. 2019 klo 14.52 Brian Piccioni (
> br...@documenteddesigns.com) kirjoitti:
> >
> > By having a single integrated tool analogous to “Update PCB From
> Schematic” can ensure coherency.
> >
> > Can this do other kinds of changes than just annotation? I'm thinking of
> changing the footprint or value. For example I could use Change Footprint
> feature in pcbnew and propagate that change to eeschema. That's not so
> difficult to do in eeshcema and update the board, but often it would feel
> much more natural to e.g. test if 0402 R package would be physically better
> for some situation than 0603 and then update the shcematic based on the
> board if it fits.
> >
> >
> >
> > Eeli Kaikkonen
> >
> >
> >
> > ___
> > 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