Re: [Kicad-developers] ***UNCHECKED*** Re: Linux support for wxGLCanvas and Wayland/EGL
Hi, On Wed, Sep 30, 2020 at 08:46:46AM -0400, Wayne Stambaugh wrote: > I'm fine with adding glew to the third party directory. I'm assuming > that the plan would be to use cmake to determine if EGL support was > required and build glew accordingly. With the Debian Developer hat on: this needs an easily reachable OFF switch, because it makes packaging harder if projects ship outdated components as part of their source tree. Simon ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] ***UNCHECKED*** Re: Pcbnew - wxWidgets Debug Alerts on startup
Hi, On Tue, Aug 18, 2020 at 10:44:00PM +0100, Ian McInerney wrote: > Found the problem, it was an unintialized enum in the property system > (PCB_LAYER_T). I have just pushed a fix to master for it. That also fixes #4931. Simon ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Downloads storage maintenance
Hi Orson, On Mon, Aug 17, 2020 at 09:58:41AM +0200, Maciej Suminski wrote: > I have received a message saying that a virtual machine hosting the > downloads storage might be down on 7th September between 9:00 and 12:00. > Most likely the break will be shorter than 30 minutes. I thought we kept everything in OpenStack, and the download server was basically just a web frontend. This shouldn't affect us in any way though, nightly builds start at around 11 and take a bit over two hours. Simon signature.asc Description: PGP signature ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Kicad 6 API
Hi Conrad, On 13.07.20 14:48, Conrad Wood wrote: > I am keen on generating the outputs for manufacturing and documentation > (e.g. circuit diagram pdfs, rendered 3d-view of pcb) as part of a git > hook. There is still some UI code inside the data representation, so for now scripting can only control a GUI instance. This is kind of annoying for git hooks as you need to set up a fake display server. > I've seen various 'hacks' out there to provide a graphical 'diff'. I > would like to see the API either provide means to do a diff on two > commits of the same repository, graphical or otherwise, in such a way > that it can be integrated into a web-based process. > (with "diff" I mean a method to see where and what changes were made in > two versions by a person not trained to do PCB design. - this is mostly > to review changes and spot unintended modifications) diff/merge is non-trivial, because PCB structures are three-dimensional while files are one-dimensional strings of bytes. Anything that is able to generate meaningful diffs would need to fully understand the files, not just look for similarities. > On bigger/complex boards, there are often 'sections' which are handled > by exports. for example, radio vs memory/cpu vs powersupply. It would > absolutely awesome if we can progress KiCad to support such teams. In > my mind, I am thinking of a KiCad server which serves clients and > sections can be 'locked' and worked on simultaneously. Simultaneously I > mean, with changes being propagated to each KiCad Client in real-time. That is partially a function of diff/merge, and also requires more of a notification system than we currently have (basically, we know to update *the* view when data changes, but we'd need to track multiple views on the data and add a way for data modifications to fail because of conflicts -- plus UI presentation for that. That would require a lot of changes to internals. Simon signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] How much do we care about small memory leaks?
Hi, FWIW, I've been running the tests with memory checking enabled on both Linux and Windows (MSVC), and we have several leaks there already, some from us, some from wxWidgets, some from Gtk, some from Python, and apparently some from Boost.Test. I don't exactly trust DrMemory yet, it seems to sometimes show false positives, but I couldn't yet create simple test cases that have the same false positives. Since the test cases are low-level stuff with shallow call stacks, those should give excellent inroads into getting rid of a lot of memory checker noise. I've gotten a bit of pushback from the Gtk people on cleaning up their singletons, apparently they prefer to suppress valgrind messages after verifying that a particular object is supposed to leak. What is a bit annoying is that Jenkins seems to be unable to generate reports for this. We have summary information for our test cases in XML form, as well as log files from valgrind and DrMemory for individual cases, but these aren't yet archived or postprocessed. For report files (but only if no build is currently running :/) Linux: https://jenkins.simonrichter.eu/job/linux-kicad-head/ws/build/Testing/Temporary/ (MemoryChecker.*.log) Windows: https://jenkins.simonrichter.eu/job/windows-kicad-msvc-head/build=release,cpu=amd64,label=msvc/ws/build/Testing/Temporary/DrMemory/ Debug builds on Windows often run into timeouts because memory error report generation takes close to an hour for some tests. :/ Simon signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Compile problem with Fedora 32
Hi, On 14.05.20 07:28, victor tejada wrote: > Hello, guys, I tried to compile kicad source code on fedora 32 but the > error is > "ImportError: No module named wx > CMake Error at CMakeModules/FindwxPython.cmake:52 (message): > wxPython/Phoenix does not appear to be installed on the system > Call Stack (most recent call first): > CMakeLists.txt:740 (find_package)" > so wxPython 4.0.1 is installed on my pc. Check that it's using the Python version that wxPython was compiled against. IIRC KiCad still selects Python 2 unless told to use Python 3, so if you have wxPython for Python 3, it will not be usable. On any modern distro, you probably need to configure with -DKICAD_SCRIPTING_PYTHON3:BOOL=ON -DKICAD_SCRIPTING_WXPYTHON:BOOL=ON -DKICAD_SCRIPTING_WXPYTHON_PHOENIX:BOOL=ON Simon signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] v6 breaking changes to eeschema - starting new refactor wise?
Hi James, On 12.05.20 18:36, James Jackson wrote: > However, I've noted in a few bug reports and new feature > requests that there are likely to be significant changes to eeschema > moving towards v6 (last reference I saw was in relation to vector and > group busses). So, is it wise to start looking at a significant feature > now (if the big changes have happened already), or wait until those > changes are made, or is this not actually an issue? Just trying to avoid > wasting effort and then have to re-duplicate it later! Rebasing branches usually works for me, even with slightly conflicting changes -- perhaps the most important thing you can do in a large refactoring is to make each commit as small as possible while still being thematically consistent, and to make sure that every commit on its own compiles. So a refactoring change usually consists of 1. add new internal interface (just exists, isn't used yet) 2. move dialog 1 over to the new interface 3. move dialog 2 over to the new interface ... n. remove the now-unused old interface This allows me to just throw CPU power at rebasing. The two most important commands are $ git rebase -x 'make -C Build -j`nproc`' origin to verify that indeed every commit still compiles after rebasing, and $ for i in $(git rev-list --reverse $(git merge-base HEAD origin)..origin); do git rebase $i || break; done to rebase your branch one commit at a time to minimize conflicts. You can even combine them to $ for i in $(git rev-list --reverse $(git merge-base HEAD origin)..origin); do git rebase -x 'make -C Build -j`nproc`' $i || break; done but this will take an absurd amount of time, usually directly rebasing is sufficient. Simon signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Separate download server directory for each Windows nightly build installer version?
Hi, On Fri, Apr 24, 2020 at 11:10:27PM +0300, Eeli Kaikkonen wrote: > I keep the Windows nightly build download server page ( > https://kicad-downloads.s3.cern.ch/index.html?prefix=windows/nightly/) open > in a browser tab to download the latest nightly build, often daily. It's > slightly annoying to have four files for each nightly build: 64 and 32 bit, > and lite and full. Possible, we'd just have to change the script that calls s3cmd to copy the files. If there is consensus that this is a good thing I can do that. Simon ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] MR Test Failure Help
Hi, On Tue, Apr 21, 2020 at 03:06:50PM -0700, Emery B wrote: > My merge requests (170&171) have failed in the test step. Test passes if > merged to the latest development branch. Should I push a merge-commit to my > MR? Please advise. There is an additional test in Gitlab, which checks formatting of newly added lines. Check the report if the suggestions in there make sense to you. These only generate warnings, as there may be a good reason to deviate from the rules-as-automatically-checked. Simon ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] 5.1 branch freeze
Hi, On 16.04.20 03:30, Wayne Stambaugh wrote: > The 5.1 branch has been frozen in order to prepare for the 5.1.6 stable > release. Please do not make any commits to the 5.1 branch without first > confirming with the lead dev team and no translated string changes. Presumably that implies that translators should check whether anything needs to be done. Current translation status on the 5.1 branch seems to be LANG;TRANSLATED;FUZZY;UNTRANSLATED bg;1262;3052;1352 ca;2738;1914;1014 cs;5430;162;74 de;5666;; el;2894;2241;531 en;5666;; es;4566;948;152 fi;1240;2950;1476 fr;5666;; hu;5607;40;19 it;5666;; ja;5580;60;26 ko;370;2798;2498 lt;1853;3277;536 nl;877;3123;1666 pl;5622;34;10 pt;5656;6;4 ru;5666;; sk;1210;2751;1705 sl;292;2598;2776 sv;342;1502;3822 zh_CN;5666;; zh_TW;4541;954;171 Done: de, en, fr, it, ru, zh_CN Need work: cs, hu, ja, pl, pt The others have larger issues, and we might want to check whether they are still maintained and/or we can find volunteers for them. Simon signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Please be kind towards translators
Hi Marco, On 05.04.20 11:47, Marco Ciampa wrote: > Also these kind of messages can be reduced/shrinked: > # eeschema/sch_sexpr_parser.cpp:1152 > msgid "" > "Invalid pin number in\n" > "file: \"%s\"\n" > "line: %d\n" > "offset: %d" > into > msgid "" > "%s in\n" > "file: \"%s\"\n" > "line: %d\n" > "offset: %d" > with the first parameter %s being the error string... That has three problems: - it only saves something if all the error messages use the same template - the grammar needs to be unchanged for all errors in all languages - it requires two lookups, which looks ugly in the code While we're at it: do we have a sensible way to use context dependent positive/negative responses in different places for languages that need them, e.g. "Save?", "Yes", "No" needs to be translated into both Mandarin and Welsh as if it read "Save?", "Save." "Don't save.", because these languages affirm by repeating the verb. I dimly remember that GNU gettext has some kind of context marker, but I'm not sure if that is portable. Simon signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] Angle representation in ARC_GEOM_MANAGER
Hi, the comments for the methods setting the start and end angles say that these angles are normalized to 0..2pi, but the only thing that happens is conditionally adding 2pi if the angle is negative. Also, apparently both start and end angle being identical (tested with operator== on floating point values) is wrong. - Is (0, 2pi) a valid configuration? - Should the test use a more appropriate comparison? This is one of the candidates I'd like to replace with an auto-wrapping class that can only take values between 0 and 2*PI, exclusively, and that tests with a bit of slack even around the wrap, i.e. 0.0 == 2*M_PI - 0.1 is true. Simon ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Internal units in the KiCAD source code
Hi Wayne, On 13.02.20 20:47, Wayne Stambaugh wrote: > One thing that can be said > for sure about 64 bit internal units is that there will be a performance > hit on 32 bit architectures. The questions are how much and do we care? I'd expect that to be negligible compared to cache effects, where we lose a bit because objects grow in size, and gain a bit because we get rid of a few megabytes of almost-but-not-quite duplicated code. If we were interested in micro-optimizing, unified internal units would allow linking everything into a big application, dropping the requirement for kifaces to be position-independent code, which would give 32-bit x86 a 2-5% speedup. The big gain of unified internal units would be on the developer side, because we'd improve compilation speed, and we'd spend a lot less time explaining to new developers why we're building position independent static libraries, and why certain functions cannot be used from functions inside common/. Simon signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Internal units in the KiCAD source code
Hi,
On 13.02.20 16:06, Thomas Pointhuber wrote:
> The solution discussed was to move to 64bit and to use
> constexpr/templates handling unit conversion. So a programmer can for
> example enter 2mm and the compiler automatically converts it into the
> internal unit like nm.
> I'm still in favour of improving this. The same with angles.
Angles have to go first, because we have many different representations
based on lengths, and several of the 2D representations have overloaded
"rotate" functions that consume an angle -- so if we were to add new
length/vector/size/distance types, we'd need to add more "rotate"
functions for all of these as well.
For angles, this is somewhat complicated by the fact that we have three
different representations (radians, degrees, tenths of a degree), and
the latter can also be floating point or integer. Adding new classes is
somewhat[1] straightforward[2], but the code actually using it is full
of magic multiplications and divisions with factors like 0.1, 10,
M_PI/1800, 1800/M_PI and so on, all of which are scalar so they aren't
caught by making the new type deliberately incompatible.
Once angles are done, the same thing can be done for lengths, where,
thankfully, the magic values are somewhat confined to the headers.
One thing I really like is that we can express things like
angle a = 90_deg;
and in places where we need a scalar, such as the file reader/writer
code, we can then use
out << ( a / deg );
to write a value in degrees ("deg" is a global constexpr angle object
with a value of M_PI/180. :) ).
For the foreseeable future I'm going to concentrate on net ties, so if
anyone wants to run wild with the angle code, go ahead.
Simon
[1] lol
[2] https://gitlab.com/GyrosGeier/kicad/-/commits/refactor/angle
signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Broken Linux build
Hi, On 07.02.20 19:58, Jon Evans wrote: > In lib_id.h, LIB_ID::Test() is declared inside "#if defined(DEBUG)" > But in lib_id.cpp, LIB_ID::Test() will never be implemented because it > is wrapped in: > #if 0 && defined(DEBUG) lol, so this worked only because -DDEBUG was never defined for SWIG before (because the invocation only pulls in COMPILE_DEFINITIONS and not the CXX_FLAGS). So that's three bugs fixed today, then. ¯\_(ツ)_/¯ Simon signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Broken Linux build
Hi, On 07.02.20 19:31, Jon Evans wrote: > Good find! I think we should remove that line > (pcbnew/CMakeLists.txt:403) since it's not used. > I guess we have just been clobbering KICAD_CONFIG_DIR for swig and it > just didn't matter. Yes, that should be done for the sake of cleanup. The other thing is that this does not solve the problem. I just did a full rebuild and WTF. Simon signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Broken Linux build
Hi,
On 07.02.20 19:19, Simon Richter wrote:
> This. The COMPILE_DEFINITIONS property is applied to CC and CXX
> invocations, not to the SWIG command line.
Spoke too soon. Those are actually applied. What is happening is that
swig is invoked as
/usr/bin/swig3.0 -python -c++ -outdir /home/geier/OSS/kicad/Build/pcbnew
-I/home/geier/OSS/kicad/pcbnew -I/home/geier/OSS/kicad/include
-I/home/geier/OSS/kicad/scripting -I/home/geier/OSS/kicad/common/swig
-I/home/geier/OSS/kicad/libs/kimath/include -I -DDEBUG
-DKICAD_CONFIG_DIR=kicad -DHAVE_STDINT_H -DKICAD_SCRIPTING
-DKICAD_SCRIPTING_MODULES -DKICAD_SCRIPTING_PYTHON3
-DKICAD_SCRIPTING_WXPYTHON -DKICAD_SCRIPTING_WXPYTHON_PHOENIX
-DKICAD_SCRIPTING_ACTION_MENU -DKICAD_SPICE -DKICAD_USE_OCE
-DGLM_FORCE_CTOR_INIT -DWX_COMPATIBILITY -D_FILE_OFFSET_BITS=64
-DWXUSINGDLL -D__WXGTK__ -DPCBNEW -o
/home/geier/OSS/kicad/Build/pcbnew/pcbnew_wrap.cxx swig/pcbnew.i
Notice the -I before the -DDEBUG? The fix for -DDEBUG reordered the
preprocessor definitions, so now -DDEBUG instead of the
-DKICAD_CONFIG_DIR is interpreted as an include directory.
The -I is expanded from -I${WXPYTHON_SWIG_DIR} which is an empty
variable that is never mentioned anywhere else in the source tree.
Unless there is a configuration that sets this variable, removing that
-I line from the swig invocation is the way to go.
Simon
signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Broken Linux build
Hi, On 07.02.20 18:54, Jon Evans wrote: > Avenues of investigation I can think of: > 1) This is swig-related, and somehow it's not picking up the -DDEBUG > flag under the new way of defining it This. The COMPILE_DEFINITIONS property is applied to CC and CXX invocations, not to the SWIG command line. > 2) Somehow -DDEBUG is not being set for some systems No, that was before. :/ Simon signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Gitlab CI stuff?
Hi, On Wed, Feb 05, 2020 at 10:44:00AM -0600, Adam Wolf wrote: > I want to rekajigger the Wayne and Layne macOS build machines, and > I've had luck with other clients adding mac builders using > gitlab-runner. FWIW, I'd also like to move over at some point, but Gitlab's permission model will not allow runners to be configured by anyone with less than Maintainer status. One of the people who were at the KiCad dinner is a test engineer, it might also be valuable to get him on board here. Simon ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] How to access the fbp sources
Hi, On Tue, Feb 04, 2020 at 07:40:02PM +0100, ja...@veith.net wrote: > To access the fbp sources I tried to install the wxFormbuilder for > Ubuntu 18.04LTS. As there seems neither distro version nor Debian > packages I used the github repo with v3.9.0: I've made a set of unofficial Debian packages that live at http://simonrichter.eu/debian/ . The 3.9.0 packages have a known bug that the generated output claims to be built with 3.8.0, as that is hardcoded, but other than that the packages seem to work alright. Simon ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] , and the format checker
Hi, we have a build failure on MSVC because ngspice.cpp no longer includes . This file should really be included first by any cpp file, because it uses macros to work around compiler differences. The format checker rightly suggests that, as it is a <> include from the local project, it should go after the ** includes. Can we somehow special-case this? In the long run, we probably want to have a or similar file per project, which lists all the external includes, and is precompiled before the rest of the project, this would have the same constraint, but as a hard requirement (i.e. we get compiler errors if the include isn't the first non-comment in the file). What would be required to adjust the format checker? Simon signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] GitHub Mirror not updating?
Hi Wayne, On 20.01.20 21:25, Wayne Stambaugh wrote: > If I run the commands Simon suggested to remove the blobs, what does > this mean for devs who pull from the dev repo on gitlab? After fetching normally, using $ git fetch anyone who doesn't have local work on top can just reset their branch, using $ git reset --keep origin/master to pivot over. The --keep option makes sure that no local changes are overwritten, and complains if it would do so. If they have local work, the sanest approach is to rebase on top of origin/master and delete the offending commits at the same time by doing an interactive rebase $ git rebase -i origin/master This gives a list of all commits that don't have identical content in the old and new history. Since the filtered branch is the same except for those four, the first four lines will be pick ea31730b4 Handle error returns from lstat. pick e83420f19 Remove file accidentally commited in ea31730b4 pick e27e6ee16 Also catch null dereference in case wxASSERT was skipped. pick e1925b89c Remove file accidentally added in e27e6ee1 and all local changes will follow those. You can either delete these lines from the todo list, or replace the work "pick" by "drop". The approach using "git filter-branch" is not recommended for normal developers, because it generates another alternate history that needs to be resolved by calling "git rebase origin/master", and when you're rebasing anyway, you can also remove the commits at that point. Wayne, if you want to avoid filter-branch, you can also use an interactive rebase: $ git rebase -i 9df2cfb32 In the list, move the correction commits under the commits they fix, and replace "pick" by "fixup". The first six lines should read pick ea31730b4 Handle error returns from lstat. fixup e83420f19 Remove file accidentally commited in ea31730b4 pick b3af41e1b RTree: Fix iterator in single branch trees pick e27e6ee16 Also catch null dereference in case wxASSERT was skipped. fixup e1925b89c Remove file accidentally added in e27e6ee1 pick 7399465fd Handle nullptr. i.e. line 2 becomes "fixup", lines 5 and 6 are swapped, and line (now) 5 also becomes "fixup". Both this method and the filter-branch method alter the committer name and date in the new history, so the commit IDs are not reproducible. Anyone but Wayne can of course run the same commands and get commits with identical contents but different ID, which a normal rebase will clean up nicely. The merge request workflow probably doesn't have to change (much), since we rebase changes before merging them, for these the same interactive rebase as above works. Simon signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Rebase the tree?
Hi, On 17.01.20 19:14, Simon Richter wrote: > 1. "git rebase -i origin/master" > 2. in the editor, if they are present, remove the lines > > pick ea31730b4 Handle error returns from lstat. > pick e83420f19 Remove file accidentally commited in ea31730b4 > pick e27e6ee16 Also catch null dereference in case wxASSERT was skipped. > pick e1925b89c Remove file accidentally added in e27e6ee1 > > 3. save and exit Even less interactive: git filter-branch \ --prune-empty \ --index-filter \ 'git rm --cached --ignore-unmatch common/libcommon.a.*' \ 9df2cfb32..HEAD This rewrites the current branch to a state where the files were never added, and removes the now-empty correction commits. The SHA1 sums in the new branch are different, but as the commit contents are identical, rebasing feature branches then goes smoothly even from the gitlab GUI. If you rebased a branch containing the offending commits on top of a cleaned one, this generates four commits adding and removing the files with no further changes, and the filter-branch commit above then reduces these to no-ops and removes the commits. A simple test in gitlab *merge request is descended from e1925b89c" could identify merge requests that would need to be rewritten. Simon signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Rebase the tree?
Hi, On 17.01.20 20:03, Nhat Khai wrote: > This is call "refactor" de facto git history for better future :-). It > that occurred, may as well add git-lfs for large bin files as well- will > help reduce time for fresh clone too. No, we're not supposed to have large binary files in that tree -- which is why accidentally checking in some is such a big deal. Simon signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Rebase the tree?
Hi, On 17.01.20 18:02, Ian McInerney wrote: > You can't just use the `git rebase > master devBranch` command to fix it, since that will go back to the last > unchanged commit before the binary blobs, then replay all the contents > of their branch since then onto the current master - which will include > the commits from master itself that they picked up since the binary > blobs. Not all of our contributors have an enormous amount of experience > using git, so that could be difficult for them to do properly. Indeed, automatic rebases end up with the four commits, reduced to just the insertion and deletion of the files, before the rebased branch. What works is using rebase -i, and removing the four commits from the list, so we could tell people to do that: 1. "git rebase -i origin/master" 2. in the editor, if they are present, remove the lines pick ea31730b4 Handle error returns from lstat. pick e83420f19 Remove file accidentally commited in ea31730b4 pick e27e6ee16 Also catch null dereference in case wxASSERT was skipped. pick e1925b89c Remove file accidentally added in e27e6ee1 3. save and exit The sooner we do this, the fewer people will have branches based on these. I'm not worried about the CI systems, these have long pulled the objects, and haven't run out of space as a result, but it makes fresh clones a lot slower than they need to be, especially over https, where shallow clones cannot be negotiated. Simon signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Rebase the tree?
Hi Seth, On Fri, Jan 17, 2020 at 06:53:46AM -0800, Seth Hillbrand wrote: > >there are two massive blobs that were accidentally checked in, and > >checking > >out the repo requires these to be transferred. Should we make an > >exception > >and rebase the tree to remove them from the history? > I would say no. History is inviolate. True, but it's a significant chunk of useless history: -r--r--r-- 1 geier geier 5685856 Jan 17 16:40 pack-1478d96c882a625a8a6a25cac9ec2b8e514a2e61.idx -r--r--r-- 1 geier geier 157961655 Jan 17 16:40 pack-1478d96c882a625a8a6a25cac9ec2b8e514a2e61.pack -r--r--r-- 1 geier geier 1100 Jan 17 16:38 pack-81e52eb60810956fd5294dc2fb1ee61ce1aa7438.idx -r--r--r-- 1 geier geier 20734471 Jan 17 16:38 pack-81e52eb60810956fd5294dc2fb1ee61ce1aa7438.pack -r--r--r-- 1 geier geier 1100 Jan 17 16:37 pack-e18ed50ebfea3897568189f3806d0a2e7051dd37.idx -r--r--r-- 1 geier geier 44601959 Jan 17 16:37 pack-e18ed50ebfea3897568189f3806d0a2e7051dd37.pack The largest pack at 160 MB is our development history excluding these two files, the other two are the two files packed individually. They compress fairly well, but this is still 37.5% of our repository size. Simon ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] Rebase the tree?
Hi, there are two massive blobs that were accidentally checked in, and checking out the repo requires these to be transferred. Should we make an exception and rebase the tree to remove them from the history? Simon ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] What is the right build target to produce an installation zip.
Hi, On Thu, Jan 09, 2020 at 12:12:43PM -0500, Brian Piccioni wrote: > How do I make a file I can unzip to/install to my Windows programs > directory? Packaging is external to the build tools, there is a separate KiCad-Winbuilder[1] project that does that. Simon [1] https://gitlab.com/kicad/packaging/kicad-win-builder ___ 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] unreleased wxFormBuilder
Hi, On Mon, Jan 06, 2020 at 05:16:30AM -0800, Seth Hillbrand wrote: > >Apparently development versions also generate output with whitespace > >errors and, in one case, compute a size differently, that might also be > >interesting to watch in the future. > I'm not really concerned about the warning, dire as it is worded. > However, I would like to know which dialog was sized differently. > One of the reasons we were OK with development versions is that > wxformbuilder is so buggy that 3.8.0 was not useable for certain > controls. Regenerating pcbnew/dialogs/dialog_text_properties_base.fbp with 3.9.0 gives a different default size (height 563 instead of 463) compared with the unreleased version it was generated before.[1] (I know the patch says 3.8.0 -- my Debian package hardcoded that, and I didn't fix it before rebuilding, but this is the state from the 3.9.0 release) Simon [1] https://gitlab.com/kicad/code/kicad/merge_requests/45/diffs#b56671c731bede3525b64ef8f4780a86125d86c5 ___ 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] unreleased wxFormBuilder
Hi, we've been asked on IRC about a dire warning "you WILL lose data if you save" from wxFormBuilder when opening some of the files. Apparently there are new fields in the XML, but the format version hasn't been bumped yet, because there was no new release. Can we tighten the wxFB requirement to "3.8.0 or later releases" to avoid this? Merge request moving all affected files back to a release version is at https://gitlab.com/kicad/code/kicad/merge_requests/45 Apparently development versions also generate output with whitespace errors and, in one case, compute a size differently, that might also be interesting to watch in the future. Simon signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] GitLab bug workflow
Hi, On Wed, Dec 04, 2019 at 11:09:58AM +, Jeff Young wrote: > Forgive me if this was communicated and I missed it, but when do we > transition a GitLab bug from Open to Closed? At Fix-Committed or > Fix-Released? Can't gitlab track bugs vs commits, and generate open/closed states for the branch one is working on? (I mean, even debbugs can do that) Simon ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Strokefont change from std::deque to std::vector
Hi, On Tue, Dec 03, 2019 at 03:27:26PM +, Jeff Young wrote: > Changing the glyph back to a deque (and leaving the strokes vectors) would > probably alleviate much of the performance hit — but I’m not sure if it would > bring back the memory issues or not. Would it make sense to build it up as a list or deque, perhaps with a custom allocator, and then copy the contents to a vector once the length is known? Simon ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] Fixes for Visual Studio / vcpkg build
Hi Nick, On 01.12.19 20:07, Nick Østergaard wrote: > OK, cool, it looks like the msvc builds on jenkins are back in green again :) > https://jenkins.simonrichter.eu/job/windows-kicad-msvc-head/ They were broken at the same time as the Linux builds :) Simon signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] GitLab migration
Hi Wayne, On Fri, Nov 29, 2019 at 12:49:30PM -0500, Wayne Stambaugh wrote: > I will also be disabling the Launchpad blueprint and answers pages as > well. We not going to migrate the blueprints to GitLab because the > entire blueprint system is a mess due to the lack of sane permissions. > We may have to manually migrate the useful blueprints to GitLab once we > have a reasonable process for doing so. One of my main hopes for the migration is to get a workflow for collaborative pre-implementation design. Blueprints were a nice idea, but they were never fully implemented on Launchpad, and it shows. It'd probably make sense to use the Wiki for that, do you know if it is possible for non-committers to have limited Wiki editing rights (e.g. an "ideas" namespace with looser permissions, and moving the page to the "roadmap" namespace later)? Simon ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] ***UNCHECKED*** Re: Re: GitLab migration
Hi Seth, On Wed, Nov 27, 2019 at 06:29:11AM -0800, Seth Hillbrand wrote: > >Ah, so that's why my application was ignored. :) > Sorry about that Simon. My inbox got flooding with permission > applications for folks and I haven't been able to find time yet to > got through all and respond to people. I suspect yours is in there > somewhere. Which section should your permissions be in? No hurry, so far there isn't much I can sensibly do on Gitlab anyway. I've withdrawn the "general" application, and submitted new ones for "code/kicad" (which would probably be at some non-commit-but-able-to-send-merge-requests level) and for packaging/kicad-winbuilder (where it might make sense for me to have commit). > It would be very good to have it set up as a Windows runner. Right > now, we only have Linux free runners. The Windows runners are > supposed to come online in a few months. Mac runners sometime next > year (maybe). Would you have time to dig into a CI script for the > code? Unsure how much time I will have, but there is always procrastination of more urgent things that opens up time slots for kicad work. Setting up a runner needs a lot of permissions, or at least someone with a lot of permissions extracting the necessary access token, as Github are rightfully assuming that runner administrators have a lot of access to the pipeline anyway, so I'll probably start by setting up my own projects on Gitlab with my machine configured as a runner, and then subsequently "sharing" that runner once it's working. Simon ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] ***UNCHECKED*** Re: GitLab migration
Hi Seth, On Tue, Nov 26, 2019 at 12:54:31PM -0800, Seth Hillbrand wrote: > Wayne and the bot have permissions for the entire project. I'm > there while sorting out the transition work. Coding permissions are > specific to https://gitlab.com/kicad/code/ . Library permissions > are specific to https://gitlab.com/kicad/libraries/ , etc. Ah, so that's why my application was ignored. :) > Once I get the > packaging section set up, we'll have folks in charge of their > relative builds that we can run through the GitLab CI runner > interface. Should I add my box as a runner then, so we don't run into time limits, or do we first see how far we get with the free offer? Simon ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] [PATCH 0/1] Experimental code for running tests separately
Hi, this is not meant for immediate merging, but maybe of interest to some: this patch splits the test cases inside the Boost.Test based tests in a way that is visible to CTest. The downside is that running the tests now takes ages because Boost.Test setup is really slow, the upside is that individual test cases show up in the log, and no trickery with logfiles is needed. Running valgrind on individual tests is also possible in theory, but useless in practice because glib doesn't have an equivalent to __libc_freeres(), so we get 294 false positives from glib for every test. If someone wants to pursue this further, here is the code. Simon Simon Richter (1): Split Boost.Test based tests CMakeModules/BoostTest.cmake | 204 +++ CMakeModules/BoostTestAddTests.cmake | 138 ++ qa/CMakeLists.txt| 1 + qa/common/CMakeLists.txt | 6 +- qa/eeschema/CMakeLists.txt | 2 +- qa/libs/sexpr/CMakeLists.txt | 2 +- qa/pcbnew/CMakeLists.txt | 2 +- qa/utils/kicad2step/CMakeLists.txt | 2 +- 8 files changed, 350 insertions(+), 7 deletions(-) create mode 100644 CMakeModules/BoostTest.cmake create mode 100644 CMakeModules/BoostTestAddTests.cmake -- 2.24.0 ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] [PATCH 1/1] Split Boost.Test based tests
--- CMakeModules/BoostTest.cmake | 204 +++ CMakeModules/BoostTestAddTests.cmake | 138 ++ qa/CMakeLists.txt| 1 + qa/common/CMakeLists.txt | 6 +- qa/eeschema/CMakeLists.txt | 2 +- qa/libs/sexpr/CMakeLists.txt | 2 +- qa/pcbnew/CMakeLists.txt | 2 +- qa/utils/kicad2step/CMakeLists.txt | 2 +- 8 files changed, 350 insertions(+), 7 deletions(-) create mode 100644 CMakeModules/BoostTest.cmake create mode 100644 CMakeModules/BoostTestAddTests.cmake diff --git a/CMakeModules/BoostTest.cmake b/CMakeModules/BoostTest.cmake new file mode 100644 index 0..ec3419694 --- /dev/null +++ b/CMakeModules/BoostTest.cmake @@ -0,0 +1,204 @@ +# Distributed under the OSI-approved BSD 3-Clause License. See accompanying +# file Copyright.txt or https://cmake.org/licensing for details. + +#[===[.rst: +BoostTest +-- + +This module defines functions to help use the Boost.Test infrastructure. + +The :command:`boost_test_discover_tests` discovers tests by asking the +compiled test executable to enumerate its tests. + +This commands is intended to replace use of :command:`add_test` to register +tests, and will create a separate CTest test for each Boost.Test test case. +Note that this is in some cases less efficient, as common set-up and tear-down +logic cannot be shared by multiple test cases executing in the same instance. +However, it provides more fine-grained pass/fail information to CTest, which is +usually considered as more beneficial. By default, the CTest test name is the +same as the Boost.Test name (i.e. ``suite.testcase``); see also +``TEST_PREFIX`` and ``TEST_SUFFIX``. + +.. command:: boost_test_discover_tests + + Automatically add tests with CTest by querying the compiled test executable + for available tests:: + +boost_test_discover_tests(target + [EXTRA_ARGS arg1...] + [WORKING_DIRECTORY dir] + [TEST_PREFIX prefix] + [TEST_SUFFIX suffix] + [PROPERTIES name1 value1...] + [TEST_LIST var] + [DISCOVERY_TIMEOUT seconds] +) + + ``boost_test_discover_tests`` sets up a post-build command on the test executable + that generates the list of tests by parsing the output from running the test + with the ``--boost_test_list_tests`` argument. This ensures that the full list of + tests, including instantiations of parameterized tests, is obtained. Since + test discovery occurs at build time, it is not necessary to re-run CMake when + the list of tests changes. + However, it requires that :prop_tgt:`CROSSCOMPILING_EMULATOR` is properly set + in order to function in a cross-compiling environment. + + Additionally, setting properties on tests is somewhat less convenient, since + the tests are not available at CMake time. Additional test properties may be + assigned to the set of tests as a whole using the ``PROPERTIES`` option. If + more fine-grained test control is needed, custom content may be provided + through an external CTest script using the :prop_dir:`TEST_INCLUDE_FILES` + directory property. The set of discovered tests is made accessible to such a + script via the ``_TESTS`` variable. + + The options are: + + ``target`` +Specifies the Boost.Test executable, which must be a known CMake +executable target. CMake will substitute the location of the built +executable when running the test. + + ``EXTRA_ARGS arg1...`` +Any extra arguments to pass on the command line to each test case. + + ``WORKING_DIRECTORY dir`` +Specifies the directory in which to run the discovered test cases. If this +option is not provided, the current binary directory is used. + + ``TEST_PREFIX prefix`` +Specifies a ``prefix`` to be prepended to the name of each discovered test +case. This can be useful when the same test executable is being used in +multiple calls to ``boost_test_discover_tests()`` but with different +``EXTRA_ARGS``. + + ``TEST_SUFFIX suffix`` +Similar to ``TEST_PREFIX`` except the ``suffix`` is appended to the name of +every discovered test case. Both ``TEST_PREFIX`` and ``TEST_SUFFIX`` may +be specified. + + ``PROPERTIES name1 value1...`` +Specifies additional properties to be set on all tests discovered by this +invocation of ``boost_test_discover_tests``. + + ``TEST_LIST var`` +Make the list of tests available in the variable ``var``, rather than the +default ``_TESTS``. This can be useful when the same test +executable is being used in multiple calls to ``boost_test_discover_tests()``. +Note that this variable is only available in CTest. + + ``DISCOVERY_TIMEOUT num`` +Specifies how long (in seconds) CMake
[Kicad-developers] [PATCH] Enable full CTest framework
This allows asking CTest for running the test suite under valgrind --- CMakeLists.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CMakeLists.txt b/CMakeLists.txt index 7f6ee37a5..81e5dc8ae 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -980,7 +980,7 @@ if( UNIX AND NOT APPLE ) ) endif() -#include( CTest ) +include( CTest ) enable_testing() if( UNIX AND NOT APPLE ) ___ 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] Building Kicad on Windows 10/Eclipse/Msys2
Hi, On Thu, Nov 21, 2019 at 09:30:48PM -0500, Brian Piccioni wrote: > Download the Kicad source files from > https://github.com/KiCad/kicad-source-mirror; > Untar or unzip into /home/kicad-source-mirror-master This probably should be "use git to get the source tree", otherwise I think this might be a valuable addition to the website. Simon ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] KiCad Assembly at 36C3
Hi, On Wed, Nov 20, 2019 at 12:57:31PM +0100, Carlo Maragno wrote: > I saw that Seth was planning to do something similar at fosdem. Yes, I'm also going there, and that is probably where the interesting stuff happens, since there are people there with insight into the codebase and a general idea where it is headed. If we wanted to do KiCad hacking at Congress, the opportunity I see there is more shaped like "we can motivate each other, and if anyone needs to repeatedly compile stuff, I can just throw the big machines into the van that's going anyway, so the logistical effort is minimal." I'm not carrying these boxes around just for the fun of it, especially if there is no good place to put them, so we should decide if there are enough people that it makes sense to reserve a table. Simon ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] KiCad Assembly at 36C3
Hi, On Tue, Nov 19, 2019 at 10:31:36PM +0100, Carlo Maragno wrote: > an assembly is just a table and some power cords. It's meant to serve as a > base for people to gather and hack around. If there is a critical mass of people who want to do development work, I could bring two machines for compiling stuff on. Simon ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] GitLab migration
Hi, On Sun, Nov 10, 2019 at 06:43:33PM +0100, Maciej Suminski wrote: > Good catch, thanks! I think I have already found the bug, I will let you > know after the next run is finished. Quick question: if I have a new bug report, should I file it in LP or in gitlab or wait until migration is done? Simon ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Test failures
Hi Jeff, On Sun, Nov 10, 2019 at 11:45:20AM +, Jeff Young wrote: > I’ve pushed changed which I hope will fix the spacing problem (but I never > got the test environment working on my Mac so I’m not 100% sure). Looks good. Simon ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] Test failures
Hi, we seem to have picked up two test failure reports[1]: [Info] - check KI_TEST::SexprIsListOfLength( (SEXPR::SEXPR&) s_list, 5 ) has passed == [File] - /var/lib/jenkins-agent/workspace/linux-kicad-head/src/qa/libs/sexpr/test_sexpr.cpp == [Line] - 101 == [Context] Sexpr string conversion mismatch: got '(symbol (2 42.42 "substring") 1 3.14 "string")', expected '(symbol (2 42.42 "substring") 1 3.14 "string")' [Info] - check KI_TEST::SexprConvertsToString( *sexp, c.m_input ) has passed == [File] - /var/lib/jenkins-agent/workspace/linux-kicad-head/src/qa/libs/sexpr/test_sexpr_parser.cpp == [Line] - 235 [Info] - check KI_TEST::SexprConvertsToString( *sexp, c.m_input ) has passed == [File] - /var/lib/jenkins-agent/workspace/linux-kicad-head/src/qa/libs/sexpr/test_sexpr_parser.cpp == [Line] - 235 == [Context] empty list == [Context] simple list == [Context] nested list == [Context] Sexpr string conversion mismatch: got '(42 (1 2))', expected '(42 (1 2))' These aren't in the build log[2]: Running tests... /usr/bin/ctest --force-new-ctest-process Test project /var/lib/jenkins-agent/workspace/linux-kicad-head/build Start 1: qa_python 1/8 Test #1: qa_python Passed0.47 sec Start 2: common_eeschema 2/8 Test #2: common_eeschema .. Passed0.16 sec Start 3: common_pcbnew 3/8 Test #3: common_pcbnew Passed0.17 sec Start 4: qa_common_gerbview 4/8 Test #4: qa_common_gerbview ... Passed0.16 sec Start 5: pcbnew 5/8 Test #5: pcbnew ... Passed0.15 sec Start 6: eeschema 6/8 Test #6: eeschema . Passed0.15 sec Start 7: sexpr 7/8 Test #7: sexpr Passed0.02 sec Start 8: kicad2step 8/8 Test #8: kicad2step ... Passed0.02 sec It seems the difference is in the number of indentations, so this is a minor issue, but I'm confused about errors in the report file and a clean log file, that is probably a bigger problem. Simon [1] https://jenkins.simonrichter.eu/job/linux-kicad-head/3781/testReport/ [2] https://jenkins.simonrichter.eu/job/linux-kicad-head/3781/console ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Back annotate references from PCB
Hi, On Wed, Nov 06, 2019 at 08:26:52AM -0500, Wayne Stambaugh wrote: > > May I implement some back annotation feature from PCB to schematic? > You are welcome to contribute to KiCad. I suspect it will not be as > easy as you think it will be. Complex schematic hierarchies (using the > same schematic more than once in a design) always trips up new developers. I dimly remember that there was some work (Ian did that IIRC) to make the netlist the master document and attach the schematic and PCB information to that, with a first patch to keep the netlist up-to-date continuously. It would probably make sense to join that effort, because any other solution would conflict heavily with that. Simon ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Benchmarking kicad compilation on CPUs released 6 years apart
Hi, I've made another quick run for Release builds: MakeNinja Scripting ON5:19.66 5:03.91 3336% 3565% Scripting OFF 3:33.84 3:08.50 4947% 5684% That is with -j64 on 2 socket T2P9D01. You can see that dependency generation makes about 15 seconds difference (the CMake generator for Makefiles has that as a separate step, while the generator for Ninja knows how to output dependency information during the first build). The Python scripting makes a huge difference, because the Swig header needs to be generated before we can start on the pcbnew subdirectory, and both this generator and compiling the wrappers take ages, so there is less parallelism. Even a factor of 56.84 is quite some distance from 64, so there may be some potential left. Simon ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Benchmarking kicad compilation on CPUsreleased 6 years apart
Hi, On Wed, Oct 30, 2019 at 06:49:15PM +0100, Holger Vogt wrote: > Would you mind to switch to tag ngspice-31.3? There have been a lot > of bug fixes an enhancements, many of them initiated by KiCad users. Just did, next MSVC build should use that. Note that we mostly use my MSVC builds for the compiler diagnostics, and almost nobody runs these binaries for real (largely because Python support is missing). They do work whenever I try them, though. Simon ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Benchmarking kicad compilation on CPUs released 6 years apart
Hi, On Tue, Oct 29, 2019 at 07:00:48PM +0100, Tomasz Wlostowski wrote: > $ make -j12 > real 7m59.758s > user 86m44.231s > sys 5m9.724s That is more than 1100% CPU usage, with -j12, so very close to full usage. How is that even possible, don't you have that two minute phase at the end of building pcbnew_kiface where it's just building pcbnew_wrap.cxx.o and everything else is done? Simon ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Benchmarking kicad compilation on CPUsreleased 6 years apart
Hi, On Tue, Oct 29, 2019 at 05:28:07PM -0400, Brian Piccioni wrote: > Do you use Visual Studio to compile Kicad? If so, how? I’m not very good with > things like cmake and I’ve tried and tried to get KiCad (or even just PCBNew) > to compile with Visual Studio and end up with various problems I can’t solve > like missing packages, etc.. I'm still doing automatic Visual Studio builds on Jenkins, and I think I've found all places where I need to do "@echo on" so all commands show up in the build logs. There is a vcpkg based build[1] that is missing a few packages, but you can probably lift the vcpkg incantations and the cmake integration of vcpkg from there. There is also a everything-from-scratch Visual Studio build[2] that pulls in all required packages as artifacts and gives them to cmake in a way that it understands, which sometimes are cmake variables and sometimes environment variables. I'd probably get started with vcpkg, and then add the missing packages from the everything-from-scratch recipes. The required packages are collected on a separate page[3] on my Jenkins installation. If you really want to do a good deed, you can make vcpkg packages from the missing stuff and submit them. Simon [1] https://jenkins.simonrichter.eu/job/windows-kicad-msvc-vcpkg/ [2] https://jenkins.simonrichter.eu/job/windows-kicad-msvc-head/ [3] https://jenkins.simonrichter.eu/view/MSVC/ ___ 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] Benchmarking kicad compilation on CPUs released 6 years apart
Hi, On Mon, Oct 28, 2019 at 10:20:45PM -0700, Andrew Lutsenko wrote: > I kinda expected 2x maybe 3x decrease because not all computations scale > linearly with number of threads. I was pleasantly surprised by almost 6x > decrease in clean build time and 5x in incremental builds. FWIW, we have a number of bottlenecks in the build process: - dependency generation of common doesn't start until the version header is generated, which only happens after bitmaps and gal are complete - dependency generation of pcbnew_kiface doesn't start until the python wrapper is generated, which takes ages itself. - the python wrapper is compiled as one of the last things, and the linker must wait for that. We could probably shave off another two or three minutes of build time if we could make sure that we always make progress on the critical path. The dependency generation as a side effect pulls all the sources and headers into cache, which reduces the effects of I/O latency a bit during compilation, so parallelizing with more than the number of threads you actually have is probably counterproductive. Numbers with CPU time as percent of real time: clean ~15 ~5 tip E5-2620v4 (32) 7:04.87 5:18.74 5:16.64 3:40.92 2243% 1854% 1854% 1330% T2P9D01 (64)5:16.37 4:14.04 4:10.26 3:20.97 3360% 2558% 2570% 1546% Simon ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] Quote characters
Hi, Minor issue, but still a bit of an annoyance: quote characters in strings are wildly inconsistent. Some places use double quotes, some use single quotes, some use angle brackets. It might make sense to make a visual distinction for different kinds of objects, e.g.: Cannot open "file name": No such file or directory Signal 'RESET' is tied to signal 'GND'. Component pin 'VCC' (1) is not driven. At least consistently using double quotes would be a marked improvement though. Translations can use localized quotes, so each language should have their own consistent set. I'd expect German to use „file name“ everywhere, never ‚file name‘, for example. Simon signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Python files still depending on Python2 only due used shebang
Hi Wayne, On 26.10.19 19:00, Wayne Stambaugh wrote: > None the less, there is currently no wxPhoenix/Python3 support for windows. TBH, I wouldn't like to be dependent on MSVC on Windows -- the compiler is great as an additional source of diagnostics, and some people might like the smaller runtime, but in the end we want to be 100% free software. Simon signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] [PATCH] Update python defaults
Python 2 is deprecated upstream, and most distributions are switching to Python 3 as default, and ship wxPython Phoenix as the wxWidgets binding for Python 3. --- CMakeLists.txt | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/CMakeLists.txt b/CMakeLists.txt index a80e90bc8..24f8d5988 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -69,16 +69,16 @@ option( KICAD_SCRIPTING_MODULES ON ) option( KICAD_SCRIPTING_PYTHON3 -"Build for Python 3 instead of 2 (default OFF)." -OFF ) +"Build for Python 3 instead of 2 (default ON)." +ON ) option( KICAD_SCRIPTING_WXPYTHON "Build wxPython implementation for wx interface building in Python and py.shell (default ON)." ON ) option( KICAD_SCRIPTING_WXPYTHON_PHOENIX -"Use new wxPython binding (default OFF)." -OFF ) +"Use new wxPython binding (default ON)." +ON ) option( KICAD_SCRIPTING_ACTION_MENU "Build a tools menu with registered python plugins: actions plugins (default ON)." ___ 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] Update python defaults
Hi, On 26.10.19 18:55, Simon Richter wrote: > Python 2 is deprecated upstream, and most distributions are switching > to Python 3 as default, and ship wxPython Phoenix as the wxWidgets > binding for Python 3. This is mainly to get the ball rolling -- before this can be applied on master I'm going to do a round of -patch builds so we can see what exactly breaks if we do this. Simon signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] Implement auto annotation on component/symbol placement.
Hi, On 28.09.19 20:40, Zficani Zficani wrote: > This patch adds an option to automatically annotate components/symbols > when they're placed, copied or duplicated. Configuration can be found > in Preferences and it is akin to 'Annotate Schematic...' tool. User can > choose how they want their components number and whether the whole > schematic should be taken into account when doing so. - Needs rebase - Compile/testsuite tested on Linux, each commit individually. - Needs whitespace cleanup (spaces at EOL, empty line at EOF) Simon signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] Project Wiki?
Hi, not sure if I've asked this already: is there some place where I could post design documents for review and archival? Launchpad has Blueprints for sorting design documents, but the system assumes that the actual document lives in a Wiki somewhere, because it is expected to change during the review process. Should I just use GitHub here, or commandeer some EtherPad or ChaosPad, or do we have a better place for unfinished documents? Simon signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] Failing tests
Hi, we have three new test failures[1] (same test, with different internal units): - Common.library.module.tests.Segment [Error] - check SegCollideCorrect( c.m_seg_a, c.m_seg_b, c.m_clearance, c.m_exp_coll ) has failed for ( [ [ 0 | 0 ] - [ 10 | 0 ] ], [ [ 0 | 10 ] - [ 10 | 10 ] ], 10, false )Parallel, 10 apart, 10 clearCollision incorrect: expected 0, got 1 == [File] - /var/lib/jenkins/workspace/linux-kicad-head/src/qa/common/geometry/test_segment.cpp == [Line] - 360 == [Context] Parallel, 10 apart, 10 clear == [Context] Collision incorrect: expected 0, got 1 [Error] - check SegCollideCorrect( c.m_seg_a, c.m_seg_b, c.m_clearance, c.m_exp_coll ) has failed for ( [ [ 0 | -10 ] - [ 0 | 0 ] ], [ [ -20 | 0 ] - [ -2 | 0 ] ], 2, false )T-junction, 2 apart, 2 clearCollision incorrect: expected 0, got 1 == [File] - /var/lib/jenkins/workspace/linux-kicad-head/src/qa/common/geometry/test_segment.cpp == [Line] - 360 == [Context] T-junction, 2 apart, 2 clear == [Context] Collision incorrect: expected 0, got 1 This was introduced[2] by one of Fix zero failure in SEG::PointCloserThan(). — jeff Performance enhancement. — jeff Simon [1] https://jenkins.simonrichter.eu/job/linux-kicad-head/3603/testReport/ [2] https://jenkins.simonrichter.eu/job/linux-kicad-head/3603/changes ___ 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 2/2] Remove questionable useless casts
Hi, On Fri, Sep 06, 2019 at 10:09:07PM -0400, Reece R. Pollack wrote: > >-const float posYfactor = (float)(windowsPos.y + y * > >4.0f) / (float)m_windowSize.y; > >+const float posYfactor = windowsPos.y + y * 4.0f / > >(float)m_windowSize.y; > These are mathematically different expressions. You need to restore > the parenthesis around the numerator expression even if you remove > the cast. Good catch, thanks! > I would further argue that in many cases removing the cast is less > clear than explicitly indicating how you want the expression > interpreted, even if the expressions were the same. Yes, my hope was that the first patch only had cases where the cast didn't add any valuable information. There are still a lot of places where the useless cast is part of a macro or a printf statement, I've left those alone (that's also why I didn't add a warning). Simon ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] [PATCH 2/2] Remove questionable useless casts
These are also reported by gcc -Wuseless-casts as having the same source
and destination type, so the new code is equivalent to the old, but it is
less immediately obvious that this interpretation was originally intended.
---
.../3d_render_raytracing/c3d_render_raytracing.cpp| 2 +-
pcbnew/swig/pcbnew_action_plugins.cpp | 4 ++--
pcbnew/tools/selection_tool.cpp | 2 +-
polygon/clipper.cpp | 4 ++--
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/3d-viewer/3d_rendering/3d_render_raytracing/c3d_render_raytracing.cpp b/3d-viewer/3d_rendering/3d_render_raytracing/c3d_render_raytracing.cpp
index 0940caa8a..967daaf93 100644
--- a/3d-viewer/3d_rendering/3d_render_raytracing/c3d_render_raytracing.cpp
+++ b/3d-viewer/3d_rendering/3d_render_raytracing/c3d_render_raytracing.cpp
@@ -1126,7 +1126,7 @@ void C3D_RENDER_RAYTRACING::render_preview( GLubyte *ptrPBO )
for( unsigned int y = 0; y < RAYPACKET_DIM; ++y )
{
-const float posYfactor = (float)(windowsPos.y + y * 4.0f) / (float)m_windowSize.y;
+const float posYfactor = windowsPos.y + y * 4.0f / (float)m_windowSize.y;
bgColor[y] = (SFVEC3F)m_settings.m_BgColorTop * SFVEC3F(posYfactor) +
(SFVEC3F)m_settings.m_BgColorBot * ( SFVEC3F(1.0f) - SFVEC3F(posYfactor) );
diff --git a/pcbnew/swig/pcbnew_action_plugins.cpp b/pcbnew/swig/pcbnew_action_plugins.cpp
index d00a5c459..f91f4487f 100644
--- a/pcbnew/swig/pcbnew_action_plugins.cpp
+++ b/pcbnew/swig/pcbnew_action_plugins.cpp
@@ -396,7 +396,7 @@ void PCB_EDIT_FRAME::buildActionPluginMenus( ACTION_MENU* actionMenu )
item = AddMenuItem( actionMenu, wxID_ANY, ap->GetName(), ap->GetDescription(), bitmap );
Connect( item->GetId(), wxEVT_COMMAND_MENU_SELECTED,
- (wxObjectEventFunction) (wxEventFunction) (wxCommandEventFunction) &
+ (wxEventFunction) (wxCommandEventFunction) &
PCB_EDIT_FRAME::OnActionPluginMenu );
ACTION_PLUGINS::SetActionMenu( ii, item->GetId() );
@@ -432,7 +432,7 @@ void PCB_EDIT_FRAME::AddActionPluginTools()
wxID_ANY, wxEmptyString, bitmap, ap->GetName() );
Connect( button->GetId(), wxEVT_COMMAND_MENU_SELECTED,
-(wxObjectEventFunction) (wxEventFunction) (wxCommandEventFunction) &
+(wxEventFunction) (wxCommandEventFunction) &
PCB_EDIT_FRAME::OnActionPluginButton );
// Link action plugin to button
diff --git a/pcbnew/tools/selection_tool.cpp b/pcbnew/tools/selection_tool.cpp
index 3b45a9237..3e760b4bd 100644
--- a/pcbnew/tools/selection_tool.cpp
+++ b/pcbnew/tools/selection_tool.cpp
@@ -2064,7 +2064,7 @@ void SELECTION_TOOL::GuessSelectionCandidates( GENERAL_COLLECTOR& aCollector,
if( track->GetNetCode() != via->GetNetCode() )
continue;
-double lenRatio = (double) ( track->GetLength() + track->GetWidth() ) /
+double lenRatio = ( track->GetLength() + track->GetWidth() ) /
(double) via->GetWidth();
if( lenRatio > trackViaLengthRatio )
diff --git a/polygon/clipper.cpp b/polygon/clipper.cpp
index fc9cb8f67..05841ab60 100644
--- a/polygon/clipper.cpp
+++ b/polygon/clipper.cpp
@@ -388,10 +388,10 @@ public:
if( hi < 0 )
{
if( lo == 0 ) return (double) hi * shift64;
-else return -(double) (~lo + ~hi * shift64);
+else return -(~lo + ~hi * shift64);
}
else
-return (double) (lo + hi * shift64);
+return (lo + hi * shift64);
}
};
// --
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
[Kicad-developers] [PATCH 1/2] Remove useless casts
This removes casts where source and destination type are identical, as reported by gcc -Wuseless-cast. All of these should be trivial. --- 3d-viewer/3d_cache/sg/sg_helpers.h | 4 ++-- 3d-viewer/3d_canvas/create_layer_items.cpp | 10 +- 3d-viewer/3d_model_viewer/c3d_model_viewer.cpp | 2 +- .../c3d_render_ogl_legacy.cpp | 2 +- .../3d_render_ogl_legacy/clayer_triangles.h| 4 ++-- .../accelerators/cbvh_pbrt.cpp | 2 +- .../c3d_render_createscene.cpp | 8 .../c3d_render_raytracing.cpp | 2 +- .../shapes2D/citemlayercsg2d.cpp | 6 ++ .../shapes2D/cpolygon2d.cpp| 2 +- .../shapes3D/clayeritem.cpp| 4 ++-- 3d-viewer/3d_rendering/cimage.cpp | 4 ++-- 3d-viewer/3d_rendering/cpostshader.h | 2 +- 3d-viewer/3d_rendering/trackball.cpp | 12 ++-- bitmap2component/bitmap2cmp_main.cpp | 2 +- common/base_struct.cpp | 2 +- common/bezier_curves.cpp | 4 ++-- common/board_printout.cpp | 2 +- common/draw_panel_gal.cpp | 4 ++-- common/gal/opengl/opengl_compositor.cpp| 6 +++--- common/gal/opengl/opengl_gal.cpp | 2 +- common/gal/opengl/shader.cpp | 4 ++-- common/lib_table_base.cpp | 2 +- common/tool/picker_tool.cpp| 2 +- common/utf8.cpp| 2 +- common/view/view.cpp | 4 ++-- common/widgets/footprint_preview_widget.cpp| 4 ++-- common/widgets/net_selector.cpp| 2 +- common/xnode.cpp | 4 ++-- cvpcb/cvpcb.cpp| 2 +- cvpcb/display_footprints_frame.cpp | 2 +- dxflib_qcad/dl_dxf.cpp | 2 +- eeschema/dialogs/dialog_erc.cpp| 2 +- eeschema/generate_alias_info.cpp | 2 +- eeschema/hierarch.cpp | 2 +- eeschema/libedit/toolbars_libedit.cpp | 2 +- .../netlist_exporter_pspice.cpp| 2 +- eeschema/sch_eagle_plugin.cpp | 4 ++-- eeschema/sch_marker.cpp| 2 +- eeschema/sch_sheet_path.h | 2 +- eeschema/toolbars_viewlib.cpp | 2 +- eeschema/tools/ee_inspection_tool.cpp | 2 +- eeschema/tools/ee_point_editor.cpp | 10 +- eeschema/tools/ee_selection.cpp| 2 +- eeschema/tools/ee_selection_tool.cpp | 2 +- eeschema/tools/lib_edit_tool.cpp | 2 +- eeschema/tools/sch_drawing_tools.cpp | 6 +++--- eeschema/tools/sch_edit_tool.cpp | 4 ++-- eeschema/tools/sch_editor_control.cpp | 2 +- gerbview/gerbview_frame.cpp| 2 +- gerbview/tools/gerbview_control.cpp| 2 +- gerbview/tools/gerbview_selection_tool.cpp | 2 +- include/gal/graphics_abstraction_layer.h | 4 ++-- include/gal/opengl/shader.h| 2 +- include/utf8.h | 6 +++--- pagelayout_editor/pl_editor.cpp| 2 +- pagelayout_editor/pl_editor_frame.cpp | 2 +- pagelayout_editor/tools/pl_edit_tool.cpp | 2 +- pagelayout_editor/tools/pl_editor_control.cpp | 2 +- pagelayout_editor/tools/pl_point_editor.cpp| 2 +- pagelayout_editor/tools/pl_selection_tool.cpp | 2 +- pcb_calculator/pcb_calculator.cpp | 2 +- .../class_board_stackup.cpp| 4 ++-- pcbnew/class_board.cpp | 4 +--- pcbnew/class_dimension.cpp | 2 +- pcbnew/class_drawsegment.cpp | 4 ++-- pcbnew/class_marker_pcb.cpp| 8 pcbnew/class_module.cpp| 4 ++-- pcbnew/class_module.h | 4 ++-- pcbnew/class_pcb_target.cpp| 2 +- pcbnew/class_pcb_text.cpp | 2 +- pcbnew/class_track.cpp | 4 ++-- pcbnew/class_zone.cpp | 2 +- pcbnew/connectivity/connectivity_algo.cpp | 8 +++- pcbnew/convert_drawsegment_list_to_polygon.cpp | 4 ++-- pcbnew/dialogs/dialog_create_array.cpp | 4 ++-- pcbnew/exporters/export_gencad.cpp | 4 +--- pcbnew/files.cpp | 2 +- pcbnew/footprint_info_impl.cpp | 2 +- pcbnew/legacy_plugin.cpp | 2 +- pcbnew/pad_print_functions.cpp | 2 +- pcbnew/pcb_base_frame.cpp | 10 +- pcbnew/pcb_draw_panel_gal.cpp | 2 +- pcbnew/pcb_view.cpp| 2 +- pcbnew/plot_board_layers.cpp
[Kicad-developers] [PATCH 0/2] Remove useless casts
Hi, I have two patches that remove useless casts. The first covers cases where it is quite obvious that the cast can be removed with no adverse effects, the second contains the cases where that is less clear. In theory, both can be applied and should not cause code changes, but the second needs review to see if something else was originally intended by that code. Simon Simon Richter (2): Remove useless casts Remove questionable useless casts 3d-viewer/3d_cache/sg/sg_helpers.h| 4 ++-- 3d-viewer/3d_canvas/create_layer_items.cpp| 10 - .../3d_model_viewer/c3d_model_viewer.cpp | 2 +- .../c3d_render_ogl_legacy.cpp | 2 +- .../3d_render_ogl_legacy/clayer_triangles.h | 4 ++-- .../accelerators/cbvh_pbrt.cpp| 2 +- .../c3d_render_createscene.cpp| 8 +++ .../c3d_render_raytracing.cpp | 4 ++-- .../shapes2D/citemlayercsg2d.cpp | 6 ++--- .../shapes2D/cpolygon2d.cpp | 2 +- .../shapes3D/clayeritem.cpp | 4 ++-- 3d-viewer/3d_rendering/cimage.cpp | 4 ++-- 3d-viewer/3d_rendering/cpostshader.h | 2 +- 3d-viewer/3d_rendering/trackball.cpp | 12 +- bitmap2component/bitmap2cmp_main.cpp | 2 +- common/base_struct.cpp| 2 +- common/bezier_curves.cpp | 4 ++-- common/board_printout.cpp | 2 +- common/draw_panel_gal.cpp | 4 ++-- common/gal/opengl/opengl_compositor.cpp | 6 ++--- common/gal/opengl/opengl_gal.cpp | 2 +- common/gal/opengl/shader.cpp | 4 ++-- common/lib_table_base.cpp | 2 +- common/tool/picker_tool.cpp | 2 +- common/utf8.cpp | 2 +- common/view/view.cpp | 4 ++-- common/widgets/footprint_preview_widget.cpp | 4 ++-- common/widgets/net_selector.cpp | 2 +- common/xnode.cpp | 4 ++-- cvpcb/cvpcb.cpp | 2 +- cvpcb/display_footprints_frame.cpp| 2 +- dxflib_qcad/dl_dxf.cpp| 2 +- eeschema/dialogs/dialog_erc.cpp | 2 +- eeschema/generate_alias_info.cpp | 2 +- eeschema/hierarch.cpp | 2 +- eeschema/libedit/toolbars_libedit.cpp | 2 +- .../netlist_exporter_pspice.cpp | 2 +- eeschema/sch_eagle_plugin.cpp | 4 ++-- eeschema/sch_marker.cpp | 2 +- eeschema/sch_sheet_path.h | 2 +- eeschema/toolbars_viewlib.cpp | 2 +- eeschema/tools/ee_inspection_tool.cpp | 2 +- eeschema/tools/ee_point_editor.cpp| 10 - eeschema/tools/ee_selection.cpp | 2 +- eeschema/tools/ee_selection_tool.cpp | 2 +- eeschema/tools/lib_edit_tool.cpp | 2 +- eeschema/tools/sch_drawing_tools.cpp | 6 ++--- eeschema/tools/sch_edit_tool.cpp | 4 ++-- eeschema/tools/sch_editor_control.cpp | 2 +- gerbview/gerbview_frame.cpp | 2 +- gerbview/tools/gerbview_control.cpp | 2 +- gerbview/tools/gerbview_selection_tool.cpp| 2 +- include/gal/graphics_abstraction_layer.h | 4 ++-- include/gal/opengl/shader.h | 2 +- include/utf8.h| 6 ++--- pagelayout_editor/pl_editor.cpp | 2 +- pagelayout_editor/pl_editor_frame.cpp | 2 +- pagelayout_editor/tools/pl_edit_tool.cpp | 2 +- pagelayout_editor/tools/pl_editor_control.cpp | 2 +- pagelayout_editor/tools/pl_point_editor.cpp | 2 +- pagelayout_editor/tools/pl_selection_tool.cpp | 2 +- pcb_calculator/pcb_calculator.cpp | 2 +- .../class_board_stackup.cpp | 4 ++-- pcbnew/class_board.cpp| 4 +--- pcbnew/class_dimension.cpp| 2 +- pcbnew/class_drawsegment.cpp | 4 ++-- pcbnew/class_marker_pcb.cpp | 8 +++ pcbnew/class_module.cpp | 4 ++-- pcbnew/class_module.h | 4 ++-- pcbnew/class_pcb_target.cpp | 2 +- pcbnew/class_pcb_text.cpp | 2 +- pcbnew/class_track.cpp| 4 ++-- pcbnew/class_zone.cpp | 2 +- pcbnew/connectivity/connectivity_algo.cpp | 8 +++ .../convert_drawsegment_list_to_polygon.cpp | 4 ++-- pcbnew/dialogs/dialog_create_array.cpp| 4 ++-- pcbnew/exporters/export_gencad.cpp| 4 +--- pcbnew/files.cpp | 2 +- pcbnew/footprint_info_impl.cpp| 2 +- pcbnew/legacy_plugin.cpp | 2 +- pcbnew/pad_print_functions.cpp
Re: [Kicad-developers] [RFC] Comments for a Layer Stack Manager in Pcbnew
Hi, > Are the binaries downloadable? I downloaded > kicad-patched-495-762dabd75-x86_64.exe from > https://kicad-downloads.s3.cern.ch/index.html?prefix=windows/testing/patched/ > but pcbnew crashes before it opens. The binaries on the download server and on the Jenkins host (found under "Artifacts") should be identical. The only thing that could explain a crash would be that I built with Python3 enabled. I'm trying again with Python2, that will be #497. Simon ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [RFC] Comments for a Layer Stack Manager in Pcbnew
Hi, > Please test and comment. > I want to commit this feature soon. Builds on msys2 and msvc are on the way: https://jenkins.simonrichter.eu/job/windows-kicad-msys2-patch/495/ https://jenkins.simonrichter.eu/job/windows-kicad-msvc-patch/142/ There should be binaries there for easier testing soon. Simon ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Kicad support for Linux on PPC
Hi, On Thu, Aug 29, 2019 at 04:27:56PM +0200, Gianluca Renzi wrote: > Cool! But my platform is ppc64be! :-( What hardware is that? I want one. Simon ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Linker Error (self made...)
Hi Ian, On Wed, Aug 28, 2019 at 04:36:03PM +0200, Ian McInerney wrote: > Just to be clear, I was only going to focus on cleaning up the static > linkage in the current build process. While items in common could be moved > into a new DLL, I don't have enough experience with that to try to attempt > it right now. The static linkage is required because the base units are different across programs. Any code that needs to convert between internal and real world length units links to a function that applies the conversion factor for the program being linked currently. The base class code is linked multiple times, once per kiface, and each copy is linked against the appropriate version of the conversion function for this kiface. The "common" library collects all code that is not directly sensitive to -DEESCHEMA, -DGERBVIEW or -DPCBNEW, but these functions are allowed to reference functions that are -- so there will be undefined symbols in that library that are filled in by the kiface. We can't delay resolving that to runtime because we have multiple different definitions for these symbols, which would conflict, and also Linux is the only platform that even allows shared libraries with undefined symbols. Simon ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Linker Error (self made...)
Hi, On Wed, Aug 28, 2019 at 10:47:52AM +0200, Ian McInerney wrote: > I think that the only way to really fix this is to split common up into > some smaller units, I had the same idea already. This works for some parts (for example I was able to split off dlist as an experiment), but the base_units stuff cannot be turned into a library right now. What might work would be defining the conversion factor in the Kiface instantiation code and pass it down through the *_FRAME hierarchy, but that would make all conversions require the frame as context (so it would break my plan for a gradual replacement). Once the unit code is merged, there isn't even a need to build separate DLLs anymore, we can just link everything together. Simon ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Patch: Fixing a compile error on Power PC
Hi, On Tue, Aug 27, 2019 at 05:14:47PM +0200, Tomasz Wlostowski wrote: > Does anybody here have a PPC machine to test this? Preferably one with > working OpenGL? I have half of one, missing a case though so it's not set up yet. With luck, I'll get to that next week, then I can also integrate it with Jenkins so we can get regular reports. Simon ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Linker Error (self made...)
Hi, On Tue, Aug 27, 2019 at 02:56:37AM +0200, Ian McInerney wrote: > I was trying to do a fresh build of master with the address sanitizer > enabled in Clang, and I am receiving a strange linker error, and was > curious if anyone else had any thoughts on it. I fixed a similar error on MSVC once. MSVC encodes the return type in the mangled symbol, while gcc does not, and the build fell over on MSVC because we had two different declarations for Pgm(), one returning a reference to PGM_BASE, the other returning a reference to a compatible type (so this wasn't a runtime problem). My suspicion is that something similar is going on here. This could be something stupid even like a mismatch in compiler flags (which are a mix of CMAKE_CXX_FLAGS, CMAKE_SHARED_LINKER_FLAGS, CMAKE_MODULE_LINKER_FLAGS and CMAKE_EXE_LINKER_FLAGS). Compiling with -flto on gcc gives a few warnings[1] about different types being used in the 3D viewer, usually related to GLM vector types (so presumably different translation units use different preprocessor macros when including GLM), but nothing Kiface related (this wouldn't catch any mismatch in modules that are not linked together though). Simon [1] https://jenkins.simonrichter.eu/job/linux-kicad-head-lto/lastStableBuild/gcc/ ___ 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] Fix some memory leaks
Hi, On Tue, Aug 13, 2019 at 05:43:02PM +0200, Ian McInerney wrote: > Smart pointers would definitely have been nicer to use, but the issue we > have with the board objects is they are passed out through SWIG to Python > currently, and SWIG doesn't seem to support unique_ptr, so I am not sure > how it would react if we gave it a deque of unique_ptrs. Anyone know if > that would break anything? That would break horribly, indeed. It would probably make sense to have a higher-level interface for scripting, and SWIG that instead of exposing the internals, breaking all the scripts everytime we improve something. :/ Simon ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [Patch] Fix some memory leaks
Hi, On Tue, Aug 13, 2019 at 10:50:10AM -0400, Wayne Stambaugh wrote: > Maybe we should have used boost::ptr_deque instead. You get heap > allocation cleanup for free. Or a deque of smart pointers. Without range-based for, that was annoying to use because you needed the double dereference for(std::deque >::const_iterator i = objects.begin; i != object.end(); ++i) (*i)->function(); which was the main reason boost::ptr_container exists. Today, we can just for(auto const : objects) p->function(); which is not perfect, but probably good enough. I'm not entirely convinced we need lists of polymorphic objects that much. The construct where VIA is a subclass of TRACK (which is also used directly) could possibly be changed into abstract TRACK as a base, TRACE and VIA as (final) most derived classes, and objects stored in deque and deque without fear of slicing. That should cut down on the number of allocations required, and also allow introducing a pool allocator into the deque type as a further optimization. Simon ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Possible MSW-only fix for print bug
Hi Jeff, On Fri, Aug 09, 2019 at 11:36:44AM +0100, Jeff Young wrote: > I’ve merged a possible fix for https://bugs.launchpad.net/kicad/+bug/1464773, > but it will only work on MSW until wxWidgets 3.1.1. Of course that means I > can’t test it. Nightlies are built against 3.1 these days. Simon ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Coding style question
Hi Tom, > - always use std::shared_ptr explicitly? I'd vote for explicit smart pointers in function signatures and member definitions, and "auto" in places where it can be deduced. MSVC's /ANALYZE also has some helpful diagnostics like C26418[1] "Shared pointer parameter X is not copied or moved. Use T* or T& instead." to find instances where smart pointers wouldn't be needed. Simon [1] https://jenkins.simonrichter.eu/job/windows-kicad-msvc-analyze-head/build=release,cpu=amd64,label=msvc/70/msbuild/category.1965989428/#issuesContent ___ 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] Fix initialization order for COLOR4D statics
Hi, On Mon, Aug 05, 2019 at 10:58:44AM +0200, Ian McInerney wrote: > I tracked it down to the fact that COLOR4D has some static colors that were > being used to initialize some other static variables in pcbnew's layer > widgets. I have moved all the static colors to an initialize on first use > paradigm (so now we just call them like a function, e.g. > COLOR4D::UNSPECIFIED() ) to fix it. Can that be solved by constexpr? Simon ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Preferred way to contribute
Hi, On Thu, Jul 25, 2019 at 09:52:21AM +0300, Alexander Shuklin wrote: > Is submitting patches through developers mailing list is preferred way to > contribute? Or better to submit merge requests through launchpad in some > cases (big commit, or something else)? The mailing list seems to be preferred, because that gives the best chances of something resembling a code review, but for big commits that change little (e.g. reformatting, moving code, ...) or multi-author branches it is often better to use a merge request. Simon ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] RFC: KiCad windows installer proposal
Hi, On Wed, Jul 24, 2019 at 08:13:43AM -0400, Wayne Stambaugh wrote: > AFAICT this has not been tested using nightly builds to ensure there are > no issues before we put it into production. The -patch installers are built without the library, and have been tested to install fine on top of stable or nightly, leaving the library alone. I can see that nightly users mostly want to stay somewhat up to date (there is usually a forum thread in which users discuss which nightly is the best) with the software, and install a new version of the library either as a side effect of a nightly, or because the new version has something they need. In the long run, it might make sense to decouple the library from the main program and have it release independently. This will make it more difficult to build a single package that contains everything, but my feeling is that this is closer to what users need. Simon ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] RFC: KiCad windows installer proposal
Hi, On Wed, Jul 24, 2019 at 02:04:15AM -0700, Andrew Lutsenko wrote: > I agree, if my proposal won't be accepted as is then whatever changes I > will make should be properly tested and won't be rushed for 5.1.3. But if > no changes will be required then all the hard work is done already. Just > need to merge the PR, run the build and upload both executables. I'm largely in favour, because I don't see myself getting around to replacing the entire installer with something sensible soon. The long term plan is to build an MSI based installer, because that leaves the option of either embedding the cabinet files into the MSI or leaving them external, and allows building binary patch installers that can upgrade existing installations in-place. Simon ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] Adapt CMake 3.0 compatibility code for C++14
Hi, On Wed, Jul 17, 2019 at 01:24:26PM -0400, Seth Hillbrand wrote: > Any reason to be using the gnu++14 extensions? I thought we were > trying to stay with the vanilla c++14. I went for consistency. This code is pretty much unused anyway, since it only handles the very old CMake versions that don't know the properties -- that's why there is a version check in front that causes a fatal error if someone bumps the minimum CMake version without removing the compatibility code. We currently have the respective compiler extensions enabled (both GNU and Visual Studio), because we don't have set( CMAKE_CXX_EXTENSIONS OFF ) The problem is that doing that breaks msys2 builds with wx 3.0, because gcc provides a POSIX-compliant strlen implementation as an extension that becomes unavailable in standards-compliant mode. A wx header decides to redirect missing functions to replacements in the DLL, but building the DLL with extensions enabled means that the function is missing -- so builds with -std=c++14 fail to link with a missing symbol. I dimly remember that this is fixed in wx 3.1 (just provide the CRT functions unconditionally), but I can't find the bug report anymore. Simon ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] [PATCH] Adapt CMake 3.0 compatibility code for C++14
---
CMakeLists.txt | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 85b029786..cb41e0c15 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -201,12 +201,12 @@ endif()
if( CMAKE_VERSION VERSION_LESS 3.1 AND ( CMAKE_COMPILER_IS_GNUCXX OR CMAKE_CXX_COMPILER_ID MATCHES "Clang" ) )
include(CheckCXXCompilerFlag)
-CHECK_CXX_COMPILER_FLAG("-std=c++11" COMPILER_SUPPORTS_CXX11)
+CHECK_CXX_COMPILER_FLAG("-std=gnu++14" COMPILER_SUPPORTS_CXX14)
-if(COMPILER_SUPPORTS_CXX11)
-set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
+if(COMPILER_SUPPORTS_CXX14)
+set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=gnu++14")
else()
-message(STATUS "The compiler ${CMAKE_CXX_COMPILER} has no C++11 support. Please use a different C++ compiler.")
+message(STATUS "The compiler ${CMAKE_CXX_COMPILER} has no C++14 support. Please use a different C++ compiler.")
endif()
endif()
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH v2 0/8] MSVC Build
Hi Wayne, On Tue, Jul 16, 2019 at 06:24:30PM -0400, Wayne Stambaugh wrote: > I'm ready to push this patch set. I'm assuming this is the same changes > as the merge request. If not please let me know. The merge request is better: - two small fixes for things that happened while rebasing - MSVC needs "/utf-8", not "/UTF-8", the latter would be an #undef - an unused CMake variable got readded - keeps the attribution for Tom's commits. I've done a rebased branch for 5.1 as well, but will test it first before I submit that. Since I have a proper day job now, that will be some time. Simon ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Build errors on linux
Hi, On Tue, Jul 16, 2019 at 03:24:14PM +0100, Jeff Young wrote: > I assume gcc 6 is still new enough to support C++14? It didn't complain about -std=g++14, so the answer is a resounding "maybe". Simon ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Build errors on linux
Hi Jeff, On Tue, Jul 16, 2019 at 03:13:43PM +0100, Jeff Young wrote: > Wow. I thought gcc was a “real” compiler. ;) To be fair, that is gcc 6 only, which is in Debian oldstable (so we need to support it for a year or so still). gcc 7 doesn't have that problem. Simon ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] [PATCH] Work around a bug in gcc 6.3 capturing constexpr by reference
This causes an error
lvalue required as unary '&' operand
when compiling with ancient gcc. Declaring it static in addition to
constexpr works around the problem.
---
eeschema/tools/sch_editor_control.cpp | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eeschema/tools/sch_editor_control.cpp b/eeschema/tools/sch_editor_control.cpp
index c6eb4e0fc..cfea237eb 100644
--- a/eeschema/tools/sch_editor_control.cpp
+++ b/eeschema/tools/sch_editor_control.cpp
@@ -439,7 +439,7 @@ void SCH_EDITOR_CONTROL::doCrossProbeSchToPcb( const TOOL_EVENT& aEvent, bool aF
#ifdef KICAD_SPICE
int SCH_EDITOR_CONTROL::SimProbe( const TOOL_EVENT& aEvent )
{
-constexpr KICAD_T wiresAndComponents[] = { SCH_LINE_T, SCH_COMPONENT_T, SCH_SHEET_PIN_T, EOT };
+constexpr static KICAD_T wiresAndComponents[] = { SCH_LINE_T, SCH_COMPONENT_T, SCH_SHEET_PIN_T, EOT };
SIM_PLOT_FRAME* simFrame = (SIM_PLOT_FRAME*) m_frame->Kiway().Player( FRAME_SIMULATOR, false );
std::string tool = aEvent.GetCommandStr().get();
@@ -481,7 +481,7 @@ int SCH_EDITOR_CONTROL::SimProbe( const TOOL_EVENT& aEvent )
int SCH_EDITOR_CONTROL::SimTune( const TOOL_EVENT& aEvent )
{
-constexpr KICAD_T fieldsAndComponents[] = { SCH_COMPONENT_T, SCH_FIELD_T, EOT };
+constexpr static KICAD_T fieldsAndComponents[] = { SCH_COMPONENT_T, SCH_FIELD_T, EOT };
std::string tool = aEvent.GetCommandStr().get();
SIM_PLOT_FRAME* simFrame = (SIM_PLOT_FRAME*) m_frame->Kiway().Player( FRAME_SIMULATOR, false );
___
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] Failing test: common.holeyPolySet.Collide( VECTOR2I( 11, 11 ), 5 )
Hi, we have a failing test, consistent on all tested platforms: [Error] - check common.holeyPolySet.Collide( VECTOR2I( 11, 11 ), 5 ) has failed == [File] - /var/lib/jenkins/workspace/linux-kicad-head/src/qa/common/geometry/test_shape_poly_set_collision.cpp == [Line] - 160 The first build[1] this appeared on has the following changes: Cleanup and commenting. Allow thermal spokes to be same width as minimum width. Add preference for flip axis. Fix a bug in tool activation/deactivation and another illegal Update position before first mouse-move-event. Improve performance, commenting and API of some polygon classes. Simon [1] https://jenkins.simonrichter.eu/job/linux-kicad-head/3325/ ___ 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 v2 0/8] MSVC Build
Hi Wayne, > I have to apply the patches, build, and test. I should be able to get > to it over the weekend. My only comment is on patch #1. I would have > preferred that we implemented the missing boost pointer container object > clone methods rather the work around. As a temporary fix I could live > with this but it just feels wrong to me. I'm not even sure it is wrong -- if I understood the problem correctly, we'd do a deep clone of a container containing objects, and then throw away the original, so we could just return the original instead. > Everything else seems pretty > straight forward. I definitely want to get some testing due to the > changes to make sure nothing is broken before we cherry pick this to the > 5.1 branch. I haven't tested this on 5.1 yet, because I was expecting this to go into master only. Simon ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] [PATCH] Remove GLM version check (no longer needed with C++14)
---
CMakeLists.txt | 4
1 file changed, 4 deletions(-)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 77912e9e9..27d319c05 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -565,10 +565,6 @@ endif()
# Find GLM library, required
#
find_package( GLM 0.9.5.1 REQUIRED )
-if( GLM_VERSION MATCHES "0.9.9.3" AND CMAKE_CXX_COMPILER_ID MATCHES "GNU")
-MESSAGE( FATAL_ERROR "\nGLM version ${GLM_VERSION} is incompatible with KiCad using GCC.\n"
- "Please downgrade to GLM version 0.9.9.2 or older or use clang instead" )
-endif()
add_definitions( -DGLM_FORCE_CTOR_INIT )
___
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] wxWidgets Event Tables or Bind and lambdas
Hi,
> I prefer the way Simon has it formatted, since the lambda follows the
> general function formatting guidelines. I am indifferent to the grouping of
> arguments around it though, and the clang-format script would seem to
> prefer doing it this way:
> function( arg1, arg2, arg3, arg4, arg5,
> arg6, arg7 );
Yes, that's why I mentioned the "argument grouping" aspect: manually
inserted newlines should be kept, even if more tokens would fit the line.
One of the patches in my stack (remove superfluous casts) has
@@ -5268,11 +5268,13 @@ void ClipperOffset::DoOffset( double delta )
if( node.m_endtype == etOpenButt )
{
int j = len - 1;
-pt1 = IntPoint( (cInt) Round( m_srcPoly[j].X + m_normals[j].X *
-delta ), (cInt) Round( m_srcPoly[j].Y +
m_normals[j].Y * delta ) );
+pt1 = IntPoint(
+Round( m_srcPoly[j].X + m_normals[j].X * delta ),
+Round( m_srcPoly[j].Y + m_normals[j].Y * delta ) );
It's fairly obvious that the old state was done by an automatic tool, and
is pretty much the worst possible state.
Simon
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] wxWidgets Event Tables or Bind and lambdas
Hi,
My layout would be
m_footprintListBox->Bind( wxEVT_RIGHT_DOWN,
[this]( wxMouseEvent& )
{
this->PopupMenu( this->m_footprintContextMenu );
} );
Rationale:
- it follows the "indent twice for round parentheses" rule
- the lambda begins on the first character in the line
- it keeps the lambda on the same indentation level
- it leaves enough space for the lambda without too many extra breaks
- the closing parenthesis follows the last argument on the same line
The "wxEVT_RIGHT_DOWN" would technically be on the same level as the lambda, so
m_footprintListBox->Bind(
wxEVT_RIGHT_DOWN,
[this]( wxMouseEvent& )
{
this->PopupMenu( this->m_footprintContextMenu );
} );
would be equivalent. We have both
function( arg1, arg2, arg3, arg4, arg5,
arg6, arg7 );
and
function(
arg1,
arg2,
arg3,
arg4,
arg5,
arg6,
arg7 );
in the codebase, as well as several instances where some arguments are
grouped tighter than others, e.g.
function( something.x, something.y,
something.w, something.h );
instead of
function( something.x, something.y, something.w,
something.h );
I think the usual rule applies: the compiler doesn't care, so the highest
priority is that it should be human readable.
Simon
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] wxWidgets Event Tables or Bind and lambdas
Hi, On Fri, Jul 12, 2019 at 11:11:21AM +0200, Ian McInerney wrote: > Other windows seem to use the Bind method with lambda functions for these > small functions, and I have used them as well for some new bindings for the > actionization when needed. My main question is, is it acceptable to also > transition existing events (unaffected by the action changes) to use this > paradigm? Which registration method is used is completely internal to the class that handles the events -- the same file contains both the registration and the handlers. IMO, it should be consistent within one file (i.e. if there is a table, it should be complete and not be augmented with additional runtime bindings), but beyond that it doesn't really matter. wxWidgets 3.0 generates a few warnings about initialization order of static objects on MSVC when we're using tables, but these seem to be both harmless and fixed with wxWidgets 3.1. Simon ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Strange program version numbering in KiCad
Hi, On Tue, Jul 09, 2019 at 09:26:11AM -0400, Steven A. Falco wrote: > I'd vote for the .99 approach, assuming I get a vote. :-) The main difficulty is the way the version number generation is implemented. We use "git describe" to get the name of the last tag, then add the number of commits and the commit ID. So, if we wanted to have .99 in the version number somewhere, there'd have to be a tag "5.99" on some intermediate version. I guess I could special-case that in the delivery pipeline so that it doesn't get uploaded as a stable release, but I still think it is a bit confusing to have a tag on something that is not a release. Simon ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH v2 0/8] MSVC Build
Hi, On Fri, Jul 05, 2019 at 06:24:45PM +0200, Tomasz Wlostowski wrote: > > I can't test the Windows functionality but this doesn't appear to break > > anything on Linux. > I'm ok with Simon's patches. Can give them a try on MSVC, but I'm pretty > confident they will work already. These are tested on Linux (with "git rebase -x make", so individual commits compile on their own) and Windows with MSYS2 and MSVC through Jenkins. I can't test MacOS. > @Simon: Now that we'll be supporting MSVC, should we put a 'MSVC > precompiled library kit' somewhere on Kicad webpage to spare people the > hassle of finding the right version on Jenkins? Yes, can do. I'm going to investigate vcpkg as well, since it has cmake integration, so it reduces to "tell vcpkg that we need these packages, and tell cmake to talk to vcpkg". My initial experiments were promising, it seems to be missing oce and ngspice, and I'm unsure about the status of wxpython, but everything else seems to be there. Simon ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] [PATCH v2 3/8] Set _USE_MATH_DEFINES on Windows
All compilers need this in standards-compliant mode. --- CMakeLists.txt | 4 1 file changed, 4 insertions(+) diff --git a/CMakeLists.txt b/CMakeLists.txt index ee43d9eb98..c73c86a291 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -245,6 +245,10 @@ if( WIN32 ) # define UNICODE and_UNICODE definition on Windows. KiCad uses unicode. # Both definitions are required add_definitions(-DUNICODE -D_UNICODE) + +# In fully standards-compliant mode, M_PI et al. are defined only if +# _USE_MATH_DEFINES is set. +add_definitions( -D_USE_MATH_DEFINES ) endif() ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] [PATCH v2 8/8] Define compiler flags for MSVC
Defines:
- inhibit generation of #pragma comment(lib, ...) from boost
- inhibit warnings about "unsafe" containers
- inhibit warnings about "unsafe" C functions
- inhibit warnings about "deprecated" POSIX functions
- suppress min/max macros from windows.h
Flags:
- source and execution charsets are UTF-8
- suppress warnings about throw() not being fully supported in the compiler
- suppress warnings about values being explicitly cast to bool
- enable string pooling
- enable unreferenced code removal
- enable COMDAT folding
- generate PDB debug information
---
CMakeLists.txt | 40
1 file changed, 40 insertions(+)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index c73c86a291..c64d752c2e 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -108,6 +108,10 @@ option( KICAD_SPICE
"Build KiCad with internal Spice simulator."
ON )
+option( KICAD_BUILD_PARALLEL_CL_MP
+"Build in parallel using the /MP compiler option (default OFF for safety reasons)"
+OFF )
+
# when option KICAD_SCRIPTING OR KICAD_SCRIPTING_MODULES is enabled:
# PYTHON_EXECUTABLE can be defined when invoking cmake
# ( use -DPYTHON_EXECUTABLE=/python.exe or python2 )
@@ -361,6 +365,42 @@ if( CMAKE_COMPILER_IS_GNUCXX OR CMAKE_CXX_COMPILER_ID MATCHES "Clang" )
endif( CMAKE_COMPILER_IS_GNUCXX OR CMAKE_CXX_COMPILER_ID MATCHES "Clang" )
+if( MSVC )
+# Disallow implicit linking for Boost
+add_definitions( -DBOOST_ALL_NO_LIB )
+# Disable MSVC's deprecation warnings
+add_definitions( -D_CRT_SECURE_NO_WARNINGS -D_CRT_NONSTDC_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS )
+# Hide Windows's min() and max() macros
+add_definitions( -DNOMINMAX )
+# source and execution charset are UTF-8
+string( APPEND CMAKE_CXX_FLAGS " /UTF-8" )
+# C4290: throw() is interpreted as declspec(nothrow)
+string( APPEND CMAKE_CXX_FLAGS " /wd4290" )
+# C4800: non-bool is explicitly cast to bool, forcing value of 0 or 1
+string( APPEND CMAKE_CXX_FLAGS " /wd4800" )
+# /Zi: create PDB
+string( APPEND CMAKE_CXX_FLAGS " /Zi" )
+# /GF: enable string pooling
+string( APPEND CMAKE_CXX_FLAGS_RELEASE " /GF" )
+foreach( type EXE SHARED MODULE)
+# /DEBUG: create PDB
+string( APPEND CMAKE_${type}_LINKER_FLAGS " /DEBUG" )
+# /OPT:REF: omit unreferenced code
+string( APPEND CMAKE_${type}_LINKER_FLAGS_RELEASE " /OPT:REF" )
+# /OPT:ICF: fold common data
+string( APPEND CMAKE_${type}_LINKER_FLAGS_RELEASE " /OPT:ICF" )
+endforeach()
+
+# Let cl.exe parallelize builds
+if( KICAD_BUILD_PARALLEL_CL_MP )
+string( APPEND CMAKE_CXX_FLAGS " /MP" )
+endif()
+endif()
+
+if( USE_WX_OVERLAY OR APPLE )
+add_definitions( -DUSE_WX_OVERLAY )
+endif()
+
if( KICAD_SCRIPTING )
add_definitions( -DKICAD_SCRIPTING )
endif()
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
[Kicad-developers] [PATCH v2 1/8] pcbnew: can't return a copy of ptr_vector if items are polymorphic and have no clone() methods. Work it around.
---
pcbnew/pcb_edit_frame.h | 3 ++-
pcbnew/pcbnew_config.cpp | 12 ++--
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/pcbnew/pcb_edit_frame.h b/pcbnew/pcb_edit_frame.h
index 705f5f7f4c..dadb6cba0e 100644
--- a/pcbnew/pcb_edit_frame.h
+++ b/pcbnew/pcb_edit_frame.h
@@ -93,6 +93,7 @@ protected:
PCB_LAYER_WIDGET* m_Layers;
PARAM_CFG_ARRAY m_configParams; ///< List of Pcbnew configuration settings.
+PARAM_CFG_ARRAY m_projectFileParams;
wxString m_lastNetListRead;///< Last net list read with relative path.
@@ -379,7 +380,7 @@ public:
* @return PARAM_CFG_ARRAY - it is only good until SetBoard() is called, so
* don't keep it around past that event.
*/
-PARAM_CFG_ARRAY GetProjectFileParameters();
+PARAM_CFG_ARRAY& GetProjectFileParameters();
/**
* Function SaveProjectSettings
diff --git a/pcbnew/pcbnew_config.cpp b/pcbnew/pcbnew_config.cpp
index ff1cb57420..8b577538ef 100644
--- a/pcbnew/pcbnew_config.cpp
+++ b/pcbnew/pcbnew_config.cpp
@@ -125,21 +125,21 @@ void PCB_EDIT_FRAME::SaveProjectSettings( bool aAskForSave )
}
-PARAM_CFG_ARRAY PCB_EDIT_FRAME::GetProjectFileParameters()
+PARAM_CFG_ARRAY& PCB_EDIT_FRAME::GetProjectFileParameters()
{
-PARAM_CFG_ARRAY pca;
+m_projectFileParams.clear();
// This one cannot be cached because some settings are going to/from the BOARD,
// so pointers into that cannot be saved for long.
-pca.push_back( new PARAM_CFG_FILENAME( wxT( "PageLayoutDescrFile" ),
+m_projectFileParams.push_back( new PARAM_CFG_FILENAME( wxT( "PageLayoutDescrFile" ),
_SCREEN::m_PageLayoutDescrFileName ) );
-pca.push_back( new PARAM_CFG_FILENAME( wxT( "LastNetListRead" ), _lastNetListRead ) );
+m_projectFileParams.push_back( new PARAM_CFG_FILENAME( wxT( "LastNetListRead" ), _lastNetListRead ) );
-GetBoard()->GetDesignSettings().AppendConfigs( GetBoard(), );
+GetBoard()->GetDesignSettings().AppendConfigs( GetBoard(), _projectFileParams);
-return pca;
+return m_projectFileParams;
}
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
[Kicad-developers] [PATCH v2 6/8] MSVC support for libcontext
This uses the Windows native Fiber API.
---
common/system/libcontext.cpp | 66
include/system/libcontext.h | 16 ++-
include/tool/coroutine.h | 8 --
3 files changed, 87 insertions(+), 3 deletions(-)
diff --git a/common/system/libcontext.cpp b/common/system/libcontext.cpp
index f6f83ceaef..57478f12c2 100644
--- a/common/system/libcontext.cpp
+++ b/common/system/libcontext.cpp
@@ -13,6 +13,8 @@
http://www.boost.org/LICENSE_1_0.txt)
*/
+#include
+#include
#include
#if defined(LIBCONTEXT_PLATFORM_windows_i386) && defined(LIBCONTEXT_COMPILER_gcc)
@@ -1268,3 +1270,67 @@ __asm (
);
#endif
+
+#if defined(LIBCONTEXT_PLATFORM_msvc_x86_64) || defined(LIBCONTEXT_PLATFORM_msvc_i386)
+
+#include
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include
+
+namespace libcontext
+{
+
+static int threadHasFibers = 0;
+
+struct FiberData
+{
+ intptr_t inValue;
+ intptr_t outValue;
+ void(*entry)(intptr_t);
+};
+
+static std::map fiberParams;
+
+static void fiberEntry(LPVOID params)
+{
+ auto ctx = (fcontext_t) GetCurrentFiber();
+ auto& d = fiberParams[ctx];
+ d.entry(d.inValue);
+}
+
+fcontext_t LIBCONTEXT_CALL_CONVENTION make_fcontext(void* sp, size_t size, void(*fn)(intptr_t))
+{
+ if (!threadHasFibers)
+ {
+ ConvertThreadToFiber(nullptr);
+ threadHasFibers = 1;
+ }
+
+ fcontext_t ctx = CreateFiber(size, (LPFIBER_START_ROUTINE) fiberEntry, nullptr );
+ fiberParams[ctx].entry = fn;
+
+ return ctx;
+}
+
+intptr_t LIBCONTEXT_CALL_CONVENTION jump_fcontext(fcontext_t* ofc, fcontext_t nfc,
+ intptr_t vp, bool preserve_fpu)
+{
+ auto current = (void*)GetCurrentFiber();
+ fiberParams[current].outValue = vp;
+ *ofc = GetCurrentFiber();
+ fiberParams[nfc].inValue = vp;
+ SwitchToFiber(nfc);
+ return fiberParams[*ofc].outValue;
+}
+
+}; // namespace libcontext
+
+#ifdef __cplusplus
+};
+#endif
+
+#endif
diff --git a/include/system/libcontext.h b/include/system/libcontext.h
index 8045fa2b78..dfa323dcd3 100644
--- a/include/system/libcontext.h
+++ b/include/system/libcontext.h
@@ -24,6 +24,8 @@
#if defined(__GNUC__) || defined(__APPLE__) || defined(__FreeBSD__)
+#undef LIBCONTEXT_HAS_OWN_STACK
+
#define LIBCONTEXT_COMPILER_gcc
#if defined(__linux__) || defined(__FreeBSD__)
@@ -46,7 +48,8 @@
#ifdef _ARCH_PPC64
#define LIBCONTEXT_PLATFORM_linux_ppc64
#define LIBCONTEXT_CALL_CONVENTION
-#elif defined _ARCH_PPC
+#endif
+#ifdef _ARCH_PPC
#define LIBCONTEXT_PLATFORM_linux_ppc32
#define LIBCONTEXT_CALL_CONVENTION
#endif
@@ -73,6 +76,17 @@
#define LIBCONTEXT_CALL_CONVENTION
#endif
#endif
+#elif defined (_MSC_VER)
+
+#define LIBCONTEXT_HAS_OWN_STACK
+
+#define LIBCONTEXT_CALL_CONVENTION __cdecl
+
+#if defined(_WIN64)
+ #define LIBCONTEXT_PLATFORM_msvc_x86_64
+#elif defined(_WIN32)
+ #define LIBCONTEXT_PLATFORM_msvc_i386
+#endif
#endif
#ifdef __cplusplus
diff --git a/include/tool/coroutine.h b/include/tool/coroutine.h
index 7be173adb1..60144ebc0b 100644
--- a/include/tool/coroutine.h
+++ b/include/tool/coroutine.h
@@ -294,15 +294,19 @@ private:
assert( m_stack == nullptr );
-// fixme: Clean up stack stuff. Add a guard
size_t stackSize = c_defaultStackSize;
+void* sp = nullptr;
+
+#ifndef LIBCONTEXT_HAS_OWN_STACK
+// fixme: Clean up stack stuff. Add a guard
m_stack.reset( new char[stackSize] );
// align to 16 bytes
-void* sp = (void*)ptrdiff_t) m_stack.get()) + stackSize - 0xf) & (~0x0f));
+sp = (void*)ptrdiff_t) m_stack.get()) + stackSize - 0xf) & (~0x0f));
// correct the stack size
stackSize -= size_t( ( (ptrdiff_t) m_stack.get() + stackSize ) - (ptrdiff_t) sp );
+#endif
m_callee = libcontext::make_fcontext( sp, stackSize, callerStub );
m_running = true;
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
[Kicad-developers] [PATCH v2 5/8] Work around missing min/max in Windows headers
Windows headers assume min/max to be macros, but we set NOMINMAX to hide the macro definitions. This pulls in an alternative implementation. --- common/gal/cairo/cairo_print.cpp | 6 ++ 1 file changed, 6 insertions(+) diff --git a/common/gal/cairo/cairo_print.cpp b/common/gal/cairo/cairo_print.cpp index 0204c69701..6cef33e9bd 100644 --- a/common/gal/cairo/cairo_print.cpp +++ b/common/gal/cairo/cairo_print.cpp @@ -25,6 +25,12 @@ #include #include +#ifdef NOMINMAX /* workaround for gdiplus.h */ +#include +using std::min; +using std::max; +#endif + #ifdef __WXMSW__ #include #include ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] [PATCH v2 4/8] Remove own copy of FindOpenSSL.cmake
---
CMakeModules/FindOpenSSL.cmake | 342 -
1 file changed, 342 deletions(-)
delete mode 100644 CMakeModules/FindOpenSSL.cmake
diff --git a/CMakeModules/FindOpenSSL.cmake b/CMakeModules/FindOpenSSL.cmake
deleted file mode 100644
index de91787c18..00
--- a/CMakeModules/FindOpenSSL.cmake
+++ /dev/null
@@ -1,342 +0,0 @@
-#.rst:
-# FindOpenSSL
-# ---
-#
-# Try to find the OpenSSL encryption library
-#
-# Once done this will define
-#
-# ::
-#
-# OPENSSL_ROOT_DIR - Set this variable to the root installation of OpenSSL
-#
-#
-#
-# Read-Only variables:
-#
-# ::
-#
-# OPENSSL_FOUND - system has the OpenSSL library
-# OPENSSL_INCLUDE_DIR - the OpenSSL include directory
-# OPENSSL_LIBRARIES - The libraries needed to use OpenSSL
-# OPENSSL_VERSION - This is set to $major.$minor.$revision$path (eg. 0.9.8s)
-
-#=
-# Copyright 2006-2009 Kitware, Inc.
-# Copyright 2006 Alexander Neundorf
-# Copyright 2009-2011 Mathieu Malaterre
-#
-# Distributed under the OSI-approved BSD License (the "License");
-# see accompanying file Copyright.txt for details.
-#
-# This software is distributed WITHOUT ANY WARRANTY; without even the
-# implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
-# See the License for more information.
-#=
-# (To distribute this file outside of CMake, substitute the full
-# License text for the above reference.)
-
-if (UNIX)
- find_package(PkgConfig QUIET)
- pkg_check_modules(_OPENSSL QUIET openssl)
-endif ()
-
-if (WIN32)
- # http://www.slproweb.com/products/Win32OpenSSL.html
- set(_OPENSSL_ROOT_HINTS
-${OPENSSL_ROOT_DIR}
-"[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\OpenSSL (32-bit)_is1;Inno Setup: App Path]"
-"[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\OpenSSL (64-bit)_is1;Inno Setup: App Path]"
-ENV OPENSSL_ROOT_DIR
-)
- file(TO_CMAKE_PATH "$ENV{PROGRAMFILES}" _programfiles)
- set(_OPENSSL_ROOT_PATHS
-"${_programfiles}/OpenSSL"
-"${_programfiles}/OpenSSL-Win32"
-"${_programfiles}/OpenSSL-Win64"
-"C:/OpenSSL/"
-"C:/OpenSSL-Win32/"
-"C:/OpenSSL-Win64/"
-)
- unset(_programfiles)
-else ()
- set(_OPENSSL_ROOT_HINTS
-${OPENSSL_ROOT_DIR}
-ENV OPENSSL_ROOT_DIR
-)
-endif ()
-
-set(_OPENSSL_ROOT_HINTS_AND_PATHS
-HINTS ${_OPENSSL_ROOT_HINTS}
-PATHS ${_OPENSSL_ROOT_PATHS}
-)
-
-find_path(OPENSSL_INCLUDE_DIR
- NAMES
-openssl/ssl.h
-${_OPENSSL_ROOT_HINTS_AND_PATHS}
- HINTS
-${_OPENSSL_INCLUDEDIR}
- PATH_SUFFIXES
-include
-)
-
-if(WIN32 AND NOT CYGWIN)
- if(MSVC)
-# /MD and /MDd are the standard values - if someone wants to use
-# others, the libnames have to change here too
-# use also ssl and ssleay32 in debug as fallback for openssl < 0.9.8b
-# TODO: handle /MT and static lib
-# In Visual C++ naming convention each of these four kinds of Windows libraries has it's standard suffix:
-# * MD for dynamic-release
-# * MDd for dynamic-debug
-# * MT for static-release
-# * MTd for static-debug
-
-# Implementation details:
-# We are using the libraries located in the VC subdir instead of the parent directory eventhough :
-# libeay32MD.lib is identical to ../libeay32.lib, and
-# ssleay32MD.lib is identical to ../ssleay32.lib
-find_library(LIB_EAY_DEBUG
- NAMES
-libeay32MDd
-libeay32d
-${_OPENSSL_ROOT_HINTS_AND_PATHS}
- PATH_SUFFIXES
-"lib"
-"VC"
-"lib/VC"
-)
-
-find_library(LIB_EAY_RELEASE
- NAMES
-libeay32MD
-libeay32
-${_OPENSSL_ROOT_HINTS_AND_PATHS}
- PATH_SUFFIXES
-"lib"
-"VC"
-"lib/VC"
-)
-
-find_library(SSL_EAY_DEBUG
- NAMES
-ssleay32MDd
-ssleay32d
-${_OPENSSL_ROOT_HINTS_AND_PATHS}
- PATH_SUFFIXES
-"lib"
-"VC"
-"lib/VC"
-)
-
-find_library(SSL_EAY_RELEASE
- NAMES
-ssleay32MD
-ssleay32
-ssl
-${_OPENSSL_ROOT_HINTS_AND_PATHS}
- PATH_SUFFIXES
-"lib"
-"VC"
-"lib/VC"
-)
-
-set(LIB_EAY_LIBRARY_DEBUG "${LIB_EAY_DEBUG}")
-set(LIB_EAY_LIBRARY_RELEASE "${LIB_EAY_RELEASE}")
-set(SSL_EAY_LIBRARY_DEBUG "${SSL_EAY_DEBUG}")
-set(SSL_EAY_LIBRARY_RELEASE "${SSL_EAY_RELEASE}")
-
-include(${CMAKE_CURRENT_LIST_DIR}/SelectLibraryConfigurations.cmake)
-select_library_configurations(LIB_EAY)
-select_library_configurations(SSL_EAY)
-
-mark_as_advanced(LIB_EAY_LIBRARY_DEBUG LIB_EAY_LIBRARY_RELEASE
- SSL_EAY_LIBRARY_DEBUG SSL_EAY_LIBRARY_RELEASE)
-set( OPENSSL_LIBRARIES ${SSL_EAY_LIBRARY} ${LIB_EAY_LIBRARY} )
- elseif(MINGW)
-message( STATUS "Searching
[Kicad-developers] [PATCH v2 0/8] MSVC Build
Hi, another attempt at getting the MSVC patchset merged. :) The mails with the patches are for commenting, this branch should probably be merged from the "msvc" branch under https://git.launchpad.net/~sjr/kicad in order to preserve author/date information properly. Simon Simon Richter (5): Set _USE_MATH_DEFINES on Windows Remove own copy of FindOpenSSL.cmake Work around missing min/max in Windows headers Pull in macro definition for strncasecmp on MSVC Define compiler flags for MSVC Tomasz Wlostowski (3): pcbnew: can't return a copy of ptr_vector if items are polymorphic and have no clone() methods. Work it around. Export LIB_TREE_ITEM MSVC support for libcontext CMakeLists.txt | 44 + CMakeModules/FindOpenSSL.cmake | 342 --- common/gal/cairo/cairo_print.cpp | 6 + common/system/libcontext.cpp | 66 eeschema/sim/ngspice.cpp | 1 + include/lib_tree_item.h | 4 +- include/system/libcontext.h | 16 +- include/tool/coroutine.h | 8 +- pcbnew/pcb_edit_frame.h | 3 +- pcbnew/pcbnew_config.cpp | 12 +- 10 files changed, 148 insertions(+), 354 deletions(-) delete mode 100644 CMakeModules/FindOpenSSL.cmake -- 2.11.0 ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] [PATCH v2 7/8] Pull in macro definition for strncasecmp on MSVC
--- eeschema/sim/ngspice.cpp | 1 + 1 file changed, 1 insertion(+) diff --git a/eeschema/sim/ngspice.cpp b/eeschema/sim/ngspice.cpp index fa1d3e3a97..4b173ef7af 100644 --- a/eeschema/sim/ngspice.cpp +++ b/eeschema/sim/ngspice.cpp @@ -28,6 +28,7 @@ #include "ngspice.h" #include "spice_reporter.h" +#include #include // LOCALE_IO #include #include ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] [PATCH v2 2/8] Export LIB_TREE_ITEM
---
include/lib_tree_item.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/lib_tree_item.h b/include/lib_tree_item.h
index 5ad5ef4bd8..28f69b7c03 100644
--- a/include/lib_tree_item.h
+++ b/include/lib_tree_item.h
@@ -27,7 +27,7 @@
#include
#include
-
+#include
/**
* A mix-in to provide polymorphism between items stored in libraries (symbols, aliases
@@ -36,7 +36,7 @@
* It is used primarily to drive the component tree for library browsing and editing.
*/
-class LIB_TREE_ITEM
+class APIEXPORT LIB_TREE_ITEM
{
public:
virtual LIB_ID GetLibId() const = 0;
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
