---
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 5ad5ef4bd..28f69b7c0 100644
--- a/include/lib_tree_item.h
+++ b/include/lib_tree_item.h
@@ -27,7 +27,7 @@
#include
#include
-
+#include
Hi,
> The background is the GNU make is not intelligent about parallel
> builds and doesn't merge generated targets.
FWIW we have the same problem on MSBuild. The problem we have is that we
use the same generated file from two different projects, and CMake's
paradigm is that generated files
Hi,
this might fix the lexer problems. Please test extensively.
Simon
Simon Richter (1):
Fix build order for generated headers and sources
CMakeModules/Functions.cmake | 27
CMakeModules/TokenList2DsnLexer.cmake | 2 +-
common/CMakeLists.txt
This changes make_lexer() so that it no longer generates a custom target
but instead attaches the generated files to an existing one (so the first
argument now is the name of an existing library or executable, and it needs
to come after the add_library/add_executable call).
The generated source
Hi Wayne,
On Mon, Jul 01, 2019 at 09:22:15AM -0400, Wayne Stambaugh wrote:
> We already have a string comparison function that handles this. Take a
> look at StrNumCmp()[1] in common/string.cpp[2]. We use this function in
> many places for mixed text and number comparisons so I see no reason
Hi Seth,
On Mon, Jul 01, 2019 at 12:33:43PM -0400, Seth Hillbrand wrote:
> [ 38%] Building CXX object
> eeschema/CMakeFiles/eeschema_kiface_objects.dir/widgets/symbol_tree_pane.cpp.o
> /home/seth/code/kicad/kicad_bare/eeschema/dialogs/panel_sym_lib_table.cpp:29:10:
> fatal error:
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]
Hi Nick,
the main showstoppers are:
1. chroots
On the old Jenkins, we just built on the host system, which meant the
build environment was available instantly. The current system uses
chroots, which have to be unpacked every time. Presumably this could be
solved with Docker, where the unpacking
Hi,
since 5813164d1 "SHAPE_ARC: fixed polyline conversion bug introduced in
e312e2b286" we get test failures in the ArcToPolyline tests:
[Error] - check chain.CPoint( 0 ) == c.m_geom.m_start_point has failed
[[ 10 | 0 ] != [ -10 | 0 ]]Semicircle
== [File] -
---
eeschema/sch_pin.cpp | 1 +
1 file changed, 1 insertion(+)
diff --git a/eeschema/sch_pin.cpp b/eeschema/sch_pin.cpp
index 62e5d48c6f..0e9facd35d 100644
--- a/eeschema/sch_pin.cpp
+++ b/eeschema/sch_pin.cpp
@@ -50,6 +50,7 @@ SCH_PIN& SCH_PIN::operator=( const SCH_PIN& aPin )
m_libPin =
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
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:
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
Hi,
I've rebased[1] Tom's adaptation of my MSVC branch on top of current
master, seems to compile still[2], except for the usual dependency problems
with the generated lexers[3].
In this branch, we have an assembler based libcontext (taken over from
boost) that is in a later commit replaced by
Hi,
> What is the minimum version of MSVC required for building this?
I use 2017 Build Tools. It should probably work with 2012 and 2015 as well.
Simon
___
Mailing list: https://launchpad.net/~kicad-developers
Post to :
just
the initial test now.
Simon
commit 46697882c3c35b7cff13bf917d26a53f8f1b1544
Author: Simon Richter
Date: Mon Jul 1 17:02:40 2019 +0200
Fix build order for generated headers and sources
This changes make_lexer() so that it no longer generates a custom target
but instead
Hi,
On Tue, Jul 02, 2019 at 11:42:30AM -0400, Seth Hillbrand wrote:
> Instead of banging on this dependency, I could push option #2 from
> my previous e-mail. This was creating a separate target to rebuild
> the generated files and checking them into the source tree. Then we
> don't try to
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
>
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
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
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
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
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
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 :
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
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
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
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 +-
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 +-
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
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
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
>
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
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.
---
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 (
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
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
>
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
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
-
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
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
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
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
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
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
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
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
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
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
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
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?
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
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
---
CMakeModules/BoostTest.cmake | 204 +++
CMakeModules/BoostTestAddTests.cmake | 138 ++
qa/CMakeLists.txt| 1 +
qa/common/CMakeLists.txt | 6 +-
qa/eeschema/CMakeLists.txt | 2 +-
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
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
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
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
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
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
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
m
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
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
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
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
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
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:
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
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
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,
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
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
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
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
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
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
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
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 --
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
>
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:
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
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
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
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
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]
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
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
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
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:
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
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
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
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
>
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
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:
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
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
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
801 - 898 of 898 matches
Mail list logo