Re: [Kicad-developers] [KiCad-developers] Hoping to contribute but I have some questions

[Seth Hillbrand]

Hi Brian-

I haven't used your tool but from the description, I think that it 
should run primarily from Eeschema.  The steps would look like:


1) (optional) Update PCB from Schematic
2) Request x/y pairs from pcbnew via KiMail
3) Renumber components in Eeschema
4) Update PCB from Schematic

This keeps the renumbering routine localized in Eeschema where the 
netlist is maintained and prevents duplication of effort with 
back-annotation.  This may or may not meet Wayne's requirements.  It 
also reduces your coding requirements substantially as you are not 
trying to re-code a bunch of update functions (it is not just component 
refdes) in pcbnew.


Best-
Seth


Am 2019-01-07 17:22, schrieb Brian Piccioni:

Wayne

I don't think a new file format is necessary. I can transfer a change
list from PCBNew to eeSchema via Kimail. This would simply be a string
or something and never surface (though, for an audit trail it might be
useful to have the changes written out as a log file, at least
optionally). Once this change list has been checked by eeSchema (in
case the schematic is not synched to the PCB), the changes would be
implemented in PCBNew and eeSchema. Then the equivalent of Update PCB
back to the PCB.

So, to summarize:
1) Generate a change list in PCBNew;
2) Using Kimail send the change list to eeSchema for quality control
(in case the schematic is out of synch with the board;
3) Once the change list has been checked, update the reference
designations on the PCB;
4) Using Kimail, direct eeSchema to update the reference designations
as per the change list;
5) After updating the schematic, eeSchema invokes an "UpdatePCB" which
a) generates a new netlist;
b) transfers that netlist to PCBNew via Kimail;
c) opens a menu to import the netlist to PCBNew.

Note that the netlist changes still flow from eeSchema to PCBNew,
however, since the reference designations on both the schematic and
the PCB have been changed in exactly the same manner, the connectivity
is not changed.

I have done this manually using edit commands in PCBNew and eeSchema
and it seems to work fine.

To reiterate, I am pretty virtually certain this can be done without
requiring a new file format and will ensure the schematic and PCB
remain in sync with the netlist.

Of course, I may be misunderstanding your point or not be well enough
versed in how things work.

Nevertheless, if I work on the code and hit a brick wall I can either
look for a solution or abandon the effort in shame.

Regards
Brian


-Original Message-
From: Wayne Stambaugh 
Sent: January 7, 2019 12:30 PM
To: Brian Piccioni ;
kicad-developers@lists.launchpad.net
Subject: Re: [KiCad-developers] Hoping to contribute but I have some 
questions


On 1/7/2019 9:49 AM, Brian Piccioni wrote:

Wayne

I looked at the source over the weekend within the context of your 
comment. In eeSchema there is a command to "Update PCB" with a 
modified netlist. This command is passed from eeSchema to PCBNew by 
Kimail. At this stage my rough program design has evolved to a sort of 
state machine where there are several interactions between PCBNew and 
eeSchema via Kimail (i.e. passing the change list, checking it for 
errors, committing the change list if no errors, etc).


This is the issue that I was talking about.  Currently netlist changes
are unidirectional from the schematic editor to the board editor.  In
order to push annotation changes from the board editor to the
schematic editor, you (or someone else) will have to implement this in
order to back annotate the revised references from the board editor to
the schematic editor.  The other option is to save an intermediate
netlist file from the board editor (which I also believe doesn't exist
yet) and import the changes into the schematic editor.  These would be
the only two solutions that I would accept but my preference is the
former.  I want to avoid yet another intermediate file format.



Since I propose to do a "dry run" of the component changes in eeSchema 
to check for errors it seems to me that executing "Update PCB" 
immediately after re-annotating the PCB and schematic would ensure 
coherency with the netlist.


As this is pretty much was a PCB designer would do if he re-annotated 
manually it should work under program control as well.


Would this address your concern or is there something else I am 
missing?


Regards

Brian

-Original Message-
From: Kicad-developers
 On Behalf Of Wayne Stambaugh
Sent: January 5, 2019 8:07 AM
To: kicad-developers@lists.launchpad.net
Subject: Re: [Kicad-developers] Hoping to contribute but I have some
questions

On 1/4/19 6:18 PM, Tomasz Wlostowski wrote:

On 04/01/2019 18:51, Brian Piccioni wrote:
I am still keen to attempt to incorporate geographical component 
annotation into KiCad. In general, it is preferable for component 
annotation to be done relative to the PCB and in some logical order 
(left/right, top to bottom, etc). Thereafter this information is 

Re: [Kicad-developers] Pulling mac 5.0.2...

[Adam Wolf]

It looks like there's something wrong with the shared library references of
just the 5.0.2 packages.  They were generated using the build script, but
not 100% automatically.  I've set Jenkins up to build those too, which
should help reduce human error next time.

This is assuming I fatfingered something in the build.

The nighties and 5.0.1 seem fine.

I have a contract delivery this week, and things are a little frantic, but
I should still be able to get this fixed.

Adam

On Mon, Jan 7, 2019, 5:46 PM Andy Peters 
>
> > On Jan 7, 2019, at 3:20 PM, Adam Wolf 
> wrote:
> >
> > Hi folks!
> >
> > Just a heads up, the macos 5.0.2 packages are gross for some reason.  I
> am regenerating them and we'll see what's going on.
> >
> > (I am regenerating them at 5.0.2-2)
>
> Gross in what way? I haven’t pulled down a nightly in a couple of weeks.
>
> -a
> ___
> 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] Pulling mac 5.0.2...

[Andy Peters]

> On Jan 7, 2019, at 3:20 PM, Adam Wolf  wrote:
> 
> Hi folks!
> 
> Just a heads up, the macos 5.0.2 packages are gross for some reason.  I am 
> regenerating them and we'll see what's going on.
> 
> (I am regenerating them at 5.0.2-2)

Gross in what way? I haven’t pulled down a nightly in a couple of weeks.

-a
___
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] Symbol library file format

[Rene Pöschl]

On 04/01/19 15:10, Wayne Stambaugh wrote:


Is there a way to mark a unit as "power unit" (I think you mentioned
sometime back that this might be required to properly make simulation
for multi unit symbols possible while still allowing the power unit to
be separate. A power unit would also be a "must be placed unit" but i
feel separating these two might add more flexibility.)


See definition above.  I'm not sure having a "required" keyword is
useful.  Do you have an example in mind.



There are many parts that not only have power connections but also some
control connections that are necessary for the function of the part.
A lot of these have the control pins shared between many units so it
makes sense to move them to a specialized unit. That unit would then be
required but does not fulfill the "this is a power unit" thing. Hence my
suggestion for a more general "this unit must be placed" vs. "This unit
is optional" field. (The "This is a power unit" thing is not really
necessary for ERC. At least not if there is a "this is a required unit"
flag. The only reason i suggested that is because you mentioned that it
might be required for simulation purposes.)


___
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-developers] Hoping to contribute but I have some questions

[Brian Piccioni]

Wayne

I don't think a new file format is necessary. I can transfer a change list from 
PCBNew to eeSchema via Kimail. This would simply be a string or something and 
never surface (though, for an audit trail it might be useful to have the 
changes written out as a log file, at least optionally). Once this change list 
has been checked by eeSchema (in case the schematic is not synched to the PCB), 
the changes would be implemented in PCBNew and eeSchema. Then the equivalent of 
Update PCB back to the PCB.

So, to summarize:
1) Generate a change list in PCBNew;
2) Using Kimail send the change list to eeSchema for quality control (in case 
the schematic is out of synch with the board;
3) Once the change list has been checked, update the reference designations on 
the PCB;
4) Using Kimail, direct eeSchema to update the reference designations as per 
the change list;
5) After updating the schematic, eeSchema invokes an "UpdatePCB" which
a) generates a new netlist;
b) transfers that netlist to PCBNew via Kimail;
c) opens a menu to import the netlist to PCBNew.

Note that the netlist changes still flow from eeSchema to PCBNew, however, 
since the reference designations on both the schematic and the PCB have been 
changed in exactly the same manner, the connectivity is not changed. 

I have done this manually using edit commands in PCBNew and eeSchema and it 
seems to work fine.

To reiterate, I am pretty virtually certain this can be done without requiring 
a new file format and will ensure the schematic and PCB remain in sync with the 
netlist.

Of course, I may be misunderstanding your point or not be well enough versed in 
how things work. 

Nevertheless, if I work on the code and hit a brick wall I can either look for 
a solution or abandon the effort in shame.

Regards
Brian


-Original Message-
From: Wayne Stambaugh  
Sent: January 7, 2019 12:30 PM
To: Brian Piccioni ; 
kicad-developers@lists.launchpad.net
Subject: Re: [KiCad-developers] Hoping to contribute but I have some questions

On 1/7/2019 9:49 AM, Brian Piccioni wrote:
> Wayne
> 
> I looked at the source over the weekend within the context of your comment. 
> In eeSchema there is a command to "Update PCB" with a modified netlist. This 
> command is passed from eeSchema to PCBNew by Kimail. At this stage my rough 
> program design has evolved to a sort of state machine where there are several 
> interactions between PCBNew and eeSchema via Kimail (i.e. passing the change 
> list, checking it for errors, committing the change list if no errors, etc).

This is the issue that I was talking about.  Currently netlist changes are 
unidirectional from the schematic editor to the board editor.  In order to push 
annotation changes from the board editor to the schematic editor, you (or 
someone else) will have to implement this in order to back annotate the revised 
references from the board editor to the schematic editor.  The other option is 
to save an intermediate netlist file from the board editor (which I also 
believe doesn't exist yet) and import the changes into the schematic editor.  
These would be the only two solutions that I would accept but my preference is 
the former.  I want to avoid yet another intermediate file format.

> 
> Since I propose to do a "dry run" of the component changes in eeSchema to 
> check for errors it seems to me that executing "Update PCB" immediately after 
> re-annotating the PCB and schematic would ensure coherency with the netlist.
> 
> As this is pretty much was a PCB designer would do if he re-annotated 
> manually it should work under program control as well.
> 
> Would this address your concern or is there something else I am missing?
> 
> Regards
> 
> Brian
> 
> -Original Message-
> From: Kicad-developers 
>  net> On Behalf Of Wayne Stambaugh
> Sent: January 5, 2019 8:07 AM
> To: kicad-developers@lists.launchpad.net
> Subject: Re: [Kicad-developers] Hoping to contribute but I have some 
> questions
> 
> On 1/4/19 6:18 PM, Tomasz Wlostowski wrote:
>> On 04/01/2019 18:51, Brian Piccioni wrote:
>>> I am still keen to attempt to incorporate geographical component annotation 
>>> into KiCad. In general, it is preferable for component annotation to be 
>>> done relative to the PCB and in some logical order (left/right, top to 
>>> bottom, etc). Thereafter this information is imported to the schematic. I 
>>> wrote a standalone utility (RenumKicadPCB) which does this but ideally, 
>>> we’d want the function built into Kicad.
>>>
>>> I understand this would be viewed as a “rogue effort” but lack of 
>>> geographical component annotation is a major missing feature and my hope is 
>>> that if my code works the developers might consider adding it or something 
>>> like it into the project. Otherwise I’ll just maintain my own variant of 
>>> the two affected applications for limited use.
>>>
>>> I am not used to working in c++ or working on large projects. Nevertheless, 
>>> I 

[Kicad-developers] Pulling mac 5.0.2...

[Adam Wolf]

Hi folks!

Just a heads up, the macos 5.0.2 packages are gross for some reason.  I am
regenerating them and we'll see what's going on.

(I am regenerating them at 5.0.2-2)

Should we pull the download temporarily?  It may be a day or two before I
get the good packages up.

I apologize to everyone.

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] Build failed in Jenkins: linux-kicad-full-gcc-head #4493

[Miguel Angel Ajo]

See 


Changes:

[jean-pierre charras] Remove a useless qa test.

--
[...truncated 151.62 KB...]
[ 87%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/editrack-part2.cpp.o
[ 88%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/lib_bezier.cpp.o
[ 88%] Building CXX object 
cvpcb/CMakeFiles/cvpcb_kiface.dir/cvpcb_mainframe.cpp.o
[ 88%] Building CXX object cvpcb/CMakeFiles/cvpcb_kiface.dir/listbox_base.cpp.o
[ 88%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/lib_circle.cpp.o
[ 88%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/editrack.cpp.o
[ 88%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/lib_collectors.cpp.o
[ 88%] Building CXX object cvpcb/CMakeFiles/cvpcb_kiface.dir/menubar.cpp.o
[ 88%] Building CXX object 
cvpcb/CMakeFiles/cvpcb_kiface.dir/readwrite_dlgs.cpp.o
[ 88%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/edtxtmod.cpp.o
[ 88%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/lib_draw_item.cpp.o
[ 88%] Building CXX object 
cvpcb/CMakeFiles/cvpcb_kiface.dir/toolbars_cvpcb.cpp.o
[ 88%] Building CXX object 
cvpcb/CMakeFiles/cvpcb_kiface.dir/tools/cvpcb_actions.cpp.o
[ 88%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/lib_field.cpp.o
[ 88%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/event_handlers_tracks_vias_sizes.cpp.o
[ 88%] Building CXX object 
cvpcb/CMakeFiles/cvpcb_kiface.dir/tools/cvpcb_control.cpp.o
Scanning dependencies of target pl_editor
[ 88%] Building CXX object 
pagelayout_editor/CMakeFiles/pl_editor.dir/__/common/single_top.cpp.o
[ 88%] Building CXX object eeschema/CMakeFiles/eeschema_kiface.dir/lib_pin.cpp.o
[ 88%] Building CXX object 
pagelayout_editor/CMakeFiles/pl_editor.dir/__/common/pgm_base.cpp.o
[ 88%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/files.cpp.o
[ 88%] Building CXX object 
cvpcb/CMakeFiles/cvpcb_kiface.dir/tools/cvpcb_selection_tool.cpp.o
[ 88%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/lib_polyline.cpp.o
[ 88%] Linking CXX executable pl_editor
[ 88%] Built target pl_editor
Scanning dependencies of target pcb_calculator
[ 88%] Building CXX object 
pcb_calculator/CMakeFiles/pcb_calculator.dir/__/common/single_top.cpp.o
[ 88%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/lib_rectangle.cpp.o
[ 88%] Building CXX object 
cvpcb/CMakeFiles/cvpcb_kiface.dir/dialogs/fp_conflict_assignment_selector_base.cpp.o
[ 88%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/footprint_info_impl.cpp.o
[ 88%] Building CXX object 
pcb_calculator/CMakeFiles/pcb_calculator.dir/__/common/pgm_base.cpp.o
[ 88%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/lib_text.cpp.o
[ 89%] Building CXX object 
cvpcb/CMakeFiles/cvpcb_kiface.dir/dialogs/fp_conflict_assignment_selector.cpp.o
[ 89%] Building CXX object eeschema/CMakeFiles/eeschema_kiface.dir/libarch.cpp.o
[ 89%] Linking CXX executable pcb_calculator
[ 89%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/footprint_editor_utils.cpp.o
[ 89%] Building CXX object 
cvpcb/CMakeFiles/cvpcb_kiface.dir/dialogs/dialog_display_options.cpp.o
[ 89%] Built target pcb_calculator
Scanning dependencies of target io_benchmark
[ 89%] Building CXX object 
tools/io_benchmark/CMakeFiles/io_benchmark.dir/io_benchmark.cpp.o
[ 89%] Linking CXX executable io_benchmark
[ 89%] Building CXX object eeschema/CMakeFiles/eeschema_kiface.dir/menubar.cpp.o
[ 89%] Built target io_benchmark
[ 89%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/netlist_generator.cpp.o
[ 89%] Building CXX object 
cvpcb/CMakeFiles/cvpcb_kiface.dir/dialogs/dialog_display_options_base.cpp.o
[ 89%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/footprint_editor_onclick.cpp.o
[ 89%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/footprint_editor_options.cpp.o
[ 89%] Building CXX object 
cvpcb/CMakeFiles/cvpcb_kiface.dir/dialogs/dialog_config_equfiles_base.cpp.o
[ 89%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/netlist_object_list.cpp.o
[ 89%] Building CXX object 
cvpcb/CMakeFiles/cvpcb_kiface.dir/dialogs/dialog_config_equfiles.cpp.o
[ 89%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/netlist_object.cpp.o
[ 90%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/fp_tree_synchronizing_adapter.cpp.o
[ 90%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/footprint_edit_frame.cpp.o
[ 90%] Building CXX object 
cvpcb/CMakeFiles/cvpcb_kiface.dir/__/pcbnew/dialogs/dialog_fp_plugin_options.cpp.o
[ 90%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/onleftclick.cpp.o
[ 90%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/footprint_libraries_utils.cpp.o
[ 90%] Building CXX object 

Re: [Kicad-developers] FOSDEM KiCad dinner.

[Frank Severinsen]

Hi WayneI would like to attend again this year. ___
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] HAVE_CLOCK_GETTIME redefined

[Eeli Kaikkonen]

I get this warning which I haven't seen before. I don't know at all what it
does or is it dangerous, but in general there shouldn't be two definitions
for the same name. In this case the value is different which doesn't sound
good. The compiled code has still worked for me as much as I have tested.
Does this depend on the python version and does it come from system rather
than KiCad?

Building CXX object
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/pcbnew_wrap.cxx.o
In file included from
/work/ohjelmointi/kicad/kicad/include/bitmap_types.h:38:0,
 from
/work/ohjelmointi/kicad/kicad/include/base_struct.h:38,
 from pcbnew/pcbnew_wrap.cxx:5408:
./config.h:26:0: warning: "HAVE_CLOCK_GETTIME" redefined
 #define HAVE_CLOCK_GETTIME

In file included from /usr/include/python3.6m/pyconfig.h:3:0,
 from /usr/include/python3.6m/Python.h:8,
 from pcbnew/pcbnew_wrap.cxx:173:
/usr/include/x86_64-linux-gnu/python3.6m/pyconfig.h:127:0: note: this is
the location of the previous definition
 #define HAVE_CLOCK_GETTIME 1

-

Note: the version under compilation is actually 1ae6fc78a6b372428.

Application: kicad
Version: (6.0.0-rc1-dev-1482-g69fc301bf), release build
Libraries:
wxWidgets 3.0.4
Platform: Linux 4.15.0-43-generic x86_64, 64 bit, Little endian, wxGTK
Build Info:
wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.22
Boost: 1.65.1
OpenCASCADE Community Edition: 6.9.1
Compiler: GCC 7.3.0 with C++ ABI 1011

Build settings:
USE_WX_GRAPHICS_CONTEXT=OFF
USE_WX_OVERLAY=OFF
KICAD_SCRIPTING=ON
KICAD_SCRIPTING_MODULES=ON
KICAD_SCRIPTING_PYTHON3=ON
KICAD_SCRIPTING_WXPYTHON=ON
KICAD_SCRIPTING_WXPYTHON_PHOENIX=ON
KICAD_SCRIPTING_ACTION_MENU=ON
BUILD_GITHUB_PLUGIN=OFF
KICAD_USE_OCE=ON
KICAD_USE_OCC=OFF
KICAD_SPICE=OFF



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

[Kicad-developers] Build failed in Jenkins: linux-kicad-full-gcc-head #4492

[Miguel Angel Ajo]

See 


Changes:

[jean-pierre charras] remove dead code.

--
[...truncated 152.03 KB...]
[ 86%] Building CXX object eeschema/CMakeFiles/eeschema_kiface.dir/lib_pin.cpp.o
Scanning dependencies of target cvpcb_kiface
[ 86%] Building CXX object cvpcb/CMakeFiles/cvpcb_kiface.dir/cvpcb.cpp.o
Scanning dependencies of target gerbview
[ 86%] Building CXX object 
gerbview/CMakeFiles/gerbview.dir/__/common/single_top.cpp.o
[ 86%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/fp_tree_model_adapter.cpp.o
[ 86%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/lib_polyline.cpp.o
[ 86%] Building CXX object 
gerbview/CMakeFiles/gerbview.dir/__/common/pgm_base.cpp.o
[ 86%] Building CXX object 
cvpcb/CMakeFiles/cvpcb_kiface.dir/__/common/base_units.cpp.o
[ 86%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/lib_rectangle.cpp.o
[ 86%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/generate_footprint_info.cpp.o
[ 86%] Building CXX object 
cvpcb/CMakeFiles/cvpcb_kiface.dir/__/pcbnew/board_items_to_polygon_shape_transform.cpp.o
[ 86%] Linking CXX executable gerbview
[ 86%] Built target gerbview
Scanning dependencies of target pl_editor
[ 86%] Building CXX object 
pagelayout_editor/CMakeFiles/pl_editor.dir/__/common/single_top.cpp.o
[ 86%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/lib_text.cpp.o
[ 86%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/grid_layer_box_helpers.cpp.o
[ 86%] Building CXX object 
cvpcb/CMakeFiles/cvpcb_kiface.dir/__/pcbnew/pcb_general_settings.cpp.o
[ 86%] Building CXX object 
pagelayout_editor/CMakeFiles/pl_editor.dir/__/common/pgm_base.cpp.o
[ 86%] Building CXX object eeschema/CMakeFiles/eeschema_kiface.dir/libarch.cpp.o
[ 86%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/highlight.cpp.o
[ 87%] Building CXX object 
cvpcb/CMakeFiles/cvpcb_kiface.dir/__/pcbnew/drc_item.cpp.o
[ 87%] Linking CXX executable pl_editor
[ 87%] Building CXX object eeschema/CMakeFiles/eeschema_kiface.dir/menubar.cpp.o
[ 87%] Built target pl_editor
Scanning dependencies of target pcb_calculator
[ 87%] Building CXX object 
pcb_calculator/CMakeFiles/pcb_calculator.dir/__/common/single_top.cpp.o
[ 87%] Building CXX object 
cvpcb/CMakeFiles/cvpcb_kiface.dir/__/pcbnew/tools/grid_helper.cpp.o
[ 87%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/hotkeys.cpp.o
[ 87%] Building CXX object 
pcb_calculator/CMakeFiles/pcb_calculator.dir/__/common/pgm_base.cpp.o
[ 87%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/netlist_generator.cpp.o
[ 87%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/hotkeys_board_editor.cpp.o
[ 87%] Building CXX object 
cvpcb/CMakeFiles/cvpcb_kiface.dir/auto_associate.cpp.o
[ 87%] Linking CXX executable pcb_calculator
[ 87%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/netlist_object_list.cpp.o
[ 87%] Built target pcb_calculator
Scanning dependencies of target io_benchmark
[ 87%] Building CXX object 
tools/io_benchmark/CMakeFiles/io_benchmark.dir/io_benchmark.cpp.o
[ 87%] Linking CXX executable io_benchmark
[ 87%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/hotkeys_footprint_editor.cpp.o
[ 87%] Built target io_benchmark
[ 87%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/initpcb.cpp.o
[ 87%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/netlist_object.cpp.o
[ 87%] Building CXX object cvpcb/CMakeFiles/cvpcb_kiface.dir/cfg.cpp.o
[ 87%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/onleftclick.cpp.o
[ 87%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/layer_widget.cpp.o
[ 87%] Building CXX object 
cvpcb/CMakeFiles/cvpcb_kiface.dir/components_listbox.cpp.o
[ 87%] Building CXX object 
cvpcb/CMakeFiles/cvpcb_kiface.dir/display_footprints_frame.cpp.o
[ 87%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/load_select_footprint.cpp.o
[ 87%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/onrightclick.cpp.o
[ 87%] Building CXX object 
cvpcb/CMakeFiles/cvpcb_kiface.dir/footprints_listbox.cpp.o
[ 87%] Building CXX object 
cvpcb/CMakeFiles/cvpcb_kiface.dir/library_listbox.cpp.o
[ 87%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/magnetic_tracks_functions.cpp.o
[ 87%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/operations_on_items_lists.cpp.o
[ 87%] Building CXX object 
cvpcb/CMakeFiles/cvpcb_kiface.dir/cvpcb_mainframe.cpp.o
[ 87%] Building CXX object cvpcb/CMakeFiles/cvpcb_kiface.dir/listbox_base.cpp.o
[ 87%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/pin_number.cpp.o
[ 87%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/menubar_footprint_editor.cpp.o
[ 87%] Building CXX object 

[Kicad-developers] Build failed in Jenkins: linux-kicad-full-gcc-head #4491

[Miguel Angel Ajo]

See 


Changes:

[jean-pierre charras] QA: Add pcbnew unit tests CMake subdir

--
[...truncated 153.19 KB...]
[ 87%] Building CXX object 
bitmap2component/CMakeFiles/bitmap2component.dir/bitmap2component.cpp.o
[ 87%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/sheetlab.cpp.o
[ 87%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/tools/edit_tool.cpp.o
[ 87%] Building CXX object 
pagelayout_editor/CMakeFiles/pl_editor_kiface.dir/__/common/base_units.cpp.o
[ 87%] Building CXX object 
bitmap2component/CMakeFiles/bitmap2component.dir/bitmap2cmp_gui_base.cpp.o
[ 88%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/symbol_lib_table.cpp.o
[ 88%] Building CXX object 
bitmap2component/CMakeFiles/bitmap2component.dir/bitmap2cmp_gui.cpp.o
[ 88%] Building CXX object 
pagelayout_editor/CMakeFiles/pl_editor_kiface.dir/__/common/eda_text.cpp.o
[ 88%] Linking CXX executable bitmap2component
[ 88%] Building CXX object 
pagelayout_editor/CMakeFiles/pl_editor_kiface.dir/__/common/dialogs/dialog_page_settings.cpp.o
[ 88%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/tools/grid_helper.cpp.o
[ 88%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/symbol_tree_model_adapter.cpp.o
[ 88%] Built target bitmap2component
[ 88%] creating 

 from 

[ 88%] creating 

 from 

[ 88%] creating 

 from 

[ 88%] creating 

 from 

Scanning dependencies of target pcb_calculator_kiface
[ 88%] Building CXX object 
pcb_calculator/CMakeFiles/pcb_calculator_kiface.dir/pcb_calculator.cpp.o
[ 88%] Building CXX object 
pagelayout_editor/CMakeFiles/pl_editor_kiface.dir/__/common/page_info.cpp.o
[ 88%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/symbol_tree_synchronizing_adapter.cpp.o
[ 88%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/tools/microwave_tool.cpp.o
[ 88%] Building CXX object 
pcb_calculator/CMakeFiles/pcb_calculator_kiface.dir/attenuators.cpp.o
[ 88%] Linking CXX shared module _pl_editor.kiface
[ 88%] Building CXX object 
pcb_calculator/CMakeFiles/pcb_calculator_kiface.dir/board_classes_values.cpp.o
[ 88%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/template_fieldnames.cpp.o
[ 88%] Building CXX object 
pcb_calculator/CMakeFiles/pcb_calculator_kiface.dir/colorcode.cpp.o
[ 88%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/tools/footprint_editor_tools.cpp.o
[ 88%] Built target pl_editor_kiface
Scanning dependencies of target s3d_plugin_idf
[ 88%] Building CXX object 
plugins/3d/idf/CMakeFiles/s3d_plugin_idf.dir/s3d_plugin_idf.cpp.o
[ 88%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/template_fieldnames_keywords.cpp.o
[ 88%] Building CXX object 
pcb_calculator/CMakeFiles/pcb_calculator_kiface.dir/electrical_spacing_values.cpp.o
[ 88%] Building CXX object 
plugins/3d/idf/CMakeFiles/s3d_plugin_idf.dir/__/__/__/utils/idftools/vrml_layer.cpp.o
[ 88%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/tool_sch.cpp.o
[ 88%] Building CXX object 
pcb_calculator/CMakeFiles/pcb_calculator_kiface.dir/params_read_write.cpp.o
[ 88%] Linking CXX shared module libs3d_plugin_idf.so
[ 88%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/tools/pad_tool.cpp.o
[ 88%] Built target s3d_plugin_idf
[ 88%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/tools/pcb_actions.cpp.o
[ 88%] Building CXX object 
pcb_calculator/CMakeFiles/pcb_calculator_kiface.dir/pcb_calculator_frame.cpp.o
[ 88%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/tools/pcb_bright_box.cpp.o
[ 88%] Building CXX object 
eeschema/CMakeFiles/eeschema_kiface.dir/tool_viewlib.cpp.o
[ 89%] Building CXX object 
pcb_calculator/CMakeFiles/pcb_calculator_kiface.dir/datafile_read_write.cpp.o
[ 89%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/tools/pcb_editor_control.cpp.o
[ 89%] Building CXX object 
pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/tools/pcb_selection_conditions.cpp.o
[ 89%] Building CXX object 

Re: [Kicad-developers] FOSDEM KiCad dinner.

[Thomas Pointhuber]

Hi Wayne,

 

I would like to attend this year again.

 

Regards,

Thomas




Gesendet: Montag, 07. Januar 2019 um 18:40 Uhr
Von: "Wayne Stambaugh" 
An: "KiCad Developers" 
Betreff: [Kicad-developers] FOSDEM KiCad dinner.

For those of you who don't know, the last few years at FOSDEM we have
had a KiCad dinner on Saturday evening which was open to all. Last year
we had well over 30 attendees which was very not manageable. This year
we have decided to limit the size to 15. So far we have 4 confirmed
attendees from the lead development team. I am now opening up requests
to the developers on the development mailing list. This includes our
library, documentation, and translation developers. Please RSVP me as
soon as possible if you are interested. Resevations will be on a first
come first serve basis until all 15 spots are reserved. Any remaining
spots will be open to sponsors and then to the general public.

Cheers,

Wayne

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




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

[Kicad-developers] FOSDEM KiCad dinner.

[Wayne Stambaugh]

For those of you who don't know, the last few years at FOSDEM we have
had a KiCad dinner on Saturday evening which was open to all.  Last year
we had well over 30 attendees which was very not manageable.  This year
we have decided to limit the size to 15.  So far we have 4 confirmed
attendees from the lead development team.  I am now opening up requests
to the developers on the development mailing list.  This includes our
library, documentation, and translation developers.  Please RSVP me as
soon as possible if you are interested.  Resevations will be on a first
come first serve basis until all 15 spots are reserved.  Any remaining
spots will be open to sponsors and then to the general public.

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] [PATCH] Pcbnew unit test framework

[jp charras]

Le 07/01/2019 à 17:57, Wayne Stambaugh a écrit :
> JP,
> 
> If you still have this patch applied to your repo, please push it to the
> development branch when you get a chance.  If not, please let me know
> and I will get it pushed.
> 
> Thanks,
> 
> Wayne

I just pushed it.


-- 
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] [KiCad-developers] Hoping to contribute but I have some questions

[Wayne Stambaugh]

On 1/7/2019 9:49 AM, Brian Piccioni wrote:
> Wayne
> 
> I looked at the source over the weekend within the context of your comment. 
> In eeSchema there is a command to "Update PCB" with a modified netlist. This 
> command is passed from eeSchema to PCBNew by Kimail. At this stage my rough 
> program design has evolved to a sort of state machine where there are several 
> interactions between PCBNew and eeSchema via Kimail (i.e. passing the change 
> list, checking it for errors, committing the change list if no errors, etc).

This is the issue that I was talking about.  Currently netlist changes
are unidirectional from the schematic editor to the board editor.  In
order to push annotation changes from the board editor to the schematic
editor, you (or someone else) will have to implement this in order to
back annotate the revised references from the board editor to the
schematic editor.  The other option is to save an intermediate netlist
file from the board editor (which I also believe doesn't exist yet) and
import the changes into the schematic editor.  These would be the only
two solutions that I would accept but my preference is the former.  I
want to avoid yet another intermediate file format.

> 
> Since I propose to do a "dry run" of the component changes in eeSchema to 
> check for errors it seems to me that executing "Update PCB" immediately after 
> re-annotating the PCB and schematic would ensure coherency with the netlist.
> 
> As this is pretty much was a PCB designer would do if he re-annotated 
> manually it should work under program control as well.
> 
> Would this address your concern or is there something else I am missing?
> 
> Regards
> 
> Brian
> 
> -Original Message-
> From: Kicad-developers 
>  On 
> Behalf Of Wayne Stambaugh
> Sent: January 5, 2019 8:07 AM
> To: kicad-developers@lists.launchpad.net
> Subject: Re: [Kicad-developers] Hoping to contribute but I have some questions
> 
> On 1/4/19 6:18 PM, Tomasz Wlostowski wrote:
>> On 04/01/2019 18:51, Brian Piccioni wrote:
>>> I am still keen to attempt to incorporate geographical component annotation 
>>> into KiCad. In general, it is preferable for component annotation to be 
>>> done relative to the PCB and in some logical order (left/right, top to 
>>> bottom, etc). Thereafter this information is imported to the schematic. I 
>>> wrote a standalone utility (RenumKicadPCB) which does this but ideally, 
>>> we’d want the function built into Kicad.
>>>
>>> I understand this would be viewed as a “rogue effort” but lack of 
>>> geographical component annotation is a major missing feature and my hope is 
>>> that if my code works the developers might consider adding it or something 
>>> like it into the project. Otherwise I’ll just maintain my own variant of 
>>> the two affected applications for limited use.
>>>
>>> I am not used to working in c++ or working on large projects. Nevertheless, 
>>> I figured I’d give it a try. I have been studying the source for a few 
>>> weeks and have developed a strategy which would be very simple to implement 
>>> if I had more skill/experience. 
>>>
>>> The first thing I want to do is to add the ability for eeSchema to import a 
>>> “was/is” file to update schematic annotation. Since renumbering the PCB can 
>>> be done manually or with a plugin this seems like a good first step. Since 
>>> an annotation function already exists in eeSchema, all I would have to do 
>>> it provide an option for replacing annotation with a was/is rather than the 
>>> annotation generated by eeSchema’s annotate function. 
>>>
>>> I see a clear path to doing so however, the scope of Kicad and my limited 
>>> experience with c++ and large projects mean it is not going to be easy for 
>>> me. I am not that adept at navigating Doxygen files so I have a few 
>>> questions regarding the source code (these are limited to eeSchema at the 
>>> moment).
>>>
>>> 1)  Where are the file IO functions? I have searched for (for example) 
>>> LoadProjectFIle and find the prototype but not the actual function. 
>>> Similarly I find the prototype for SaveEEFile() but not the actual function.
>>>
>>> 2)  I would like to copy as much of the existing code and dialogs as 
>>> possible (i.e. make new dialog based off another dialog) but when I open, 
>>> for example, dialog_annotate_base.h I see
>>>
>>> 
>>> ///
>>> // C++ code generated with wxFormBuilder (version Jun  5 2018)
>>> // http://www.wxformbuilder.org/
>>> //
>>> // PLEASE DO *NOT* EDIT THIS FILE!
>>> 
>>> /
>>> //
>>> 
>>> But I can’t find the “source” from which this file is generated. Where is 
>>> it?
>>>
>>> 3)  There is a guide on the Kicad documentation “Tool framework” which 
>>> describes adding a tool to PCBNew. Is there a similar guide to adding a 
>>> tool/function to eeSchema? How do I go 

Re: [Kicad-developers] [PATCH] Pcbnew unit test framework

[Wayne Stambaugh]

JP,

If you still have this patch applied to your repo, please push it to the
development branch when you get a chance.  If not, please let me know
and I will get it pushed.

Thanks,

Wayne

On 1/7/2019 9:59 AM, John Beard wrote:
> On Mon, Jan 7, 2019 at 2:47 PM jp charras  wrote:
> 
>> This patch works.
> 
> Great!
> 
>> make test works and shows only 3 tests:
> 
> Looks like you don't have the python scripting on, so you are missing
> the qa_python target. The pcbnew target (this one) is there.
> 
>> So it can be a cmake issue and/or a operating system issue.
> 
> I think CMake has been about to link OBJECT libs for about a year, and
> it might be a compiler thing too, so that's likely.
> 
>> Not easy...
>>
>> I have 2 OS: W7 32 bits and Linux.
>> In fact I have 2 Linux installs:
>> * a "old" Kubuntu 14.04 LTS (using KDE) install (similar to our Jenkins
>> install: it allows me to fix some issues found by Jenkins).
>> * a more recent Ubuntu 16.04 LTS (using Unity) install to catch some
>> other issues (especially Unity specific)>
>> 
>> Of course, I cannot test OSX builds.
> 
> OK, well I will continue to use Simon's Jenkins for Windows and hope I
> don't break too much on other systems. Hopefully as we get all our QA
> stuff lined up, there will be less platform weirdness!
> 
> Thanks for the help tracking this down!
> 
> Cheers,
> 
> John
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

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

Re: [Kicad-developers] [PATCH] Pcbnew unit test framework

[John Beard]

On Mon, Jan 7, 2019 at 2:47 PM jp charras  wrote:

> This patch works.

Great!

> make test works and shows only 3 tests:

Looks like you don't have the python scripting on, so you are missing
the qa_python target. The pcbnew target (this one) is there.

> So it can be a cmake issue and/or a operating system issue.

I think CMake has been about to link OBJECT libs for about a year, and
it might be a compiler thing too, so that's likely.

> Not easy...
>
> I have 2 OS: W7 32 bits and Linux.
> In fact I have 2 Linux installs:
> * a "old" Kubuntu 14.04 LTS (using KDE) install (similar to our Jenkins
> install: it allows me to fix some issues found by Jenkins).
> * a more recent Ubuntu 16.04 LTS (using Unity) install to catch some
> other issues (especially Unity specific)>
> 
> Of course, I cannot test OSX builds.

OK, well I will continue to use Simon's Jenkins for Windows and hope I
don't break too much on other systems. Hopefully as we get all our QA
stuff lined up, there will be less platform weirdness!

Thanks for the help tracking this down!

Cheers,

John

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

Re: [Kicad-developers] [PATCH] Pcbnew unit test framework

[Adam Wolf]

For macOS, I'm working on making it easy for folks to request a build with
a patch/git branch.  It'll happen!

On Mon, Jan 7, 2019 at 8:48 AM jp charras  wrote:

> Le 07/01/2019 à 14:00, John Beard a écrit :
> > Hi JP,
> >
> > Sorry, I thought that issue was just a side effect of conflicted
> > merges in these files, but maybe not. I had built this code on Linux
> > GCC, Windows Msys2 and MSVC on Simon's Jenkins with no issues, so I'm
> > working blind in trying to fix it.
> >
> > I think it might be an issue with older CMakes, but I cannot test this
> > as I do not know of a CI target I could use to check. I am rebuilding
> > on Jenkins now, but since it takes an hour and doesn't even show the
> > error, I'd like to know if I have also fixed it for you.
> >
> > Here's an attempt to fix it (replaces prior patch).
>
> Hi John,
>
> This patch works.
> make test works and shows only 3 tests:
> $ make test
> Running tests...
> Test project E:/kicad-launchpad/testing_git/Build/Release
> Start 1: common
> 1/3 Test #1: common ...   Passed0.09 sec
> Start 2: pcbnew
> 2/3 Test #2: pcbnew ...   Passed0.14 sec
> Start 3: shape_poly_set_refactor
> 3/3 Test #3: shape_poly_set_refactor ..   Passed0.03 sec
>
> 100% tests passed, 0 tests failed out of 3
>
>
> I also tried to re-add the line:
> "pcbnew_kiface_objects"
> in qa/pcbnew/CMakeLists.txt
>
> I get this cmake error:
> CMake Error at qa/pcbnew/CMakeLists.txt:66 (target_link_libraries):
>   Target "pcbnew_kiface_objects" of type OBJECT_LIBRARY may not be linked
>   into another target.  One may link only to INTERFACE, STATIC or SHARED
>   libraries, or to executables with the ENABLE_EXPORTS property set.
>
> and I have this error both with cmake 3.7 and a recent cmake 3.11 (on msys)
>
> So it can be a cmake issue and/or a operating system issue.
>
> >
> > What is the right way for me to check these patches are correct in
> > future? It is frustrating to submit patches that break builds that I
> > have no way to predict or detect, and I'm sure it frustrating for
> > maintainers to waste so much time speculatively building patches and
> > replying to emails with the failures.
> >
> > Cheers,
> >
> > John
>
> Not easy...
>
> I have 2 OS: W7 32 bits and Linux.
> In fact I have 2 Linux installs:
> * a "old" Kubuntu 14.04 LTS (using KDE) install (similar to our Jenkins
> install: it allows me to fix some issues found by Jenkins).
> * a more recent Ubuntu 16.04 LTS (using Unity) install to catch some
> other issues (especially Unity specific)
>
> And I already committed broken patches.
>
> Of course, I cannot test OSX builds.
>
> --
> 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
>
___
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-developers] Hoping to contribute but I have some questions

[Brian Piccioni]

Wayne

I looked at the source over the weekend within the context of your comment. In 
eeSchema there is a command to "Update PCB" with a modified netlist. This 
command is passed from eeSchema to PCBNew by Kimail. At this stage my rough 
program design has evolved to a sort of state machine where there are several 
interactions between PCBNew and eeSchema via Kimail (i.e. passing the change 
list, checking it for errors, committing the change list if no errors, etc).

Since I propose to do a "dry run" of the component changes in eeSchema to check 
for errors it seems to me that executing "Update PCB" immediately after 
re-annotating the PCB and schematic would ensure coherency with the netlist.

As this is pretty much was a PCB designer would do if he re-annotated manually 
it should work under program control as well.

Would this address your concern or is there something else I am missing?

Regards

Brian

-Original Message-
From: Kicad-developers 
 On 
Behalf Of Wayne Stambaugh
Sent: January 5, 2019 8:07 AM
To: kicad-developers@lists.launchpad.net
Subject: Re: [Kicad-developers] Hoping to contribute but I have some questions

On 1/4/19 6:18 PM, Tomasz Wlostowski wrote:
> On 04/01/2019 18:51, Brian Piccioni wrote:
>> I am still keen to attempt to incorporate geographical component annotation 
>> into KiCad. In general, it is preferable for component annotation to be done 
>> relative to the PCB and in some logical order (left/right, top to bottom, 
>> etc). Thereafter this information is imported to the schematic. I wrote a 
>> standalone utility (RenumKicadPCB) which does this but ideally, we’d want 
>> the function built into Kicad.
>>
>> I understand this would be viewed as a “rogue effort” but lack of 
>> geographical component annotation is a major missing feature and my hope is 
>> that if my code works the developers might consider adding it or something 
>> like it into the project. Otherwise I’ll just maintain my own variant of the 
>> two affected applications for limited use.
>>
>> I am not used to working in c++ or working on large projects. Nevertheless, 
>> I figured I’d give it a try. I have been studying the source for a few weeks 
>> and have developed a strategy which would be very simple to implement if I 
>> had more skill/experience. 
>>
>> The first thing I want to do is to add the ability for eeSchema to import a 
>> “was/is” file to update schematic annotation. Since renumbering the PCB can 
>> be done manually or with a plugin this seems like a good first step. Since 
>> an annotation function already exists in eeSchema, all I would have to do it 
>> provide an option for replacing annotation with a was/is rather than the 
>> annotation generated by eeSchema’s annotate function. 
>>
>> I see a clear path to doing so however, the scope of Kicad and my limited 
>> experience with c++ and large projects mean it is not going to be easy for 
>> me. I am not that adept at navigating Doxygen files so I have a few 
>> questions regarding the source code (these are limited to eeSchema at the 
>> moment).
>>
>> 1)   Where are the file IO functions? I have searched for (for example) 
>> LoadProjectFIle and find the prototype but not the actual function. 
>> Similarly I find the prototype for SaveEEFile() but not the actual function.
>>
>> 2)   I would like to copy as much of the existing code and dialogs as 
>> possible (i.e. make new dialog based off another dialog) but when I open, 
>> for example, dialog_annotate_base.h I see
>>
>>  
>> ///
>>  // C++ code generated with wxFormBuilder (version Jun  5 2018)
>>  // http://www.wxformbuilder.org/
>>  //
>>  // PLEASE DO *NOT* EDIT THIS FILE!
>>  
>> /
>> //
>>  
>> But I can’t find the “source” from which this file is generated. Where is it?
>>
>> 3)   There is a guide on the Kicad documentation “Tool framework” which 
>> describes adding a tool to PCBNew. Is there a similar guide to adding a 
>> tool/function to eeSchema? How do I go about this?
>>
> 
> Hi Brian,
> 
> Others have already answered to your questions so here's my offer: I 
> believe geographical annotation is a very useful feature so I can 
> offer a bit of my help. Point me to:
> - the latest sources of your tool,
> - a sketch of the user interface (dialogs), can be a hand-made drawing
> - a brief description of how you want all this to work (in terms of 
> user experience).
> 
> Once I have this information, I'll try making a basic port of your 
> code to Kicad codebase to the stage where you could take it over and 
> contribute further features/fixes on your own.
> 
> Tom
> 

There is a lower level piece of the puzzle that is missing and that is back 
annotation from the board editor to the schematic editor.  This is non-trivial 
because you have create a netlist from the board information and 

Re: [Kicad-developers] [PATCH] Pcbnew unit test framework

[jp charras]

Le 07/01/2019 à 14:00, John Beard a écrit :
> Hi JP,
> 
> Sorry, I thought that issue was just a side effect of conflicted
> merges in these files, but maybe not. I had built this code on Linux
> GCC, Windows Msys2 and MSVC on Simon's Jenkins with no issues, so I'm
> working blind in trying to fix it.
> 
> I think it might be an issue with older CMakes, but I cannot test this
> as I do not know of a CI target I could use to check. I am rebuilding
> on Jenkins now, but since it takes an hour and doesn't even show the
> error, I'd like to know if I have also fixed it for you.
> 
> Here's an attempt to fix it (replaces prior patch).

Hi John,

This patch works.
make test works and shows only 3 tests:
$ make test
Running tests...
Test project E:/kicad-launchpad/testing_git/Build/Release
Start 1: common
1/3 Test #1: common ...   Passed0.09 sec
Start 2: pcbnew
2/3 Test #2: pcbnew ...   Passed0.14 sec
Start 3: shape_poly_set_refactor
3/3 Test #3: shape_poly_set_refactor ..   Passed0.03 sec

100% tests passed, 0 tests failed out of 3


I also tried to re-add the line:
"pcbnew_kiface_objects"
in qa/pcbnew/CMakeLists.txt

I get this cmake error:
CMake Error at qa/pcbnew/CMakeLists.txt:66 (target_link_libraries):
  Target "pcbnew_kiface_objects" of type OBJECT_LIBRARY may not be linked
  into another target.  One may link only to INTERFACE, STATIC or SHARED
  libraries, or to executables with the ENABLE_EXPORTS property set.

and I have this error both with cmake 3.7 and a recent cmake 3.11 (on msys)

So it can be a cmake issue and/or a operating system issue.

> 
> What is the right way for me to check these patches are correct in
> future? It is frustrating to submit patches that break builds that I
> have no way to predict or detect, and I'm sure it frustrating for
> maintainers to waste so much time speculatively building patches and
> replying to emails with the failures.
> 
> Cheers,
> 
> John

Not easy...

I have 2 OS: W7 32 bits and Linux.
In fact I have 2 Linux installs:
* a "old" Kubuntu 14.04 LTS (using KDE) install (similar to our Jenkins
install: it allows me to fix some issues found by Jenkins).
* a more recent Ubuntu 16.04 LTS (using Unity) install to catch some
other issues (especially Unity specific)

And I already committed broken patches.

Of course, I cannot test OSX builds.

-- 
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] Pcbnew unit test framework

[Wayne Stambaugh]

Hey John,

I only see three tests.  Does your latest patch enable this so I can
test it?

Cheers,

Wayne

On 1/7/2019 8:39 AM, John Beard wrote:
> Hi Wayne,
> 
> 3f9230fa5 doesn't have add_subdirectory( pcbnew ) in
> qa/CMakeLists.txt, because the reversion of the merge conflicts with
> the stray patch removed it.
> 
> if you add the add_subdirectory( pcbnew ) line back, it is reported to
> break on some systems. This could be a CMake version thing, but all
> the systems I have tried work, so it's kind of hard for me to tell.
> 
> You can tell if you have the pcbnew unit tests are working if "make
> test" runs 4 tests, not 3 (or if the executable qa/pcbnew/qa_pcbnew is
> built).
> 
> Cheers,
> 
> John
> 
> On Mon, Jan 7, 2019 at 1:06 PM Wayne Stambaugh  wrote:
>>
>> I just ran a 32 bit build on windows with commit 3f9230fa and I didn't
>> have any build or test issues.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 1/7/2019 8:00 AM, John Beard wrote:
>>> Hi JP,
>>>
>>> Sorry, I thought that issue was just a side effect of conflicted
>>> merges in these files, but maybe not. I had built this code on Linux
>>> GCC, Windows Msys2 and MSVC on Simon's Jenkins with no issues, so I'm
>>> working blind in trying to fix it.
>>>
>>> I think it might be an issue with older CMakes, but I cannot test this
>>> as I do not know of a CI target I could use to check. I am rebuilding
>>> on Jenkins now, but since it takes an hour and doesn't even show the
>>> error, I'd like to know if I have also fixed it for you.
>>>
>>> Here's an attempt to fix it (replaces prior patch).
>>>
>>> What is the right way for me to check these patches are correct in
>>> future? It is frustrating to submit patches that break builds that I
>>> have no way to predict or detect, and I'm sure it frustrating for
>>> maintainers to waste so much time speculatively building patches and
>>> replying to emails with the failures.
>>>
>>> Cheers,
>>>
>>> John
>>>
>>> On Mon, Jan 7, 2019 at 11:42 AM jp charras  wrote:

 Le 07/01/2019 à 12:33, John Beard a écrit :
> Hi Seth,
>
> The revert commit (8f11a2133efd95526d1a3783dbaca76f732b8efb) also
> killed the CMake add_subdirectory (because the original commit was
> conflicted). Here is a patch to put it back in order (and put the
> existing subdirs into some order).
>
> Cheers,
>
> John
>

 Hi John,

 As previously reported, the add_subdirectory pcbnew breaks the windows
 build and some Linux builds.

 Please, first fix the the build issue in qa/pcbnew.

 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

 ___
 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] Pcbnew unit test framework

[John Beard]

Hi Wayne,

3f9230fa5 doesn't have add_subdirectory( pcbnew ) in
qa/CMakeLists.txt, because the reversion of the merge conflicts with
the stray patch removed it.

if you add the add_subdirectory( pcbnew ) line back, it is reported to
break on some systems. This could be a CMake version thing, but all
the systems I have tried work, so it's kind of hard for me to tell.

You can tell if you have the pcbnew unit tests are working if "make
test" runs 4 tests, not 3 (or if the executable qa/pcbnew/qa_pcbnew is
built).

Cheers,

John

On Mon, Jan 7, 2019 at 1:06 PM Wayne Stambaugh  wrote:
>
> I just ran a 32 bit build on windows with commit 3f9230fa and I didn't
> have any build or test issues.
>
> Cheers,
>
> Wayne
>
> On 1/7/2019 8:00 AM, John Beard wrote:
> > Hi JP,
> >
> > Sorry, I thought that issue was just a side effect of conflicted
> > merges in these files, but maybe not. I had built this code on Linux
> > GCC, Windows Msys2 and MSVC on Simon's Jenkins with no issues, so I'm
> > working blind in trying to fix it.
> >
> > I think it might be an issue with older CMakes, but I cannot test this
> > as I do not know of a CI target I could use to check. I am rebuilding
> > on Jenkins now, but since it takes an hour and doesn't even show the
> > error, I'd like to know if I have also fixed it for you.
> >
> > Here's an attempt to fix it (replaces prior patch).
> >
> > What is the right way for me to check these patches are correct in
> > future? It is frustrating to submit patches that break builds that I
> > have no way to predict or detect, and I'm sure it frustrating for
> > maintainers to waste so much time speculatively building patches and
> > replying to emails with the failures.
> >
> > Cheers,
> >
> > John
> >
> > On Mon, Jan 7, 2019 at 11:42 AM jp charras  wrote:
> >>
> >> Le 07/01/2019 à 12:33, John Beard a écrit :
> >>> Hi Seth,
> >>>
> >>> The revert commit (8f11a2133efd95526d1a3783dbaca76f732b8efb) also
> >>> killed the CMake add_subdirectory (because the original commit was
> >>> conflicted). Here is a patch to put it back in order (and put the
> >>> existing subdirs into some order).
> >>>
> >>> Cheers,
> >>>
> >>> John
> >>>
> >>
> >> Hi John,
> >>
> >> As previously reported, the add_subdirectory pcbnew breaks the windows
> >> build and some Linux builds.
> >>
> >> Please, first fix the the build issue in qa/pcbnew.
> >>
> >> 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
> >>
> >> ___
> >> 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] Pcbnew unit test framework

[Wayne Stambaugh]

I just ran a 32 bit build on windows with commit 3f9230fa and I didn't
have any build or test issues.

Cheers,

Wayne

On 1/7/2019 8:00 AM, John Beard wrote:
> Hi JP,
> 
> Sorry, I thought that issue was just a side effect of conflicted
> merges in these files, but maybe not. I had built this code on Linux
> GCC, Windows Msys2 and MSVC on Simon's Jenkins with no issues, so I'm
> working blind in trying to fix it.
> 
> I think it might be an issue with older CMakes, but I cannot test this
> as I do not know of a CI target I could use to check. I am rebuilding
> on Jenkins now, but since it takes an hour and doesn't even show the
> error, I'd like to know if I have also fixed it for you.
> 
> Here's an attempt to fix it (replaces prior patch).
> 
> What is the right way for me to check these patches are correct in
> future? It is frustrating to submit patches that break builds that I
> have no way to predict or detect, and I'm sure it frustrating for
> maintainers to waste so much time speculatively building patches and
> replying to emails with the failures.
> 
> Cheers,
> 
> John
> 
> On Mon, Jan 7, 2019 at 11:42 AM jp charras  wrote:
>>
>> Le 07/01/2019 à 12:33, John Beard a écrit :
>>> Hi Seth,
>>>
>>> The revert commit (8f11a2133efd95526d1a3783dbaca76f732b8efb) also
>>> killed the CMake add_subdirectory (because the original commit was
>>> conflicted). Here is a patch to put it back in order (and put the
>>> existing subdirs into some order).
>>>
>>> Cheers,
>>>
>>> John
>>>
>>
>> Hi John,
>>
>> As previously reported, the add_subdirectory pcbnew breaks the windows
>> build and some Linux builds.
>>
>> Please, first fix the the build issue in qa/pcbnew.
>>
>> 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
>>
>> ___
>> 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] Pcbnew unit test framework

[John Beard]

Hi JP,

Sorry, I thought that issue was just a side effect of conflicted
merges in these files, but maybe not. I had built this code on Linux
GCC, Windows Msys2 and MSVC on Simon's Jenkins with no issues, so I'm
working blind in trying to fix it.

I think it might be an issue with older CMakes, but I cannot test this
as I do not know of a CI target I could use to check. I am rebuilding
on Jenkins now, but since it takes an hour and doesn't even show the
error, I'd like to know if I have also fixed it for you.

Here's an attempt to fix it (replaces prior patch).

What is the right way for me to check these patches are correct in
future? It is frustrating to submit patches that break builds that I
have no way to predict or detect, and I'm sure it frustrating for
maintainers to waste so much time speculatively building patches and
replying to emails with the failures.

Cheers,

John

On Mon, Jan 7, 2019 at 11:42 AM jp charras  wrote:
>
> Le 07/01/2019 à 12:33, John Beard a écrit :
> > Hi Seth,
> >
> > The revert commit (8f11a2133efd95526d1a3783dbaca76f732b8efb) also
> > killed the CMake add_subdirectory (because the original commit was
> > conflicted). Here is a patch to put it back in order (and put the
> > existing subdirs into some order).
> >
> > Cheers,
> >
> > John
> >
>
> Hi John,
>
> As previously reported, the add_subdirectory pcbnew breaks the windows
> build and some Linux builds.
>
> Please, first fix the the build issue in qa/pcbnew.
>
> 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
From 5ba2710894311c56754e237607c5dbdb769b10c4 Mon Sep 17 00:00:00 2001
From: John Beard 
Date: Mon, 7 Jan 2019 11:11:47 +
Subject: [PATCH] QA: Add pcbnew unit tests CMake subdir

Also modify the linkage of kiface objects, as this is not
supported by older CMake versions.

This was accidentally removed with the reversion of the application
of the wrong patch (8f11a2133).

QA: fix object files
---
 qa/CMakeLists.txt| 7 ++-
 qa/pcbnew/CMakeLists.txt | 5 -
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/qa/CMakeLists.txt b/qa/CMakeLists.txt
index fd592f321..e0011ff77 100644
--- a/qa/CMakeLists.txt
+++ b/qa/CMakeLists.txt
@@ -12,13 +12,18 @@ if( KICAD_SCRIPTING_MODULES )
 
 endif()
 
-# common QA helpers
+# Shared QA helper libraries
 add_subdirectory( qa_utils )
 add_subdirectory( unit_test_utils )
 
+# Unit tests
 add_subdirectory( common )
+add_subdirectory( pcbnew )
 add_subdirectory( shape_poly_set_refactor )
+
+# Utility/test programs
 add_subdirectory( pcb_parse_input )
+
 # add_subdirectory( pcb_test_window )
 # add_subdirectory( polygon_triangulation )
 # add_subdirectory( polygon_generator )
diff --git a/qa/pcbnew/CMakeLists.txt b/qa/pcbnew/CMakeLists.txt
index 6402eea24..abaaa9f1f 100644
--- a/qa/pcbnew/CMakeLists.txt
+++ b/qa/pcbnew/CMakeLists.txt
@@ -36,6 +36,10 @@ add_executable( qa_pcbnew
 
 test_graphics_import_mgr.cpp
 test_pad_naming.cpp
+
+# Older CMakes cannot link OBJECT libraries
+# https://cmake.org/pipermail/cmake/2013-November/056263.html
+$
 )
 
 if( BUILD_GITHUB_PLUGIN )
@@ -73,7 +77,6 @@ target_link_libraries( qa_pcbnew
 qa_utils
 lib_dxf
 idf3
-pcbnew_kiface_objects
 unit_test_utils
 ${wxWidgets_LIBRARIES}
 ${GITHUB_PLUGIN_LIBRARIES}
-- 
2.20.1

___
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] Pcbnew unit test framework

[jp charras]

Le 07/01/2019 à 12:33, John Beard a écrit :
> Hi Seth,
> 
> The revert commit (8f11a2133efd95526d1a3783dbaca76f732b8efb) also
> killed the CMake add_subdirectory (because the original commit was
> conflicted). Here is a patch to put it back in order (and put the
> existing subdirs into some order).
> 
> Cheers,
> 
> John
> 

Hi John,

As previously reported, the add_subdirectory pcbnew breaks the windows
build and some Linux builds.

Please, first fix the the build issue in qa/pcbnew.

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] Pcbnew unit test framework

[John Beard]

Hi Seth,

The revert commit (8f11a2133efd95526d1a3783dbaca76f732b8efb) also
killed the CMake add_subdirectory (because the original commit was
conflicted). Here is a patch to put it back in order (and put the
existing subdirs into some order).

Cheers,

John

On Mon, Jan 7, 2019 at 12:20 AM Seth Hillbrand  wrote:
>
> Am 2019-01-06 15:14, schrieb John Beard:
> > Hi,
> >
> > I'm not quite sure what happened here, but patch 0001 in the top email
> > hasn't been applied, but instead the RFC patch for the combined
> > utilities tool program has been applied (now commit 502306) instead.
>
> Ugh.  Sorry all!  I clearly mixed up the commits.  Should be fixed now.
>
> -Seth
From 66c1cb2d4458d8fa3d86e540a5cb6c29055bade3 Mon Sep 17 00:00:00 2001
From: John Beard 
Date: Mon, 7 Jan 2019 11:11:47 +
Subject: [PATCH] QA: Add pcbnew unit tests CMake subdir

This was accidentally removed with the reversion of the application
of the wrong patch (8f11a2133).
---
 qa/CMakeLists.txt | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/qa/CMakeLists.txt b/qa/CMakeLists.txt
index fd592f321..e0011ff77 100644
--- a/qa/CMakeLists.txt
+++ b/qa/CMakeLists.txt
@@ -12,13 +12,18 @@ if( KICAD_SCRIPTING_MODULES )
 
 endif()
 
-# common QA helpers
+# Shared QA helper libraries
 add_subdirectory( qa_utils )
 add_subdirectory( unit_test_utils )
 
+# Unit tests
 add_subdirectory( common )
+add_subdirectory( pcbnew )
 add_subdirectory( shape_poly_set_refactor )
+
+# Utility/test programs
 add_subdirectory( pcb_parse_input )
+
 # add_subdirectory( pcb_test_window )
 # add_subdirectory( polygon_triangulation )
 # add_subdirectory( polygon_generator )
-- 
2.20.1

___
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