Re: [Kicad-developers] Kicad 6 API

[Tim Hawkins]

Would it be possible to consider using swig to create the Python Bindings,
so that it will be easy to create bindings for other languages than just
Python, Java, Kotlin or Rust would be of interest to me.

On Tue, Jul 14, 2020 at 1:06 AM Jon Evans  wrote:

> Hi Conrad,
>
> We are working towards removing all the UI dependencies (already the
> latest state-of-the-art is way better than the 5.1 branch in this
> regard).  We are also working towards a more stable Python API.
>
> One of the goals of this work is to enable some of the features you
> mentioned (automated generation of outputs, etc).
>
>
> On Mon, Jul 13, 2020 at 11:06 AM Conrad Wood 
> wrote:
> > > > I've seen various 'hacks' out there to provide a graphical 'diff'.
> > > > I
> > > > would like to see the API either provide means to do a diff on two
> > > > commits of the same repository, graphical or otherwise, in such a
> > > > way
> > > > that it can be integrated into a web-based process.
> > > > (with "diff" I mean a method to see where and what changes were
> > > > made in
> > > > two versions by a person not trained to do PCB design. - this is
> > > > mostly
> > > > to review changes and spot unintended modifications)
>
> https://gitlab.com/kicad/code/kicad/-/issues/3865
> https://gitlab.com/kicad/code/kicad/-/issues/2151
>
> This wish doesn't actually have much to do with code that is tied to
> the UI, it is just a fairly big project that nobody has started on.
>
> > > > On bigger/complex boards, there are often 'sections' which are
> > > > handled
> > > > by exports. for example, radio vs memory/cpu vs powersupply. It
> > > > would
> > > > absolutely awesome if we can progress KiCad to support such teams.
> > > > In
> > > > my mind, I am thinking of a KiCad server which serves clients and
> > > > sections can be 'locked' and worked on simultaneously.
> > > > Simultaneously I
> > > > mean, with changes being propagated to each KiCad Client in real-
> > > > time.
>
> I'm familiar with this functionality but I don't think anyone has yet
> put serious thought into it for KiCad yet (I don't think there's an
> open issue tracking it, nor a spec or any kind of roadmap).
>
> Perhaps the best way to start would be to make some more formal detail
> of the requirements (in the form of a wishlist issue on GitLab) and we
> can start figuring out the technical challenges.
>
> > I am quite aware that this is a lot of changes. I don't suggest that we
> > do everything at once. What I'd like to see though, is that there is a
> > long term view of where we want to take APIs and the GUI/Library split
> > (currently not even certain if that is the planned approach).
>
> The current planned approach is to ensure clean separation between the
> UI and the rest of the code, and to expose a stable API via Python for
> people to extend and automate KiCad with.
>
> >
> > a) what is the decision making process for KiCad-Dev for such long-term
> > changes?
>
> Long-term plans need buy-in from the lead developer team (and Wayne,
> as project lead, is final arbiter of things where we can't reach
> consensus).
>
> This mailing list is a reasonable place to discuss things (especially
> general things) before any decision is made.  Discussing specific
> ideas on a GitLab issue related to the idea is also good.
>
> > b) how does KiCad-Dev deal with large-ish changes that may span
> > multiple releases or reach further in the future than, say, a feature
> > request or a bug report?
>
> We use roadmaps, and since the move to GitLab also the Epics feature
> of that tool, to track large sets of changes that span multiple
> releases.
>
> > c) How can I help? :)
>
> If you are interested in contributing code, my recommendation is to
> start small and submit some patches for existing issues while you get
> familiar with KiCad's architecture.
>
> Understanding the current architecture is important to be able to
> contribute to planning any future architecture changes.
>
> There is a list of issues tagged "starter" that means one of the
> developers thought this issue might be more approachable to someone
> new to the codebase:
>
>
> https://gitlab.com/kicad/code/kicad/-/issues?scope=all=%E2%9C%93=opened_name[]=starter
>
> Hope this helps!
>
> Best,
> 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] Error creating merge request for 1st diff

[Joshua Redstone]

Thanks Andrew and Jon - that helped me figure it out. I think I just
successfully submitted my first merge request (# 282).
-Josh


On Mon, Jul 13, 2020 at 1:09 PM Jon Evans  wrote:

> Good point, Andrew.
>
> I normally have my fork as "origin" (which will be the default when
> doing push/pull operations).
>
> I set the main KiCad repository as a remote called "upstream" (this
> name is just my personal choice, it can be anything)
>
> That way by default I am just interacting with my fork, but I can
> specify the upstream remote if I am rebasing my changes on top of the
> latest in the main repository.
>
> Some more detail here on how to add, view and rename remotes:
>
> https://git-scm.com/book/en/v2/Git-Basics-Working-with-Remotes
>
> -Jon
>
> On Mon, Jul 13, 2020 at 12:58 PM Andrew Lutsenko 
> wrote:
> >
> > Hi,
> >
> > You are probably trying to push to kicad repo instead of your fork.
> > Instead of doing "git push" you should do "git push  corresponding to your fork>" unless your fork remote is "origin".
> > Once you have pushed to your fork git client will give you a direct link
> to create a merge request from that branch.
> >
> > Best,
> > Andrew
> >
> > On Mon, Jul 13, 2020 at 9:25 AM Joshua Redstone 
> wrote:
> >>
> >> Hi,
> >> I've prepared a diff for the raytracing engine in 3d-viewer.  It more
> conservatively clips silkscreen around vias to the edge of the outer
> annular ring rather than edge of the copper plating.
> >> I wanted to get some feedback on it, but when I tried creating a merge
> request by doing a git-push, I got the "You are not allowed to push code to
> this project." error.
> >>
> >> Is there another way I should proceed to get feedback on the diff?
> >> One question on the diff I had was I wasn't sure where / if / how to
> hook up the flag enabling the change.
> >>
> >> Thanks,
> >> Josh
> >>
> >> ___
> >> 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] Error creating merge request for 1st diff

[Jon Evans]

Good point, Andrew.

I normally have my fork as "origin" (which will be the default when
doing push/pull operations).

I set the main KiCad repository as a remote called "upstream" (this
name is just my personal choice, it can be anything)

That way by default I am just interacting with my fork, but I can
specify the upstream remote if I am rebasing my changes on top of the
latest in the main repository.

Some more detail here on how to add, view and rename remotes:

https://git-scm.com/book/en/v2/Git-Basics-Working-with-Remotes

-Jon

On Mon, Jul 13, 2020 at 12:58 PM Andrew Lutsenko  wrote:
>
> Hi,
>
> You are probably trying to push to kicad repo instead of your fork.
> Instead of doing "git push" you should do "git push  corresponding to your fork>" unless your fork remote is "origin".
> Once you have pushed to your fork git client will give you a direct link to 
> create a merge request from that branch.
>
> Best,
> Andrew
>
> On Mon, Jul 13, 2020 at 9:25 AM Joshua Redstone  wrote:
>>
>> Hi,
>> I've prepared a diff for the raytracing engine in 3d-viewer.  It more 
>> conservatively clips silkscreen around vias to the edge of the outer annular 
>> ring rather than edge of the copper plating.
>> I wanted to get some feedback on it, but when I tried creating a merge 
>> request by doing a git-push, I got the "You are not allowed to push code to 
>> this project." error.
>>
>> Is there another way I should proceed to get feedback on the diff?
>> One question on the diff I had was I wasn't sure where / if / how to hook up 
>> the flag enabling the change.
>>
>> Thanks,
>> Josh
>>
>> ___
>> 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] Kicad 6 API

[Jon Evans]

Hi Conrad,

We are working towards removing all the UI dependencies (already the
latest state-of-the-art is way better than the 5.1 branch in this
regard).  We are also working towards a more stable Python API.

One of the goals of this work is to enable some of the features you
mentioned (automated generation of outputs, etc).


On Mon, Jul 13, 2020 at 11:06 AM Conrad Wood  wrote:
> > > I've seen various 'hacks' out there to provide a graphical 'diff'.
> > > I
> > > would like to see the API either provide means to do a diff on two
> > > commits of the same repository, graphical or otherwise, in such a
> > > way
> > > that it can be integrated into a web-based process.
> > > (with "diff" I mean a method to see where and what changes were
> > > made in
> > > two versions by a person not trained to do PCB design. - this is
> > > mostly
> > > to review changes and spot unintended modifications)

https://gitlab.com/kicad/code/kicad/-/issues/3865
https://gitlab.com/kicad/code/kicad/-/issues/2151

This wish doesn't actually have much to do with code that is tied to
the UI, it is just a fairly big project that nobody has started on.

> > > On bigger/complex boards, there are often 'sections' which are
> > > handled
> > > by exports. for example, radio vs memory/cpu vs powersupply. It
> > > would
> > > absolutely awesome if we can progress KiCad to support such teams.
> > > In
> > > my mind, I am thinking of a KiCad server which serves clients and
> > > sections can be 'locked' and worked on simultaneously.
> > > Simultaneously I
> > > mean, with changes being propagated to each KiCad Client in real-
> > > time.

I'm familiar with this functionality but I don't think anyone has yet
put serious thought into it for KiCad yet (I don't think there's an
open issue tracking it, nor a spec or any kind of roadmap).

Perhaps the best way to start would be to make some more formal detail
of the requirements (in the form of a wishlist issue on GitLab) and we
can start figuring out the technical challenges.

> I am quite aware that this is a lot of changes. I don't suggest that we
> do everything at once. What I'd like to see though, is that there is a
> long term view of where we want to take APIs and the GUI/Library split
> (currently not even certain if that is the planned approach).

The current planned approach is to ensure clean separation between the
UI and the rest of the code, and to expose a stable API via Python for
people to extend and automate KiCad with.

>
> a) what is the decision making process for KiCad-Dev for such long-term
> changes?

Long-term plans need buy-in from the lead developer team (and Wayne,
as project lead, is final arbiter of things where we can't reach
consensus).

This mailing list is a reasonable place to discuss things (especially
general things) before any decision is made.  Discussing specific
ideas on a GitLab issue related to the idea is also good.

> b) how does KiCad-Dev deal with large-ish changes that may span
> multiple releases or reach further in the future than, say, a feature
> request or a bug report?

We use roadmaps, and since the move to GitLab also the Epics feature
of that tool, to track large sets of changes that span multiple
releases.

> c) How can I help? :)

If you are interested in contributing code, my recommendation is to
start small and submit some patches for existing issues while you get
familiar with KiCad's architecture.

Understanding the current architecture is important to be able to
contribute to planning any future architecture changes.

There is a list of issues tagged "starter" that means one of the
developers thought this issue might be more approachable to someone
new to the codebase:

https://gitlab.com/kicad/code/kicad/-/issues?scope=all=%E2%9C%93=opened_name[]=starter

Hope this helps!

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

Re: [Kicad-developers] Error creating merge request for 1st diff

[Andrew Lutsenko]

Hi,

You are probably trying to push to kicad repo instead of your fork.
Instead of doing "git push" you should do "git push " unless your fork remote is "origin".
Once you have pushed to your fork git client will give you a direct link to
create a merge request from that branch.

Best,
Andrew

On Mon, Jul 13, 2020 at 9:25 AM Joshua Redstone  wrote:

> Hi,
> I've prepared a diff for the raytracing engine in 3d-viewer.  It more
> conservatively clips silkscreen around vias to the edge of the outer
> annular ring rather than edge of the copper plating.
> I wanted to get some feedback on it, but when I tried creating a merge
> request by doing a git-push, I got the "You are not allowed to push code to
> this project." error.
>
> Is there another way I should proceed to get feedback on the diff?
> One question on the diff I had was I wasn't sure where / if / how to hook
> up the flag enabling the change.
>
> Thanks,
> Josh
>
> ___
> 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] Error creating merge request for 1st diff

[Jon Evans]

Hi Josh,

Please see the GitLab documentation on how to create a MR:
https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html

We also have some KiCad-specific MR guidelines:
https://gitlab.com/kicad/code/kicad/-/wikis/Merge-Request-Guidelines

In general: you will need to have your own fork of the KiCad
repository on your personal GitLab account, then push your work to a
new branch on that fork.  You then create a MR in the main KiCad
repository with the target set to your personal fork and branch.

Best,
Jon

On Mon, Jul 13, 2020 at 12:24 PM Joshua Redstone  wrote:
>
> Hi,
> I've prepared a diff for the raytracing engine in 3d-viewer.  It more 
> conservatively clips silkscreen around vias to the edge of the outer annular 
> ring rather than edge of the copper plating.
> I wanted to get some feedback on it, but when I tried creating a merge 
> request by doing a git-push, I got the "You are not allowed to push code to 
> this project." error.
>
> Is there another way I should proceed to get feedback on the diff?
> One question on the diff I had was I wasn't sure where / if / how to hook up 
> the flag enabling the change.
>
> Thanks,
> Josh
>
> ___
> 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] Error creating merge request for 1st diff

[Joshua Redstone]

Hi,
I've prepared a diff for the raytracing engine in 3d-viewer.  It more
conservatively clips silkscreen around vias to the edge of the outer
annular ring rather than edge of the copper plating.
I wanted to get some feedback on it, but when I tried creating a merge
request by doing a git-push, I got the "You are not allowed to push code to
this project." error.

Is there another way I should proceed to get feedback on the diff?
One question on the diff I had was I wasn't sure where / if / how to hook
up the flag enabling the change.

Thanks,
Josh
___
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] Kicad 6 API

[Conrad Wood]

On Mon, 2020-07-13 at 15:09 +0200, Simon Richter wrote:
> Hi Conrad,
> 
> On 13.07.20 14:48, Conrad Wood wrote:
> 
> > I am keen on generating the outputs for manufacturing and
> > documentation
> > (e.g. circuit diagram pdfs, rendered 3d-view of pcb) as part of a
> > git
> > hook.
> 
> There is still some UI code inside the data representation, so for
> now
> scripting can only control a GUI instance. This is kind of annoying
> for
> git hooks as you need to set up a fake display server.

Exactly. I feel understood and I am pleased that this is a "known"
annoyance rather than an "unknown" one :)

> 
> > I've seen various 'hacks' out there to provide a graphical 'diff'.
> > I
> > would like to see the API either provide means to do a diff on two
> > commits of the same repository, graphical or otherwise, in such a
> > way
> > that it can be integrated into a web-based process.
> > (with "diff" I mean a method to see where and what changes were
> > made in
> > two versions by a person not trained to do PCB design. - this is
> > mostly
> > to review changes and spot unintended modifications)
> 
> diff/merge is non-trivial, because PCB structures are three-
> dimensional
> while files are one-dimensional strings of bytes. Anything that is
> able
> to generate meaningful diffs would need to fully understand the
> files,
> not just look for similarities.

Indeed. That's why I think much of the parsing and 'understanding' of
the files should be moved out of the GUI and into a library. Then we
can have an API for it and can start building on top of it.

> 
> > On bigger/complex boards, there are often 'sections' which are
> > handled
> > by exports. for example, radio vs memory/cpu vs powersupply. It
> > would
> > absolutely awesome if we can progress KiCad to support such teams.
> > In
> > my mind, I am thinking of a KiCad server which serves clients and
> > sections can be 'locked' and worked on simultaneously.
> > Simultaneously I
> > mean, with changes being propagated to each KiCad Client in real-
> > time.
> 
> That is partially a function of diff/merge, and also requires more of
> a
> notification system than we currently have (basically, we know to
> update
> *the* view when data changes, but we'd need to track multiple views
> on
> the data and add a way for data modifications to fail because of
> conflicts -- plus UI presentation for that.
> 
> That would require a lot of changes to internals.


I am quite aware that this is a lot of changes. I don't suggest that we
do everything at once. What I'd like to see though, is that there is a
long term view of where we want to take APIs and the GUI/Library split
(currently not even certain if that is the planned approach).

I am no expert at the KiCad code, but when I did look if I can add such
APIs, it became clear that there is a lot of work to do in splitting
this out. 

I guess what I am really asking, is, 

a) what is the decision making process for KiCad-Dev for such long-term 
changes? 

b) how does KiCad-Dev deal with large-ish changes that may span
multiple releases or reach further in the future than, say, a feature
request or a bug report?

c) How can I help? :)







___
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] Kicad 6 API

[Simon Richter]

Hi Conrad,

On 13.07.20 14:48, Conrad Wood wrote:

> I am keen on generating the outputs for manufacturing and documentation
> (e.g. circuit diagram pdfs, rendered 3d-view of pcb) as part of a git
> hook.

There is still some UI code inside the data representation, so for now
scripting can only control a GUI instance. This is kind of annoying for
git hooks as you need to set up a fake display server.

> I've seen various 'hacks' out there to provide a graphical 'diff'. I
> would like to see the API either provide means to do a diff on two
> commits of the same repository, graphical or otherwise, in such a way
> that it can be integrated into a web-based process.
> (with "diff" I mean a method to see where and what changes were made in
> two versions by a person not trained to do PCB design. - this is mostly
> to review changes and spot unintended modifications)

diff/merge is non-trivial, because PCB structures are three-dimensional
while files are one-dimensional strings of bytes. Anything that is able
to generate meaningful diffs would need to fully understand the files,
not just look for similarities.

> On bigger/complex boards, there are often 'sections' which are handled
> by exports. for example, radio vs memory/cpu vs powersupply. It would
> absolutely awesome if we can progress KiCad to support such teams. In
> my mind, I am thinking of a KiCad server which serves clients and
> sections can be 'locked' and worked on simultaneously. Simultaneously I
> mean, with changes being propagated to each KiCad Client in real-time.

That is partially a function of diff/merge, and also requires more of a
notification system than we currently have (basically, we know to update
*the* view when data changes, but we'd need to track multiple views on
the data and add a way for data modifications to fail because of
conflicts -- plus UI presentation for that.

That would require a lot of changes to internals.

   Simon



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

Re: [Kicad-developers] Kicad 6 API

[Conrad Wood]

On Thu, 2020-07-09 at 15:18 +0200, Nick Østergaard wrote:
> Are you talking about the python scripting API,   or what is your
> intention?

I am keen on aiding some of the processes in PCB design & manufacturing
using KiCad as the tool to provide the design of the pcb. After design,
I found that often companies struggle with the process following
thereafter. We (https://www.singingcat.net/) build PCBs with KiCad and
have found this to be a common topic. So we'd like to build a more
friendly process (web) tool, with KiCad as the PCBDesign software at
its core.


1)
I am keen on generating the outputs for manufacturing and documentation
(e.g. circuit diagram pdfs, rendered 3d-view of pcb) as part of a git
hook.

2)
I like to read BOM information so that I can export the data into a
database and manage the components outside kicad. That is, because the
components being purchased actually differ slightly from those intented
during design. (Due to availability, pricing, etc..). 

3)
I've seen various 'hacks' out there to provide a graphical 'diff'. I
would like to see the API either provide means to do a diff on two
commits of the same repository, graphical or otherwise, in such a way
that it can be integrated into a web-based process.
(with "diff" I mean a method to see where and what changes were made in
two versions by a person not trained to do PCB design. - this is mostly
to review changes and spot unintended modifications)

4)
Inserting and Tracking serial numbers on the boards during git-commit.
This is essential so we can match pcb versions and assembly serial
numbers with the right version of instructions sent to manufacturer and
to match it against any certifications that were issued to certain
revisions of boards. 

5)
On bigger/complex boards, there are often 'sections' which are handled
by exports. for example, radio vs memory/cpu vs powersupply. It would
absolutely awesome if we can progress KiCad to support such teams. In
my mind, I am thinking of a KiCad server which serves clients and
sections can be 'locked' and worked on simultaneously. Simultaneously I
mean, with changes being propagated to each KiCad Client in real-time.

For the purposes above, The python API is a bit limited in that it
1) supports python only 
2) only exposes a subset of what I need

I know that's quite a lot of work, so I thought perhaps there are
thoughts around (some of) these topics already, but could not find
documentation  about the future architecture and plans for development.

Thus I wonder, if that is an area where help would be appreciated or if
I am barking up the wrong tree so to speak :)






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

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

[Nick Østergaard]

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

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

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

Nick Østergaard

On Wed, 8 Jul 2020 at 02:08, Wayne Stambaugh  wrote:
>
> I wish I could say I was surprised.
>
> On 7/7/20 4:34 PM, Mark Roszko wrote:
> > vcpkg has a python3 build .. in fact, people actually complain vcpkg
> > wants to use its own python copy as a dependency for other libraries
> > like boost-python instead of system python (lol)
> >
> > On Tue, Jul 7, 2020 at 2:42 PM Wayne Stambaugh  > > wrote:
> >
> > This could be the straw that breaks the msvc camel's back.  If we are
> > tied to the installed Python on windows, the amount of effort required
> > to package KiCad on windows increases significantly.  Shipping KiCad
> > without Python on windows is not acceptable.
> >
> > On 7/7/20 2:36 PM, Jon Evans wrote:
> > > I am not sure there is much history of vcpkg and Python working
> > > together, so this might be breaking new ground.  It is nominally a
> > > package manager for C++ libraries, after all.
> > >
> > > On Tue, Jul 7, 2020 at 12:51 PM Wayne Stambaugh
> > mailto:stambau...@gmail.com>> wrote:
> > >>
> > >> The wxPython Phoenix build system is ugly.  Before the Phoenix
> > work, it
> > >> used to respect the Python distutils configuration.  Now it just
> > steps
> > >> all over the Python distutils settings on windows and assumes
> > that the
> > >> only build platform used on windows is msvc.
> > >>
> > >> I have experience using Python distutils to build Python
> > libraries so I
> > >> can help with this although it's been a while so I'm a bit
> > rusty.  I've
> > >> never been a big fan of distutils.  It always seemed like a
> > solution in
> > >> search of a problem to me.  There are so many config/build tools
> > that do
> > >> the same thing far less painfully.
> > >>
> > >> One problem I see is that Python distutils is very much tied to the
> > >> current Python version installed.  I don't know how vcpkg handles
> > >> Python.  Do they use the installed Python or is it packaged as a
> > stand
> > >> alone port inside vcpkg?  If they use the installed Python, this
> > >> significantly complicates things as we will have to provide a
> > build for
> > >> every supported version of Python that could be installed on someones
> > >> system.  There is a big advantage with the current way we handle
> > Python
> > >> on windows.
> > >>
> > >> On 7/7/20 8:59 AM, Jon Evans wrote:
> > >>> Yes, wxWidgets I can now use straight from vcpkg.
> > >>>
> > >>> I took a look at wxPython phoenix and the build system
> > is...something else.
> > >>> Is anyone more experienced with Python build systems?
> > >>> It seems like the happy path for vcpkg is for projects that use
> > cmake.
> > >>> This hybrid of Python and C++ with custom build system in Python
> > looks
> > >>> like a headache to integrate.
> > >>>
> > >>> I have not looked at SWIG yet.  OCC it seems like is in progress (we
> > >>> are less worried about that one)
> > >>>
> > >>> -Jon
> > >>>
> > >>> On Tue, Jul 7, 2020 at 7:31 AM Mark Roszko
> > mailto:mark.ros...@gmail.com>> wrote:
> > 
> >  Nope, I'm building straight out of vcpkg now.
> >  Jon Evans posted the patches to kicad's findwxwidgets back in
> > November fyi.
> > 
> >  On Tue, Jul 7, 2020 at 5:39 AM Nick Østergaard
> > mailto:oe.n...@gmail.com>> wrote:
> > >
> > > Hi Mark
> > >
> > > I still need to patch FindwxWidgets.cmake, using this version:
> > > https://gist.github.com/nickoe/d3c224a2587eff8ea959bc383a993520
> > >
> > > See there two vcpkg issues:
> > > https://github.com/microsoft/vcpkg/issues/1843
> > > https://github.com/microsoft/vcpkg/issues/4756
> > >
> > > I thought you were using a selfbuilt version of wxwidgets.
> > Have you
> > > started to use it directly from vcpkg?
> > >
> > > I use:
> > >
> > > cmake ^
> > >
> >  
> > -DCMAKE_TOOLCHAIN_FILE=%WORKSPACE%\vcpkg\scripts\buildsystems\vcpkg.cmake
> > ^
> > > -DCMAKE_INSTALL_PREFIX:PATH=%WORKSPACE%\install
> > > -DCMAKE_PDB_OUTPUT_DIRECTORY:PATH=%WORKSPACE%\_pdb ^
> > > -DCMAKE_RUNTIME_OUTPUT_DIRECTORY:PATH=%WORKSPACE%\_bin ^
> > > -DKICAD_SPICE=OFF ^
> > > -DKICAD_USE_OCE=OFF ^
> > > -DKICAD_SCRIPTING=OFF ^
> > >