Re: [Kicad-developers] Branch update

[Marco Ciampa]

On Fri, Jul 27, 2018 at 03:44:06PM -0400, Wayne Stambaugh wrote:
> I just removed the 5.1 branch so there is no need to keep it synced with
> master. 

Hi Wayne,
very well, I was waiting for something like this...
if nobody has any objection (Nick?) I would make the i18n repository
follow your changes and delete the 5.1 branch.
This move will semplify the translation of the dev version and will
allow users to best check for the translation in the day-to-day use.

TIA

Best,

-- 


Marco Ciampa

I know a joke about UDP, but you might not get it.



 GNU/Linux User #78271
 FSFE fellow #364




___
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] Scripting action menu in packages

[Wayne Stambaugh]

The problem here is not the maturity of the scripting menu support but
rather the scripts themselves.  I'm fine with enabling this for 5.0.1.
In the end the user will bear the responsibility of bad scripts although
we will end up with the headache of supporting it.  Much like many of
the issue with the wxPython scripting support.  It takes one bug in a
python script to bring KiCad to it's knees.

Wayne

On 07/27/2018 06:03 PM, Adam Wolf wrote:
> How about we make it officially included in 5.1?
> 
> 
> 
> On Fri, Jul 27, 2018, 4:29 PM Simon Richter  > wrote:
> 
> Hi,
> 
> On 27.07.2018 21:57, Adam Wolf wrote:
> 
> > Do we think the scripting menu stuff will be mature enough to turn
> on by
> > default soon?
> 
> It's enabled in the nightlies, but disabled in the release build. One
> user has complained already[1], and I've given them a build with the
> action menu enabled and a request to report problems.
> 
> I haven't moved this to the "stable" directory though, because I'm not
> sure it's supposed to be released, but I need a decision soon before
> more users have different versions with the same number.
> 
>    Simon
> 
> [1] https://bugs.launchpad.net/kicad/+bug/1783690
> 
> ___
> 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] Scripting action menu in packages

[Adam Wolf]

How about we make it officially included in 5.1?



On Fri, Jul 27, 2018, 4:29 PM Simon Richter 
wrote:

> Hi,
>
> On 27.07.2018 21:57, Adam Wolf wrote:
>
> > Do we think the scripting menu stuff will be mature enough to turn on by
> > default soon?
>
> It's enabled in the nightlies, but disabled in the release build. One
> user has complained already[1], and I've given them a build with the
> action menu enabled and a request to report problems.
>
> I haven't moved this to the "stable" directory though, because I'm not
> sure it's supposed to be released, but I need a decision soon before
> more users have different versions with the same number.
>
>Simon
>
> [1] https://bugs.launchpad.net/kicad/+bug/1783690
>
> ___
> 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] Scripting action menu in packages

[Simon Richter]

Hi,

On 27.07.2018 21:57, Adam Wolf wrote:

> Do we think the scripting menu stuff will be mature enough to turn on by
> default soon?

It's enabled in the nightlies, but disabled in the release build. One
user has complained already[1], and I've given them a build with the
action menu enabled and a request to report problems.

I haven't moved this to the "stable" directory though, because I'm not
sure it's supposed to be released, but I need a decision soon before
more users have different versions with the same number.

   Simon

[1] https://bugs.launchpad.net/kicad/+bug/1783690



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

[Kicad-developers] Scripting action menu in packages

[Adam Wolf]

Hi folks!

Do we think the scripting menu stuff will be mature enough to turn on by
default soon?

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

[Kicad-developers] Branch update

[Wayne Stambaugh]

I just removed the 5.1 branch so there is no need to keep it synced with
master.  That only leaves the matter of versioning.  I am tempted to go
with Simon's suggesting and just use 5.0.0 as the tag and 5.0.0-unknown
as the version string in KiCadVersion.txt.  I know this will cause
issues for users who have already installed 6.0.0-rc1-dev but I really
don't know what else to do.  Users will just have to be confused.  IMO,
the package sorting issue is more important than coming up with a
version tag to appease all users.  If someone has better idea, now is
the time to speak up.

Also, just a reminder.  If you fix a bug that exists in the stable 5
branch, please do not forget to cherry-pick it from master and merge it
into the stable 5 branch.  I don't have time to keep up with the current
commit volume so I'm going to have to depend on the original committer
to make sure the 5.0 branch is correct.  We will probably have a fairly
short 5.0.1 development period due to the severity of some of the bugs
that have already been reported.

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

Re: [Kicad-developers] [RFC] Op-amp symbol icons

[Jeff Young]

Hi Kevin,

These are the icons used in the toolbars and menus, not the symbols used on the 
canvas.

Cheers,
Jeff.

> On 27 Jul 2018, at 16:12, Kevin Cozens  wrote:
> 
> On 2018-07-26 06:00 AM, Andrey Kuznetsov wrote:
>> Hmm, tough choice
> [snip]
>> The reason I kept 6C is because the other icons might only look good in 1px 
>> body.
>> 6D looks too close and 6B looks too far, so unless there's an intermediate 
>> that'll look good (doesn't matter if it's on the grid or not) then the 
>> concession has to be made towards one or the other based again on how the 
>> other icons might look.
> 
> the images are too small for me to tell which one I would prefer to see in a 
> schematic. I would need to see them in context.
> 
> All I ask is that if someone is going to mess around with the symbol for one 
> of the more commonly used schematic symbols that you keep the same size and 
> position of the pins. This will avoid breaking existing schematics. The last 
> time someone changed the R symbol it was made narrower and the two pins of 
> the part no longer extended out far enough to meet up with the wires on my 
> schematics. I had to adjust all the wires going to a resistor to reconnect 
> them.
> 
> -- 
> 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] [RFC] Op-amp symbol icons

[Kevin Cozens]

On 2018-07-26 06:00 AM, Andrey Kuznetsov wrote:

Hmm, tough choice

[snip]
The reason I kept 6C is because the other icons might only look good in 1px 
body.


6D looks too close and 6B looks too far, so unless there's an intermediate 
that'll look good (doesn't matter if it's on the grid or not) then the 
concession has to be made towards one or the other based again on how the 
other icons might look.


the images are too small for me to tell which one I would prefer to see in a 
schematic. I would need to see them in context.


All I ask is that if someone is going to mess around with the symbol for one 
of the more commonly used schematic symbols that you keep the same size and 
position of the pins. This will avoid breaking existing schematics. The last 
time someone changed the R symbol it was made narrower and the two pins of 
the part no longer extended out far enough to meet up with the wires on my 
schematics. I had to adjust all the wires going to a resistor to reconnect them.


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

[Kicad-developers] [PATCH] [5.1] Add missing colon

[Simon Richter]

---
 pcbnew/dialogs/dialog_plot.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/pcbnew/dialogs/dialog_plot.cpp b/pcbnew/dialogs/dialog_plot.cpp
index 04ad117a7..e43008cc6 100644
--- a/pcbnew/dialogs/dialog_plot.cpp
+++ b/pcbnew/dialogs/dialog_plot.cpp
@@ -495,7 +495,7 @@ void DIALOG_PLOT::SetPlotFormat( wxCommandEvent& event )
 OnChangeDXFPlotMode( event );
 break;
 
-case PLOT_FORMAT_UNDEFINED
+case PLOT_FORMAT_UNDEFINED:
 break;
 }
 
___
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 to draw bitmaps in GAL canvases

[jp charras]

Le 27/07/2018 à 15:20, Tomasz Wlostowski a écrit :
> On 27/07/18 13:28, jp charras wrote:
>> Le 26/07/2018 à 18:13, Mário Luzeiro a écrit :
>>> Hi JP,
>>> Don't know about CAIRO, but a "for xy DrawRectangle" it is too heavy.
>>
>> In fact "for xy DrawRectangle" is used only to convert the wxWidgets 
>> internal image format to the
>> Cairo internal image format.
>> The cost is low, because it is executed only once for a new bitmap.
>>
>>> >From what I remember from OPENGL_GAL the proper way to develop it would be 
>>> >by adding a new "draw element" using a new shader for draw a texture and 
>>> >by uploading the images data to GPU textures.
>>>
>>> I believe the GAL specialists will have a good understanding how to add 
>>> that feature.
>>
> Hi JP,
> 
> I'll have a look.
> 
> Tom
> 

Thanks.

-- 
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] Patch to draw bitmaps in GAL canvases

[Tomasz Wlostowski]

On 27/07/18 13:28, jp charras wrote:
> Le 26/07/2018 à 18:13, Mário Luzeiro a écrit :
>> Hi JP,
>> Don't know about CAIRO, but a "for xy DrawRectangle" it is too heavy.
> 
> In fact "for xy DrawRectangle" is used only to convert the wxWidgets internal 
> image format to the
> Cairo internal image format.
> The cost is low, because it is executed only once for a new bitmap.
> 
>> >From what I remember from OPENGL_GAL the proper way to develop it would be 
>> >by adding a new "draw element" using a new shader for draw a texture and by 
>> >uploading the images data to GPU textures.
>>
>> I believe the GAL specialists will have a good understanding how to add that 
>> feature.
> 
Hi JP,

I'll have a look.

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] [PATCH] qa_geometry tests

[Wayne Stambaugh]

John,

I finally go around to merging your patch set.  I'm assuming this patch
set will apply to the stable 5 branch as well.  Thank you for your
contribution to KiCad.

Cheers,

Wayne

On 07/10/2018 11:55 AM, John Beard wrote:
> Hi Wayne,
> 
> (Feel free to tell me to come back to this later if busy with v5!)
> 
> On closer inspection, qa_geometry is NOT a general test of geometry
> code, but rather a few tests to ensure that some refactored code
> (SHAPE_POLY_SET) matches the original CPolyLine-based code.
> 
> As for the fillet code testing, I had a go at making some actual tests
> for the SHAPE_POLY_SET. It basically does the following for a few
> combinations of radius/error:
> 
> 1) Make a square shape
> 2) Fillet it
> 3) Check there's a single resulting polygon
> 4) Look at the segments generated by the code and ensure that:
> a) The end points are the right distance from the radius centre
> b) The mid point error from the ideal arc is within tolerance
> c) The line is (roughly, due to rounding) perpendicular to the
> line joining midpoint and radius centre
> 5) Check the fillet is at least one segment
> 
> These tests do appear to pass for the SHAPE_POLY_SET code.
> 
> You could also do testing against expected co-ordinate results, but
> that requires that the Fillet code contracts to return exact,
> reproducible result, not just "good enough to fit the given error, but
> with latitude within that brief".
> 
> Attached are some patches to illustrate what I am talking about. I'm
> not asking to merge before v5, though I believe the first three are
> generally harmless in that respect, as they just enable ctest, add the
> working qa_geometry tests (renamed to qa_shape_poly_set_refactor) and
> add the Python tests.
> 
> The fourth is the new fillet tests, which are still just a concept,
> though feedback is welcome.
> 
> Cheers,
> 
> John
> 
> On Tue, Jul 10, 2018 at 4:12 PM, Wayne Stambaugh  wrote:
>> I'm not sure what bothers me more, the fact the test fails or the fact
>> that the test used  different fillet code as the pass/fail criteria
>> rather than a hard coded known correct test.  Which fillet code was/is
>> correct?  We really do need to start doing a better job with our
>> geometry tests and testing in general.  Is the fillet code we use to
>> generate polygons and other geometry actually correct?
>>
>> As far as fixing qa tests, I don't think that will impact the v5 release
>> but pushing it off to 5.0.1 or 5.1 probably makes more sense at this
>> point.  I do agree that there should be an easier way to run tests.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 7/9/2018 5:35 AM, John Beard wrote:
>>> Note to Wayne: Nothing here concerns v5 release, I was just trying to
>>> get a geom test working for future.
>>>
>>> On Mon, Jul 9, 2018 at 9:12 AM, John Beard  wrote:
 Hi,

 Let's come back to the make test behaviour after v5, I think we'll
 need to discuss that separately. However, I think this does illustrate
 why we need the tests to be runnable easily, otherwise they suffer
 bit-rot, and then the tests are useless.

 Looking at that change, the test is now iterating the second parameter
 which is now "max error", not "number of segments". Does this test
 still make any sense? It's now comparing:

 SHAPE_POLY_SET::Fillet( radius, error );

 with

 CPolyLine::Fillet( radius, segments );

 The original test was designed to ensure SHAPE_POLY_SET::Fillet and
 CPolyLine::Fillet were the same, but they now have different
 interfaces and semantics. Wouldn't it be better to check
 SHAPE_POLY_SET::Fillet (and Chamfer) against some ground truth?

 Cheers,

 John

 On Fri, Jul 6, 2018 at 8:40 PM, Nick Østergaard  wrote:
> Hi
>
> I guess we could add it to the qa target somehow? What I don't 
> particularyly
> like with this patch is that executing "make test" does not check for
> dependency changes.
>
> Back to the status about qa_geometry... it did pass a long time ago, 
> doing a
> bit of git bisect points at this commit as the one breaking the test.
>
> fbf10e941bdf26bb3618aba0a1b7c44fd0bafed2 is the first bad commit
> commit fbf10e941bdf26bb3618aba0a1b7c44fd0bafed2
> Author: Jeff Young
> Date:   Thu Mar 22 18:02:45 2018 +
>
> Switch zone fillets to absolute-error algorithm.
>
> And some general cleanup to related constants, etc.
>
> :04 04 8b6ad8d44a7b38e0355ce5c8897f823d6255f811
> 8d54d43a9bd6e5062d6b804890a779e785e430cc Mcommon
> :04 04 5a90dc20fe7cb3f74ae1768a5b5024a902c9354d
> a2be92ebd64fd46ad17427e8e3c12da7f10df699 Minclude
> :04 04 af9f333c0f56dca3a90fb7b04f385dbf39425e8d
> 99b5f9757c78216a08220b7eb056f343658b961d Mpcbnew
>
>
> Den tor. 5. jul. 2018 kl. 12.13 skrev John Beard :
>>
>> Hi,
>>
>> Are 

Re: [Kicad-developers] Patch to draw bitmaps in GAL canvases

[jp charras]

Le 26/07/2018 à 18:13, Mário Luzeiro a écrit :
> Hi JP,
> Don't know about CAIRO, but a "for xy DrawRectangle" it is too heavy.

In fact "for xy DrawRectangle" is used only to convert the wxWidgets internal 
image format to the
Cairo internal image format.
The cost is low, because it is executed only once for a new bitmap.

>>From what I remember from OPENGL_GAL the proper way to develop it would be by 
>>adding a new "draw element" using a new shader for draw a texture and by 
>>uploading the images data to GPU textures.
> 
> I believe the GAL specialists will have a good understanding how to add that 
> feature.

Yes, I think so..

> 
> Mário Luzeiro

Thanks.

> 
> 
> From: Kicad-developers 
>  on behalf of 
> jp charras 
> Sent: 26 July 2018 10:46:33
> To: Kicad Developers
> Subject: [Kicad-developers] Patch to draw bitmaps in GAL canvases
> 
> Hi, GAL gurus,
> 
> I wrote this fix that add the code to draw bitmaps that can be used in page 
> layout editor and eeschema.
> (Currently, this code is missing, and bitmaps used in page layout are shown 
> in legacy canvas, but
> not in GAL canvases)
> 
> I need a GAL guru to verify this patch (I am not a OpenGL or Cairo 
> specialist).
> I do not want to break something.
> 
> I am thinking the Cairo code is good.
> In opengl canvas, I am using a "brute force" code to draw pixels as 
> rectangles.
> I tried other ways, but there did not work.
> 
> Thanks.
> 
> --
> Jean-Pierre CHARRAS
> 


-- 
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] [RFC] Op-amp symbol icons

[Jeff Young]

Hi John,

Just an update on the opamp icon list.  These icons:

copycomponent.svg
edit_component.svg
edit_part.svg
import_cmp_from_lib.svg
save_part.svg
save_part_in_mem.svg

no longer exist.

Cheers,
Jeff.


> On 26 Jul 2018, at 09:33, Jeff Young  wrote:
> 
> Hi John,
> 
> Most other icons use a heavier pen width (see the DeMorgan symbols, pin 
> graphics, etc.), which would favour the B column.
> 
> I like the wider stance of the input pins in row 4.
> 
> BTW, the new black-and-white 16x16 icons for the dialog buttons also suffer 
> from slight blurryness.  I don’t know if they’re worth fixing or not, but if 
> you’re so inclined….
> 
> Cheers,
> Jeff.
> 
> 
>> On 25 Jul 2018, at 15:05, John Beard > > wrote:
>> 
>> Hi,
>> 
>> The pixel alignment of the op-amp icons looks a bit fuzzy compared to
>> the other newer icons. These are not the only misaligned icons, but
>> they are a very prominent set of them.
>> 
>> The problem is that both:
>> 
>> 1) The lines are not on the pixel grid
>> 2) The lines are not a whole number of pixels wide.
>> 
>> If this *were* to be changed so horizontal lines are sharp, the icons
>> have to be modified. However, going up to 2px or down to 1px line
>> width changes the feel a bit.
>> 
>> Attached are some options (for the full size op-amp icons at 26px). If
>> a consensus or executive decision ever emerges, I will produce a patch
>> for the op-amp icons in that style.
>> 
>> Personally, my "vote" is 2A, or 5A for icons where the symbol is
>> smaller, like "copycomponent".
>> 
>> List of icons affected for reference:
>> 
>> add_component.svg
>> copycomponent.svg
>> edit_cmp_symb_links.svg
>> edit_comp_footprint.svg
>> edit_comp_ref.svg
>> edit_comp_value.svg
>> edit_component.svg
>> edit_part.svg
>> export_part.svg
>> field_properties.svg
>> hidden_pin.svg
>> icon_libedit.svg
>> import_cmp_from_lib.svg
>> import_part.svg
>> libedit.svg
>> new_component.svg
>> new_cvpcb.svg
>> part_properties.svg
>> save_part.svg
>> save_part_in_mem.svg
>> 
>> Yours, bike-sheddingly,
>> 
>> John
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers 
>> 
>> Post to : kicad-developers@lists.launchpad.net 
>> 
>> Unsubscribe : https://launchpad.net/~kicad-developers 
>> 
>> More help   : https://help.launchpad.net/ListHelp 
>> 
> 

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

Re: [Kicad-developers] Fix CMakeLists.txt

[Aimylios]

Hi Orson,

perfect, thank you very much!

Best regards,
Marcus

Am 27.07.2018 um 09:13 schrieb Maciej Sumiński:

Hi Marcus,

Actually my memory has let my down this time. I have just checked the
patch on msys2 and it worked as expected, so I recommitted the original
version. Sorry for the noise.

Cheers,
Orson

On 07/26/2018 11:36 PM, Aimylios wrote:

Hi Orson,

thank you for taking the time to review and merge my patches!


Thank you for the patches, I have just merged them. I have slightly
modified the last patch - I realize that you used the correct convention
for calling execute_process(), but IIRC it did not work with msys2.
Therefore I simply added the suggested ${wxWidgets_CONFIG_OPTIONS} to
the command line and preserved "sh -c".


Unfortunately, your modified version of my third patch does not work for
me. The reason is that wxWidgets_CONFIG_OPTIONS is of type LIST (not
STRING).

This is the command I use to configure KiCad:
cmake \
     -DKICAD_SCRIPTING_WXPYTHON=OFF \
     -DKICAD_SPICE=OFF \
     -DCMAKE_BUILD_TYPE=Release \
     -DwxWidgets_CONFIG_EXECUTABLE=/usr/bin/wx-config \
     -DwxWidgets_CONFIG_OPTIONS=--toolkit=gtk2 \
     .

With this, the expression:
sh -c "${wxWidgets_CONFIG_EXECUTABLE} ${wxWidgets_CONFIG_OPTIONS}
--query-toolkit"

evaluates to:
sh -c "/usr/bin/wx-config --toolkit=gtk2;--static=no --query-toolkit"

and the semicolon (which separates the elements of the list) terminates
the command line. Consequently, both --static=no and --query-toolkit are
dropped. Instead, you get an error message like "sh: --static=no:
command not found." and the build script incorrectly assumes that GTK2
is used, even if we added --toolkit=gtk3 before.

I don't have an msys2 build environment, but maybe someone who has can
try to check if your memory serves you right and the "correct
convention" does not work.
We might then have to find an alternative solution. But I am not a CMake
guru, so any help is appreciated.

Best regards,
Marcus


___
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] Fix CMakeLists.txt

[Maciej Sumiński]

Hi Marcus,

Actually my memory has let my down this time. I have just checked the
patch on msys2 and it worked as expected, so I recommitted the original
version. Sorry for the noise.

Cheers,
Orson

On 07/26/2018 11:36 PM, Aimylios wrote:
> Hi Orson,
> 
> thank you for taking the time to review and merge my patches!
> 
>> Thank you for the patches, I have just merged them. I have slightly
>> modified the last patch - I realize that you used the correct convention
>> for calling execute_process(), but IIRC it did not work with msys2.
>> Therefore I simply added the suggested ${wxWidgets_CONFIG_OPTIONS} to
>> the command line and preserved "sh -c".
> 
> Unfortunately, your modified version of my third patch does not work for
> me. The reason is that wxWidgets_CONFIG_OPTIONS is of type LIST (not
> STRING).
> 
> This is the command I use to configure KiCad:
> cmake \
>     -DKICAD_SCRIPTING_WXPYTHON=OFF \
>     -DKICAD_SPICE=OFF \
>     -DCMAKE_BUILD_TYPE=Release \
>     -DwxWidgets_CONFIG_EXECUTABLE=/usr/bin/wx-config \
>     -DwxWidgets_CONFIG_OPTIONS=--toolkit=gtk2 \
>     .
> 
> With this, the expression:
> sh -c "${wxWidgets_CONFIG_EXECUTABLE} ${wxWidgets_CONFIG_OPTIONS}
> --query-toolkit"
> 
> evaluates to:
> sh -c "/usr/bin/wx-config --toolkit=gtk2;--static=no --query-toolkit"
> 
> and the semicolon (which separates the elements of the list) terminates
> the command line. Consequently, both --static=no and --query-toolkit are
> dropped. Instead, you get an error message like "sh: --static=no:
> command not found." and the build script incorrectly assumes that GTK2
> is used, even if we added --toolkit=gtk3 before.
> 
> I don't have an msys2 build environment, but maybe someone who has can
> try to check if your memory serves you right and the "correct
> convention" does not work.
> We might then have to find an alternative solution. But I am not a CMake
> guru, so any help is appreciated.
> 
> Best regards,
> Marcus




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