---
CMakeModules/FindwxWidgets.cmake | 1 -
1 file changed, 1 deletion(-)
diff --git a/CMakeModules/FindwxWidgets.cmake b/CMakeModules/FindwxWidgets.cmake
index 254621c..7f57d8a 100644
--- a/CMakeModules/FindwxWidgets.cmake
+++ b/CMakeModules/FindwxWidgets.cmake
@@ -897,7 +897,6 @@
---
CMakeModules/FindwxWidgets.cmake | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/CMakeModules/FindwxWidgets.cmake b/CMakeModules/FindwxWidgets.cmake
index 99c07b6..471996c 100644
--- a/CMakeModules/FindwxWidgets.cmake
+++ b/CMakeModules/FindwxWidgets.cmake
@@ -150,10
stack as internally
consistent patches again.
Simon
Simon Richter (3):
FindwxWidgets.cmake: drop a few dbg_msg invocations
FindwxWidgets.cmake: Add comment describing code block
FindwxWidgets.cmake: Treat CygWin as unix rather than undefined
CMakeModules/FindwxWidgets.cmake | 23
---
CMakeModules/FindwxWidgets.cmake | 1 +
1 file changed, 1 insertion(+)
diff --git a/CMakeModules/FindwxWidgets.cmake b/CMakeModules/FindwxWidgets.cmake
index 0d10c51..2206fbf 100644
--- a/CMakeModules/FindwxWidgets.cmake
+++ b/CMakeModules/FindwxWidgets.cmake
@@ -192,6 +192,7 @@ else()
---
CMakeModules/FindwxWidgets.cmake | 18 --
1 file changed, 18 deletions(-)
diff --git a/CMakeModules/FindwxWidgets.cmake b/CMakeModules/FindwxWidgets.cmake
index 55e057d..0d10c51 100644
--- a/CMakeModules/FindwxWidgets.cmake
+++ b/CMakeModules/FindwxWidgets.cmake
@@ -196,11
---
CMakeModules/FindwxWidgets.cmake | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/CMakeModules/FindwxWidgets.cmake b/CMakeModules/FindwxWidgets.cmake
index 2206fbf..14cfdc4 100644
--- a/CMakeModules/FindwxWidgets.cmake
+++ b/CMakeModules/FindwxWidgets.cmake
@@ -199,9
Hi,
> On the other hand I would think you still need bypass capacitors on each
> pin and therefore you still need to draw wires for those.
I usually place these on a separate sheet anyway.
For bypass caps, I'd like to have a way to map pins and capacitors to
each other, which would change the
Hi,
Am 09.02.2016 um 09:32 schrieb Jean-Samuel Reynaud:
> As suggested by Wayne, is there any objection if version on daily build
> PPA become 5.0-alpha-{repo version} or 4.99-alpha-{repo version} ?
> It will allow daily build to have a higher version number than 4.0.XX
> version available on
Hi,
Am 09.02.2016 um 10:15 schrieb Nick Østergaard:
> I would personally prefer to include the VCS version in the version string.
Hm, "+bzr12345" sorts before "+dfsg".
But if someone fixes the licence for the two images (find_replace.svg
and find.svg are CC-BY licenced, which is not DFSG
Hi,
On 06.02.2016 20:01, Bernhard Stegmaier wrote:
> I also tried in my Debian VM, but there seem to be no packages available…
I have a few Debian packages of a 3.5 prerelease at
http://www.simonrichter.eu/debian/ -- these are also what I use.
Simon
signature.asc
Description: OpenPGP
Hi,
Am 04.02.2016 um 23:07 schrieb Chris Gammell:
> I was wondering if I could help out with the @kicad_pcb twitter account.
> I keep an eye on all things KiCad on Tweetdeck and noticed that the
> official twitter is rather dormant.
Speaking of social media: I've created a "KiCad" Facebook page
The github plugin includes the CURL headers indirectly, so these headers
need to be on the include search path.
---
pcbnew/github/CMakeLists.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/pcbnew/github/CMakeLists.txt b/pcbnew/github/CMakeLists.txt
index 780d1af..bb18428 100644
---
Hi Wayne,
On 25.01.2016 01:46, Wayne Stambaugh wrote:
> Just a heads up. I will be arriving in Brussels at 2:25PM local time
> assuming my flights are on time. I should get to my hotel by no later
> than 4PM. If any one else is getting in early enough on Friday and is
> interested in grabbing
Hi Tom,
On 21.01.2016 20:00, Tomasz Wlostowski wrote:
> Currently Kicad supports only Intel-based platforms and the patch is
> intended to make them build reliably.
Well, in Debian we ship a few more[1].
> What happens if Boost devs
> decide to change the ABI of the context library once again,
Hi,
Am 21.01.2016 um 14:42 schrieb Tomasz Wlostowski:
> I've tested the new context switching code on Linux, OSX (El Capitan) &
> Windows (all OS 32-bit and 64-bit Intel). Supported compilers are GCC
> and Clang.
Wouldn't that kill all non-Intel platforms? IIRC there are a number of
people
Hi Wayne,
On 16.01.2016 21:40, Wayne Stambaugh wrote:
> Huh?
>
> +// MSVC doesn't have __func__
> +#ifdef _MSC_VER
> +#define __func__ __FUNCTION__
> +#endif
> +
Yes, I wrote yesterday that this patch was included by accident and
should be ignored.
Simon
signature.asc
Description:
Hi,
On 16.01.2016 21:32, Wayne Stambaugh wrote:
> I believe that if you truly wanted to contribute
> to KiCad, you would take a few minutes of time to learn bzr and
> launchpad.
git-remote-bzr works fine for me. Still haven't learned bzr.
Simon
signature.asc
Description: OpenPGP digital
Hi Wayne,
On 16.01.2016 22:05, Wayne Stambaugh wrote:
>> git-remote-bzr works fine for me. Still haven't learned bzr.
> How long did it take you to learn how to use this? I'll bet it was not
> very long at all was it?
Not really -- LP just appears as another remote server to me, and I can
t integers, which the compiler is allowed to
inline the same way as an enum, so this smells like a micro-optimization.
Simon
Simon Richter (11):
Avoid comparing filepos with integers
Drop some debug output
Clarify atan2 overloads
Avoid cast from const_iterator to iterator
Correct imp
The filepos type is not necessarily an integer type, because it also needs
to save the multibyte character state in case we're reading from a stream
with shift states.
The convention of using -1 as a special value is from Unix ftell(), and not
portable. Instead, the stream's failbit needs to be
---
pcbnew/autorouter/rect_placement/rect_placement.cpp | 1 -
1 file changed, 1 deletion(-)
diff --git a/pcbnew/autorouter/rect_placement/rect_placement.cpp b/pcbnew/autorouter/rect_placement/rect_placement.cpp
index da53097..3c7f562 100644
---
Hi,
On 16.01.2016 04:41, Simon Richter wrote:
> The convention of using -1 as a special value is from Unix ftell(), and not
> portable. Instead, the stream's failbit needs to be examined after the call
> to tellg().
Wait, that patch got damaged in a rebase apparently. The test should
On 16.01.2016 04:41, Simon Richter wrote:
>
> This macro is GCC-specific and should be avoided in portable code.
> ---
> include/common.h | 6 ++
> 1 file changed, 6 insertions(+)
>
Meh, that shouldn't have been in the portability branch, but only the
msvc branch. Plea
Windows-style dllimport/dllexport should be used whenever targetting
Windows directly, not just for MINGW.
---
include/import_export.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/import_export.h b/include/import_export.h
index c31729e..672709f 100644
---
This function is passed through a DLL interface, so users need to be aware
that they need to generate import stubs on Windows. Implicit generation of
stubs for undefined functions is an extension of the GNU toolchain.
---
include/kiway.h | 9 +++--
1 file changed, 7 insertions(+), 2
In the C++ standard, this function is only defined for floating point
types, and integers cannot be implicitly converted. Using explicit
conversions avoids a GCC specific extension to the standard library.
---
common/trigo.cpp| 2 +-
gerbview/gerbview_frame.cpp | 2 +-
The standard library requires iterators passed to functions that modify the
container to be mutable iterators, but GCC's implementation accepts
const_iterator in some places where these are only used to mark a place,
but the actual modification happens through a different parameter.
As this
This was apparently left in from debugging earlier, and should no longer be
needed. Since it uses a GCC extension, it makes compilation on others fail.
---
pcbnew/tools/pcbnew_control.cpp | 4
1 file changed, 4 deletions(-)
diff --git a/pcbnew/tools/pcbnew_control.cpp
These values are used in a context where the implicit conversion to integer
is necessary, but creates ambiguous template resolutions that MSVC 9 cannot
resolve. As these constants are not actually an enumerated type, simply
declaring them as static members avoids the problem.
---
While defining functions in another namespace is technically allowed as
long as the definition can be matched to a declaration, this can lead to
ambiguous resolutions, such as here.
---
pcbnew/ratsnest_viewitem.cpp | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
This macro is GCC-specific and should be avoided in portable code.
---
include/common.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/common.h b/include/common.h
index b881444..5eeea09 100644
--- a/include/common.h
+++ b/include/common.h
@@ -98,6 +98,12 @@ enum pseudokeys {
This function has two conflicting definitions in the "kicad" executable and
the other wrapper programs. As the kifaces can be loaded from either, this
silently assumes compatible data layout for the PGM_KICAD and PGM_BASE
types when passed by reference, which is valid only when the compiler is
The GCC standard library headers often include other headers as an
implementation detail. As this is not guaranteed by the standard, it is
non-portable.
---
common/gal/graphics_abstraction_layer.cpp | 2 ++
common/grid_tricks.cpp | 2 ++
common/selcolor.cpp
The NAN macro is not necessarily defined in math.h, so use
std::numeric_limits to look up an appropriate value.
---
common/gal/color4d.cpp | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/common/gal/color4d.cpp b/common/gal/color4d.cpp
index 3b509d3..3a19dc5 100644
---
Hi,
On 14.01.2016 16:51, Chris Pavlina wrote:
> It seems Ubuntu is the only one left, and the new LTS is coming out soon.
In addition, the current Ubuntu LTS is also lacking wxPython, so
scripting does not work there.
Simon
signature.asc
Description: OpenPGP digital signature
Hi,
> No one suggested to choose C++14, it is still a draft AFIK, but just
> that we probably need to set a standard, and we should probably
> consider the feasibility of choosing C++11. I am sure a lot of
> developers would like to see that happen, but we need a good accept
> for that from the
These enums are silently treated as equivalent in the ERC, because the
values are casted to integers. This works for the most part, because the
values are similar, but this is in no way enforced, and there is a small
inconsistency (NET_UNSPECIFIED vs PIN_PASSIVE).
This turns the storage into a
The C++ preprocessor is actually not required to process "true" and "false"
correctly. This works in C if is included, because these are
then macros themselves, and resolved correctly, but C++ requires them to be
keywords, so no such macros exist, and the preprocessor can treat both as
Mostly cosmetic change, although there are compilers that choke on this.
The C++ standard specifies that classes contain themselves as members,
probably so they shadow any other definition of the same name for their own
member functions, but there is really no reason why the class name should
be
Hi Chris,
Am 13.01.2016 um 02:23 schrieb Chris Pavlina:
> This patch doesn't apply to the latest revision for me, at very least
> the line numbers are off. Might have to rebase.
Ah yes, that is on top of the other stack of patches I sent, where I
split out the comparison function into a new
Hi Nick,
Am 13.01.2016 um 09:03 schrieb Nick Østergaard:
> There is no attached patch.
Yes, if there are multiple patches I occasionally write a cover letter
marked [0/x] that contains the blurb that shouldn't go into the commit
log -- so "git am" can import my commit messages directly. This is
Hi,
On 13.01.2016 20:13, Chris Pavlina wrote:
> Patch 4 has a small UI problem: with a lot of pins, the text field
> listing defined pins overflows: https://misc.c4757p.com/overflow.png
> Could you please correct this, perhaps by allowing the field to wrap,
> before I apply the next two? A
Hi,
this brings our copy of FindwxWidgets.cmake in sync with the version in the
CMake repository. Since last September, CMake includes our changes (version
check, wx 3.1, support for webview component), and these have been released
with CMake 3.4.
The change to drop the -isystem special handling
---
eeschema/dialogs/dialog_lib_edit_pin_table.cpp | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/eeschema/dialogs/dialog_lib_edit_pin_table.cpp b/eeschema/dialogs/dialog_lib_edit_pin_table.cpp
index 63d8226..52c399f 100644
---
This is in anticipation of the introduction of icons -- retrieving all the
icons and throwing them away during sorting takes ages.
---
eeschema/dialogs/dialog_lib_edit_pin_table.cpp | 88 ++
1 file changed, 47 insertions(+), 41 deletions(-)
diff --git
Hi,
these are two small pin table improvements: a direct string access avoiding
the wxVariant wrapping/unwrapping for internal functions (major speedup in
sorting), and a way to undo the grouping in the pin table in order to get a
flat table.
Simon
Simon Richter (2):
pin table: Add
Hi,
On 04.01.2016 04:50, Jon Neal wrote:
> Is there any chance that the CMAKE_BUILD_TYPE flag could be changed from
> Product to Debug by default? It is the only flag I have to include when
> I run cmake now and I often forget to set it.
The goal is to make it easy for the people who want to
Hi Wayne,
On 04.01.2016 00:50, Wayne Stambaugh wrote:
> I forgot to delete download_avhttp.cmake and the avhttp source zip file
> so this patch wont be necessary.
There is still a paragraph on KICAD_SKIP_BOOST in the documentation.
Simon
signature.asc
Description: OpenPGP digital
Hi,
this removes two leftover references to KICAD_SKIP_BOOST.
Simon
---
CMakeModules/download_avhttp.cmake | 9 +
Documentation/development/compiling.md | 8
2 files changed, 1 insertion(+), 16 deletions(-)
diff --git a/CMakeModules/download_avhttp.cmake
Hi,
this patch set implements a summary line for the pin table, listing the
currently defined pins, to quickly check whether any pins have been
forgotten.
If pins 1,2,3,4,5,6,8,9,10,11,12 are defined, the status bar then reads
"1-6,8-12".
Simon
Simon Richter (5):
Split off
/eeschema/pin_number.cpp b/eeschema/pin_number.cpp
new file mode 100644
index 000..9f5f9ea
--- /dev/null
+++ b/eeschema/pin_number.cpp
@@ -0,0 +1,134 @@
+/*
+ * This program source code file is part of KiCad, a free EDA CAD application.
+ *
+ * Copyright (C) 2015 Simon Richter
+ * Copyright (C) 20
Below the pin table, display which pins are currently defined, in order to
find gaps.
---
eeschema/dialogs/dialog_lib_edit_pin_table.cpp | 27 +++
eeschema/dialogs/dialog_lib_edit_pin_table.h | 2 +
.../dialogs/dialog_lib_edit_pin_table_base.cpp | 3 +
This class wraps the comparison function in a way that is compatible with
std::map and std::set. This, too is generally useful, so it should be moved
to the generic header.
At the same time, the criterium for less-than is changed from "equal to -1"
to "smaller than 0", because technically the
The "set of pin numbers" functionality is also useful outside the pin table
dialog, so create a wrapper class that exposes the relevant interfaces.
---
eeschema/dialogs/dialog_lib_edit_pin_table.cpp | 2 +-
eeschema/pin_number.h | 21 +
2 files
For pin numbers ending in digits, consecutive numbers are collapsed to
ranges for a better overview.
---
eeschema/pin_number.cpp | 49 +++--
1 file changed, 39 insertions(+), 10 deletions(-)
diff --git a/eeschema/pin_number.cpp
Hi,
On 21.12.2015 08:35, Lorenzo Marcantonio wrote:
> After this I'm *not* advocating a binary format, there would be no
> advantage for it in pcbnew. There are no performance restraints in
> either speed or space for kicad files so just use whatever is easier for
> you to manage (i.e.
Hi,
> Just a quick heads up. I just made my travel arrangements for FOSDEM
> 2016. That always makes it feel official to me. Please try to attend
> if you can manage it. I would like to meet as many of the KiCad
> developers as possible. I can tell you that EDA dev room dinner
> Saturday
Hi,
Am 14.12.2015 um 16:01 schrieb Mark Roszko:
> Stupid question, doesn't this change remove -O2 entirely for all gcc
> builds? Previously it defaulted to -O2 if the bug wasn't present. Now
> it never optimizes as -O0 is the default.
The default depends on the build type -- if your source tree
Hi Wayne,
On 11.12.2015 20:23, Wayne Stambaugh wrote:
> Not until after the new schematic and symbol library file formats are
> implemented. Support for pin and unit swapping will be built in to the
> new symbol library file format.
That would be fairly orthogonal to what I'm suggesting -- I'd
Hi,
> - set( BOOST_CFLAGS "cflags=${PIC_FLAG}" )
> - set( BOOST_CXXFLAGS "cxxflags=${PIC_FLAG}" )
> because cmake will only set -fpic in CFLAGS but the entire cmake file
> uses BOOST_CFLAGS and never passes the plain CFLAGS
The Boost build knows on its own that it needs -fPIC -- except if you
Hi,
I'm thinking about adding some support for pin and unit swapping. To
make it maximally useful, I'd like to generate a list of alternative
mappings inside the netlist, and add the actual swap functionality
inside pcbnew -- so if it turns out that the layout becomes easier if
two pins are
Hi,
On 08.12.2015 22:52, Wayne Stambaugh wrote:
> I asked Simon if he could figure out how to make it less noisy. I
> haven't heard back from him yet.
>>> CMake Warning (dev) at utils/idftools/CMakeLists.txt:17 (add_executable):
>>> Policy CMP0063 is not set: Honor visibility properties for
Hi,
I've made a backport of RC1 to Debian jessie -- release backports will
happen once the release has hit unstable. The same packages have been
uploaded to Debian, so if you have jessie-backports configured in your
sources.list, your system should silently switch over to the release
package
Hi,
Am 04.12.2015 um 06:46 schrieb Ike Shields:
> In the print screen on R/H side;
>
> Under Copper layers Tick is on “B.cu”
In the main window, on the right hand side, there are two tabs, "Layers"
and "Render". The former is overridden by the layer selection in the
print dialog, but the
Hi,
Am 03.12.2015 um 20:11 schrieb Jon Neal:
> With this patch when you add new layers in pcbnew they will be selected
> by default for plotting.
that is LP#1507822. -- https://bugs.launchpad.net/kicad/+bug/1507822
Simon
signature.asc
Description: OpenPGP digital signature
Hi,
On 01.12.2015 09:07, jp charras wrote:
>> As boost::polygon is gone, we can drop the workaround for older gcc.
> boost::polygon is gone, not the gcc bug.
> This is likely a gcc bug, not a boost::polygon bug.
Indeed, but the code that triggered the bug is gone, so it shouldn't
affect us any
As boost::polygon is gone, we can drop the workaround for older gcc.
---
CMakeLists.txt | 15 ---
1 file changed, 15 deletions(-)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index ec89978..cd3e1bc 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -171,21 +171,6 @@ if(
Hi,
On 01.12.2015 07:52, Ike Shields wrote:
> I did an update and it back that I was up to date?
Also, I just noticed. The bzr 4027 version is ancient. The 4.0.0 version
is not contained in Debian stable, and will not be included there
either, as Debian never updates stable releases.
I believe
This simply moves the OpenMP handling code out of the gcc specific block
with no code changes. This is safe because OpenMP detection is portable.
---
CMakeLists.txt | 33 +++--
1 file changed, 19 insertions(+), 14 deletions(-)
diff --git a/CMakeLists.txt
CMake 3.0 defines two new variables,
* CMAKE_CXX_VISIBILITY_PRESET and
* CMAKE_VISIBILITY_INLINES_HIDDEN
to control whether symbols not explicitly tagged for export are implicitly
exported. Because only version 3.3 and following also applies that to
static libraries when in 3.3 mode,
CMake provides a simple declarative statement to enable PIC, so no compiler
dependent handling is required. There is also no need to tell Boost to
build with -fPIC, their build system is smart enough.
---
CMakeLists.txt| 13 -
CMakeModules/download_boost.cmake |
Hi,
On 01.12.2015 07:52, Ike Shields wrote:
> I am having trouble printing the last part (print to copper. it is the
> printed to photo paper then laminated onto Copper) when I print all I
> get is the small drill holes and solder pads no tracks.
Could it be that some of the "Layer" or
Hi,
Am 05.11.2015 um 03:45 schrieb Mark Roszko:
>> I have repeatedly asked that devs do incremental changes so I can
>> easily review them.
> It's hard to do refactoring when your one commit has to throw out the
> kitchen sink.
However, it is often possible to submit multiple commits of the
Hi,
this should get us over the next three months.
Simon
---
copyright.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/copyright.h b/copyright.h
index 79a50ec..4110151 100644
--- a/copyright.h
+++ b/copyright.h
@@ -12,8 +12,8 @@ may choose to document this
Hi,
On 19.09.2015 23:05, Wayne Stambaugh wrote:
> No such document but basically gcc on linux and windows and clang on
> osx. The official policy on MS VS is that we will not support it.
VS 2015 is broken to the extent that it fails to compile some of the
template code in VECTOR2<> and BOX<>,
Hi,
On 14.09.2015 04:28, Mark Roszko wrote:
> Now anyone using the newer git-remote-bzr is in for fun as well
> because there is no such thing as "origin/HEAD".
origin/HEAD is automatically created with git-remote-bzr, but not
restored if lost.
You can recreate it via
echo "ref:
Hi,
while investigating an internal compiler error[1] in MSVC, I ran across
this function.
My feeling is that it is broken:
For int:
top_left = std::numeric_limits::min() / 2 +
std::numeric_limits::epsilon();
size = std::numeric_limits::max() -
Hi,
On 14.09.2015 19:10, Mark Roszko wrote:
> Weird, its supposed to be 0 for ints.
> http://en.cppreference.com/w/cpp/types/numeric_limits/epsilon
I was referring to the bit where it says "It is only meaningful if
std::numeric_limits::is_integer == false". I think it's not a big
problem for
Hi,
Am 14.09.2015 um 23:58 schrieb Adam Wolf:
[.deb packages]
> Isn't that what's in the reynauld PPA?
No, that's for Ubuntu -- they happen to use the same package format, but
packages are generally not expected to be compatible.
Simon
signature.asc
Description: OpenPGP digital
netlist_reader.h is also used by pcbcommon, so a dependency is necessary.
---
common/CMakeLists.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/common/CMakeLists.txt b/common/CMakeLists.txt
index 2b558c4..2d843cf 100644
--- a/common/CMakeLists.txt
+++ b/common/CMakeLists.txt
@@ -388,6
Hi,
this is an actual problem with VS 2015, which uses different name mangling
rules for "struct" and "class". This makes all instances use "struct".
Simon
---
pcbnew/dialogs/dialog_track_via_properties.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Hi,
this adds a number of missing includes. On gcc, other system includes use
these internally, but that is not guaranteed.
Simon
---
common/gal/graphics_abstraction_layer.cpp | 2 ++
common/grid_tricks.cpp | 2 ++
common/selcolor.cpp
Hi,
> Looks ok to me, except that the naming of the _git_LONG_HASH_ORIGIN
> variable does not match what it is, it should have been
> _git_LONG_HASH_LOCAL instead.
This completely fails to compile for me:
| [ 11%] Generating version string header
| -- Using Git to determine build version
Hi,
On 13.09.2015 17:55, Lorenzo Marcantonio wrote:
> I suppose that is talking about the implementation of va_start: address
> of last+sizeof of last gives the starting point of the va_list (in the
> 'correct' stack direction, obviously); am I correct?
Indeed. The standard is written so va_*
Hi,
On 13.09.2015 20:29, Simon Richter wrote:
> This completely fails to compile for me:
Okay, when I wipe my local repository and repeat the checkout, it works.
Having a fallback to origin/master and/or more graceful handling of a
missing origin/HEAD reference would be great though.
Si
Hi,
On 06.09.2015 13:11, Mário Luzeiro wrote:
> what is the c++ standard? that kicad is building? Please make a X in one of
> the following options:
Currently we appear to be using C++98, with a number of nonstandard GNU
extensions.
C++11 would be nice. C++14 is too new, compiler support is
Hi,
this updates our copy of FindwxWidgets.cmake to a state that is fairly
close to what is in the CMake repository. The remaining improvements over
their version are
- version check
- forward compatibility with 3.1 (looking for wx-config-3.1)
- handling for the "webview" component
These
Hi,
CMake's test for OpenMP is generic enough to work anywhere, so there is no
good reason to make it conditional on gcc/clang.
This moves the OpenMP handling to the CMakeLists.txt toplevel.
Simon
---
CMakeLists.txt | 33 +++--
1 file changed, 19 insertions(+),
Hi,
As boost::polygon is gone, we can drop the workaround for older gcc.
Simon
---
CMakeLists.txt | 15 ---
1 file changed, 15 deletions(-)
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 6e79fc9..b76c48d 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -171,21 +171,6 @@
Hi,
probably an oversight after removing debug code. This is not needed, and in
the middle of a source file, between functions.
Simon
---
pcbnew/autorouter/rect_placement/rect_placement.cpp | 1 -
1 file changed, 1 deletion(-)
diff --git
Hi,
CMake provides a simple declarative statement to enable PIC, so no compiler
dependent handling is required. There is also no need to tell Boost to
build with -fPIC, their build system is smart enough.
Simon
---
CMakeLists.txt| 13 -
Hi,
this is an improved version of the earlier patch, using the visibility
handling in CMake 3.3, and falling back to changing the global CXXFLAGS on
previous versions.
As CMake 3.3 attempts to be compatible with earlier versions, the new
behaviour needs to be explicitly enabled until 3.3
Hi,
this allows to undo the grouping in the pin table, by right clicking on the
column header of the currently active grouping column -- this allows you to
go back to a fully flat table.
Simon
---
eeschema/dialogs/dialog_lib_edit_pin_table.cpp | 6 +++---
1 file changed, 3 insertions(+), 3
Hi,
I'm trying to figure out who is owning the *_SCREEN object pointed to by
EDA_DRAW_FRAME::m_currentScreen.
In EDA_DRAW_FRAME::~EDA_DRAW_FRAME(), the object pointed to is deleted,
which suggests to me that the draw frame has some sort of ownership,
however this will only delete the last object
Hi,
CMake provides a readymade test for the GCC/CLang -fvisibility= flag. This
removes our own test and uses the result from CMake.
I've left the test for "NOT APPLE" in place -- is there a particular reason
why we do that?
Simon
---
CMakeLists.txt | 16
SCREEN objects are typically owned by the DRAW_FRAME they are attached to.
SCH_SCREEN objects may additionally be shared between one DRAW_FRAME, and
multiple SCH_SHEET objects, so they are reference counted.
To make this distinction more obvious, and avoid potential errors, move the
pointer
Hi,
small cleanup: there are a few unnecessary casts because the covariant
return already does the right thing. Where we get the screen object only in
order to get the active layer, use the accessor function directly.
Simon
---
include/wxBasePcbFrame.h | 4 ++--
Hi,
Am 01.08.2015 um 20:40 schrieb Wayne Stambaugh:
Does anyone have any major objections to this
solution. If not, I will commit this patch.
On the contrary, I'd like to see this happen.
Simon
signature.asc
Description: OpenPGP digital signature
Hi,
On 29.07.2015 21:00, jp charras wrote:
I removed a few conditional compilations in rev 6014.
This bug already known, but not fixed, should be fixed in this rev.
There is an older patch from Blair Bonnett removing all support for
wxWidgets 3.0. I have that in my repository, and it got
Hi,
three small patches for include files cleanup, each of them pretty
self-explanatory.
Simon
Simon Richter (3):
Remove superfluous includes
Include iso646.h for not, and and or keywords
add missing C++ stdlib headers
common/gal/graphics_abstraction_layer.cpp | 2 ++
common
701 - 800 of 898 matches
Mail list logo