Re: [Kicad-developers] Release 4.0.5 tagged.
Yeah that was my thoughts. Include in the tarball the old and the new names. On Wed, Dec 7, 2016 at 4:38 PM, Nick Østergaard wrote: > Yeah, I don't know what is the best solution. But alternatively we > could also just include them in the tarball, if we don't want it to > "pollute" the github kicad org. > > These tarballs: > http://downloads.kicad-pcb.org/libraries/ > > 2016-12-07 22:28 GMT+01:00 Carl Poirier : > > Aah, I see now. I had missed the part that the fp-lib-table didn't get > > updated along the new install. > > > > We indeed decided to keep the pretty names the same but with Github's > > redirection, I missed the local uppgrade use case. What I can do is > restore > > a copy of the pretties with the old name. This way the newer pretties > will > > work with the old fp-lib-table. > > > > Carl > > > > On Wed, Dec 7, 2016 at 1:57 PM, Wayne Stambaugh > > wrote: > >> > >> On 12/7/2016 1:52 PM, Nick Østergaard wrote: > >> > Yes, but lets use the windows use case. A user has 4.0.4 intalled and > >> > have fp-lib-table that matches the one used there for local libs. He > >> > then uninstalls 4.0.4 and install 4.0.5 (this would be the same as an > >> > update with a package manager and possibly osx too), the fp-lib-table > >> > is a user preference and will now reference non existing pretty dirs. > >> > The user starts pcbnew or cvpcb to add parts and when kicad tries to > >> > access one of those libs that do not exist anymore he gets > >> > "unexpected" errors. > >> > > >> > All I ask about is really; what is the desired action? > >> > > >> > I am ok with just including the rename, but I remember that at some > >> > time we said that we should not remove libs for patch releases. This > >> > would require a mention in the release note, which is probably also > >> > acceptable. > >> > >> I believe keeping the library names the same for stable series releases > >> was what we originally decided. I'm OK with adding a note to the > >> release notes for this one time. In the future, we should probably > >> create a release series branch for the libraries as we did with the > >> source and cherry-pick changes as required. I know it's extra work but > >> this will keep users happy. Hopefully there wont be many more 4 stable > >> releases so it probably doesn't make sense to do this until the 5 stable > >> release. > >> > >> > > >> > > >> > 2016-12-07 19:43 GMT+01:00 Carl Poirier : > >> >> Well, if I use all the libs as local pretties, using the fp-lib-table > >> >> that > >> >> has been tagged the same will work, won't it? Do we want to support > mix > >> >> and > >> >> matching tags? > >> >> > >> >> On Wed, Dec 7, 2016 at 10:45 AM, Nick Østergaard > >> >> wrote: > >> >>> > >> >>> Well, the issue os the fact that if a user has choosen (one way or > the > >> >>> other) to use all of the local libs he needs to update the > >> >>> fp-lib-table > >> >>> manually. An option is to copy the renamed pretty fors to the old > name > >> >>> as to > >> >>> not generate errors for the user. > >> >>> > >> >>> > >> >>> Den 07/12/2016 13.21 skrev "Carl Poirier" >: > >> >>> > >> >>> The KIGITHUB variable leads to Github. For using the pretties > locally, > >> >>> the > >> >>> fp-lib-table.for-pretty has to be used instead, which is the one > >> >>> that's > >> >>> included by default in the stable release. Anyway, as I had > mentioned > >> >>> in > >> >>> another thread very recently, the Github plugin is not even built in > >> >>> the > >> >>> stable release so I don't know how users can get into trouble. > >> >>> > >> >>> Carl > >> >>> > >> >>> On Dec 7, 2016 1:45 AM, "Nick Østergaard" > wrote: > >> > >> But this will not help if the user is using them locally. How is > that > >> supposed to be handled? > >> > >> 2016-12-07 0:46 GMT+01:00 Carl Poirier : > >> > Hi Nick, > >> > > >> > I do understand but it is not an issue, Just try it out, go to > >> > https://github.com/KiCad/Buttons_Switches_ThroughHole.pretty. > >> > > >> > Carl > >> > > >> > On Tue, Dec 6, 2016 at 5:12 PM, Nick Østergaard < > oe.n...@gmail.com> > >> > wrote: > >> >> > >> >> Hi Carl > >> >> > >> >> I have found an issue with the lib tagging. I think we decided to > >> >> not > >> >> remove any libs for the patch releaes. That is for releases where > >> >> only > >> >> the third number changes. What I see is: > >> >> > >> >> Buttons_Switches_ThroughHole.pretty remaned to > >> >> Buttons_Switches_THT.pretty > >> >> Capacitors_ThroughHole.pretty renamed to Capacitors_THT.pretty > >> >> Connect.pretty renamed to Connectors.pretty > >> >> Terminal_Blocks.pretty renamed to Connectors_Terminal_Blocks. > pretty > >> >> Sockets_WAGO734.pretty renamed to Connectors_WAGO.pretty > >> >> Diodes_ThroughHole.pretty renamed to Diodes_THT.pretty > >> >> Display.pretty renamed to Displays.pretty > >> >> Relays_ThroughHole.pretty re
Re: [Kicad-developers] Release 4.0.5 tagged.
Yeah, I don't know what is the best solution. But alternatively we could also just include them in the tarball, if we don't want it to "pollute" the github kicad org. These tarballs: http://downloads.kicad-pcb.org/libraries/ 2016-12-07 22:28 GMT+01:00 Carl Poirier : > Aah, I see now. I had missed the part that the fp-lib-table didn't get > updated along the new install. > > We indeed decided to keep the pretty names the same but with Github's > redirection, I missed the local uppgrade use case. What I can do is restore > a copy of the pretties with the old name. This way the newer pretties will > work with the old fp-lib-table. > > Carl > > On Wed, Dec 7, 2016 at 1:57 PM, Wayne Stambaugh > wrote: >> >> On 12/7/2016 1:52 PM, Nick Østergaard wrote: >> > Yes, but lets use the windows use case. A user has 4.0.4 intalled and >> > have fp-lib-table that matches the one used there for local libs. He >> > then uninstalls 4.0.4 and install 4.0.5 (this would be the same as an >> > update with a package manager and possibly osx too), the fp-lib-table >> > is a user preference and will now reference non existing pretty dirs. >> > The user starts pcbnew or cvpcb to add parts and when kicad tries to >> > access one of those libs that do not exist anymore he gets >> > "unexpected" errors. >> > >> > All I ask about is really; what is the desired action? >> > >> > I am ok with just including the rename, but I remember that at some >> > time we said that we should not remove libs for patch releases. This >> > would require a mention in the release note, which is probably also >> > acceptable. >> >> I believe keeping the library names the same for stable series releases >> was what we originally decided. I'm OK with adding a note to the >> release notes for this one time. In the future, we should probably >> create a release series branch for the libraries as we did with the >> source and cherry-pick changes as required. I know it's extra work but >> this will keep users happy. Hopefully there wont be many more 4 stable >> releases so it probably doesn't make sense to do this until the 5 stable >> release. >> >> > >> > >> > 2016-12-07 19:43 GMT+01:00 Carl Poirier : >> >> Well, if I use all the libs as local pretties, using the fp-lib-table >> >> that >> >> has been tagged the same will work, won't it? Do we want to support mix >> >> and >> >> matching tags? >> >> >> >> On Wed, Dec 7, 2016 at 10:45 AM, Nick Østergaard >> >> wrote: >> >>> >> >>> Well, the issue os the fact that if a user has choosen (one way or the >> >>> other) to use all of the local libs he needs to update the >> >>> fp-lib-table >> >>> manually. An option is to copy the renamed pretty fors to the old name >> >>> as to >> >>> not generate errors for the user. >> >>> >> >>> >> >>> Den 07/12/2016 13.21 skrev "Carl Poirier" : >> >>> >> >>> The KIGITHUB variable leads to Github. For using the pretties locally, >> >>> the >> >>> fp-lib-table.for-pretty has to be used instead, which is the one >> >>> that's >> >>> included by default in the stable release. Anyway, as I had mentioned >> >>> in >> >>> another thread very recently, the Github plugin is not even built in >> >>> the >> >>> stable release so I don't know how users can get into trouble. >> >>> >> >>> Carl >> >>> >> >>> On Dec 7, 2016 1:45 AM, "Nick Østergaard" wrote: >> >> But this will not help if the user is using them locally. How is that >> supposed to be handled? >> >> 2016-12-07 0:46 GMT+01:00 Carl Poirier : >> > Hi Nick, >> > >> > I do understand but it is not an issue, Just try it out, go to >> > https://github.com/KiCad/Buttons_Switches_ThroughHole.pretty. >> > >> > Carl >> > >> > On Tue, Dec 6, 2016 at 5:12 PM, Nick Østergaard >> > wrote: >> >> >> >> Hi Carl >> >> >> >> I have found an issue with the lib tagging. I think we decided to >> >> not >> >> remove any libs for the patch releaes. That is for releases where >> >> only >> >> the third number changes. What I see is: >> >> >> >> Buttons_Switches_ThroughHole.pretty remaned to >> >> Buttons_Switches_THT.pretty >> >> Capacitors_ThroughHole.pretty renamed to Capacitors_THT.pretty >> >> Connect.pretty renamed to Connectors.pretty >> >> Terminal_Blocks.pretty renamed to Connectors_Terminal_Blocks.pretty >> >> Sockets_WAGO734.pretty renamed to Connectors_WAGO.pretty >> >> Diodes_ThroughHole.pretty renamed to Diodes_THT.pretty >> >> Display.pretty renamed to Displays.pretty >> >> Relays_ThroughHole.pretty renamed to Relays_THT.pretty >> >> Resistors_ThroughHole.pretty renamed to Resistors_THT.pretty >> >> Sockets_BNC.pretty removed? >> >> Sockets_Mini-Universal.pretty renamed to >> >> Connectors_Mini-Universal.pretty >> >> >> >> Won't users have to manually update their fp-lib-table? >> >> >> >> Repos not tagged, Connectors_Amphenol.pretty Battery_Holders.pretty >> >> .
Re: [Kicad-developers] Release 4.0.5 tagged.
Aah, I see now. I had missed the part that the fp-lib-table didn't get updated along the new install. We indeed decided to keep the pretty names the same but with Github's redirection, I missed the local uppgrade use case. What I can do is restore a copy of the pretties with the old name. This way the newer pretties will work with the old fp-lib-table. Carl On Wed, Dec 7, 2016 at 1:57 PM, Wayne Stambaugh wrote: > On 12/7/2016 1:52 PM, Nick Østergaard wrote: > > Yes, but lets use the windows use case. A user has 4.0.4 intalled and > > have fp-lib-table that matches the one used there for local libs. He > > then uninstalls 4.0.4 and install 4.0.5 (this would be the same as an > > update with a package manager and possibly osx too), the fp-lib-table > > is a user preference and will now reference non existing pretty dirs. > > The user starts pcbnew or cvpcb to add parts and when kicad tries to > > access one of those libs that do not exist anymore he gets > > "unexpected" errors. > > > > All I ask about is really; what is the desired action? > > > > I am ok with just including the rename, but I remember that at some > > time we said that we should not remove libs for patch releases. This > > would require a mention in the release note, which is probably also > > acceptable. > > I believe keeping the library names the same for stable series releases > was what we originally decided. I'm OK with adding a note to the > release notes for this one time. In the future, we should probably > create a release series branch for the libraries as we did with the > source and cherry-pick changes as required. I know it's extra work but > this will keep users happy. Hopefully there wont be many more 4 stable > releases so it probably doesn't make sense to do this until the 5 stable > release. > > > > > > > 2016-12-07 19:43 GMT+01:00 Carl Poirier : > >> Well, if I use all the libs as local pretties, using the fp-lib-table > that > >> has been tagged the same will work, won't it? Do we want to support mix > and > >> matching tags? > >> > >> On Wed, Dec 7, 2016 at 10:45 AM, Nick Østergaard > wrote: > >>> > >>> Well, the issue os the fact that if a user has choosen (one way or the > >>> other) to use all of the local libs he needs to update the fp-lib-table > >>> manually. An option is to copy the renamed pretty fors to the old name > as to > >>> not generate errors for the user. > >>> > >>> > >>> Den 07/12/2016 13.21 skrev "Carl Poirier" : > >>> > >>> The KIGITHUB variable leads to Github. For using the pretties locally, > the > >>> fp-lib-table.for-pretty has to be used instead, which is the one that's > >>> included by default in the stable release. Anyway, as I had mentioned > in > >>> another thread very recently, the Github plugin is not even built in > the > >>> stable release so I don't know how users can get into trouble. > >>> > >>> Carl > >>> > >>> On Dec 7, 2016 1:45 AM, "Nick Østergaard" wrote: > > But this will not help if the user is using them locally. How is that > supposed to be handled? > > 2016-12-07 0:46 GMT+01:00 Carl Poirier : > > Hi Nick, > > > > I do understand but it is not an issue, Just try it out, go to > > https://github.com/KiCad/Buttons_Switches_ThroughHole.pretty. > > > > Carl > > > > On Tue, Dec 6, 2016 at 5:12 PM, Nick Østergaard > > wrote: > >> > >> Hi Carl > >> > >> I have found an issue with the lib tagging. I think we decided to > not > >> remove any libs for the patch releaes. That is for releases where > only > >> the third number changes. What I see is: > >> > >> Buttons_Switches_ThroughHole.pretty remaned to > >> Buttons_Switches_THT.pretty > >> Capacitors_ThroughHole.pretty renamed to Capacitors_THT.pretty > >> Connect.pretty renamed to Connectors.pretty > >> Terminal_Blocks.pretty renamed to Connectors_Terminal_Blocks.pretty > >> Sockets_WAGO734.pretty renamed to Connectors_WAGO.pretty > >> Diodes_ThroughHole.pretty renamed to Diodes_THT.pretty > >> Display.pretty renamed to Displays.pretty > >> Relays_ThroughHole.pretty renamed to Relays_THT.pretty > >> Resistors_ThroughHole.pretty renamed to Resistors_THT.pretty > >> Sockets_BNC.pretty removed? > >> Sockets_Mini-Universal.pretty renamed to > >> Connectors_Mini-Universal.pretty > >> > >> Won't users have to manually update their fp-lib-table? > >> > >> Repos not tagged, Connectors_Amphenol.pretty > Battery_Holders.pretty . > >> This looks correct, so that is ok. > >> > >> The fp-lib-table.for-pretty seems to match the repos tagged. > >> > >> Those renamed repos will easily summon errors in the users face. I > >> hope you understand what I mean. > >> > >> 2016-12-03 22:54 GMT+01:00 Carl Poirier : > >>> I will be tagging the libs in 24h. > >>> > >>> Carl > >>> > >>> On Sat, Dec 3, 2016 at 3:00 PM, Adam Wolf > >>>
[Kicad-developers] Patch to replace avhttp by curl in stable branch
Hi all,
I wrote this patch to allow users who cannot use avhttp for some reason to
compile the *stable*
branch using curl instead of avhttp, when using github plugin.
I tested it on W7 and Kubuntu 14.04.
However the more tests the better.
Please test it and see if there are issues (I could have missed something among
the lot of
patches related to this replacement)
Thanks.
It could be merged in stable 4.06 ( if exists...)
--
Jean-Pierre CHARRAS
>From e5c02a4325806c848c7b51e1d6b3af122b0b00d9 Mon Sep 17 00:00:00 2001
From: jean-pierre charras
Date: Wed, 7 Dec 2016 18:43:57 +0100
Subject: [PATCH] Try to replace avhttp by Curl
---
CMakeLists.txt | 4 +
CMakeModules/download_avhttp.cmake | 65 --
Documentation/development/compiling.md | 12 +-
common/CMakeLists.txt | 15 ++-
common/basicframe.cpp | 13 ++
common/footprint_info.cpp | 30 ++---
common/kicad_curl/kicad_curl.cpp | 224 +
common/kicad_curl/kicad_curl_easy.cpp | 94 ++
include/kicad_curl/kicad_curl.h| 108
include/kicad_curl/kicad_curl_easy.h | 184 +++
pcbnew/CMakeLists.txt | 4 +-
pcbnew/github/CMakeLists.txt | 40 +-
pcbnew/github/github_getliblist.cpp| 70 ++-
pcbnew/github/github_getliblist.h | 4 +-
pcbnew/github/github_plugin.cpp| 180 --
pcbnew/github/github_plugin.h | 4 +-
16 files changed, 755 insertions(+), 296 deletions(-)
delete mode 100644 CMakeModules/download_avhttp.cmake
create mode 100644 common/kicad_curl/kicad_curl.cpp
create mode 100644 common/kicad_curl/kicad_curl_easy.cpp
create mode 100644 include/kicad_curl/kicad_curl.h
create mode 100644 include/kicad_curl/kicad_curl_easy.h
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 6eea373..09932cc 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -569,6 +569,10 @@ if( NOT GLEW_FOUND )
check_find_package_result( GLEW_FOUND "GLEW" )
endif()
+# Find CURL library
+find_package( CURL REQUIRED )
+
+
##
# Find Cairo library #
##
diff --git a/CMakeModules/download_avhttp.cmake b/CMakeModules/download_avhttp.cmake
deleted file mode 100644
index abc52b7..000
--- a/CMakeModules/download_avhttp.cmake
+++ /dev/null
@@ -1,65 +0,0 @@
-# This program source code file is part of KICAD, a free EDA CAD application.
-#
-# Copyright (C) 2013 SoftPLC Corporation, Dick Hollenbeck
-# Copyright (C) 2013 Kicad Developers, see AUTHORS.txt for contributors.
-#
-# This program is free software; you can redistribute it and/or
-# modify it under the terms of the GNU General Public License
-# as published by the Free Software Foundation; either version 2
-# of the License, or (at your option) any later version.
-#
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with this program; if not, you may find one here:
-# http://www.gnu.org/licenses/old-licenses/gpl-2.0.html
-# or you may search the http://www.gnu.org website for the version 2 license,
-# or you may write to the Free Software Foundation, Inc.,
-# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA
-
-
-
-# Download av_http and install into ${PREFIX}, typically in our KiCad source tree.
-# Assumes include( ExternalProject ) was done inline previous to this file
-# and that set( DOWNLOAD_DIR ... ) was set in a higher context.
-
-#--
-
-# soon cmake will have https support, switch to a true download then:
-#set( AVHTTP_RELEASE ??? )
-#set( AVHTTP_MD5 ) # re-calc this on every RELEASE change
-
-#
-
-
-# Where the library is to be installed.
-set( PREFIX ${DOWNLOAD_DIR}/avhttp )
-
-if( KICAD_SKIP_BOOST )
-set( AVHTTP_DEPEND "" )
-else()
-set( AVHTTP_DEPEND "boost" )
-endif()
-
-
-# Install the AVHTTP header only library ${PREFIX}
-ExternalProject_Add( avhttp
-PREFIX ${PREFIX}
-DOWNLOAD_DIR${DOWNLOAD_DIR} # no true download yet
-
-# grab it from a local zip file for now, cmake caller's source dir
-URL ${CMAKE_CURRENT_SOURCE_DIR}/avhttp-master.zip
-DEPENDS ${AVHTTP_DEPEND}
-
-CONFIGURE_COMMAND ""
-
-BUILD_COMMAND ""
-INSTALL_COMMAND ${CMAKE_COMMAND} -E copy_directory
-)
-
-
-set( AVHTTP_INCLUDE_DIR "${PREFIX}/include" CACHE FILEPATH "AVHTTP include directory" )
-mark_as_advanced( AVHTTP_INCLUDE_DIR )
diff --git a/Documentation/development/c
Re: [Kicad-developers] [RFC] [PATCH] simple C++ tests
Hello all, one question might have drowned a bit: is there any particular reason why kicad builds executables and libs into their own private directories in first place rather than into a "bin" directory that I should be aware off? It will help all considerations when I don't miss the important stuff :) Michael ___ 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] Release 4.0.5 tagged.
On 12/7/2016 1:52 PM, Nick Østergaard wrote: > Yes, but lets use the windows use case. A user has 4.0.4 intalled and > have fp-lib-table that matches the one used there for local libs. He > then uninstalls 4.0.4 and install 4.0.5 (this would be the same as an > update with a package manager and possibly osx too), the fp-lib-table > is a user preference and will now reference non existing pretty dirs. > The user starts pcbnew or cvpcb to add parts and when kicad tries to > access one of those libs that do not exist anymore he gets > "unexpected" errors. > > All I ask about is really; what is the desired action? > > I am ok with just including the rename, but I remember that at some > time we said that we should not remove libs for patch releases. This > would require a mention in the release note, which is probably also > acceptable. I believe keeping the library names the same for stable series releases was what we originally decided. I'm OK with adding a note to the release notes for this one time. In the future, we should probably create a release series branch for the libraries as we did with the source and cherry-pick changes as required. I know it's extra work but this will keep users happy. Hopefully there wont be many more 4 stable releases so it probably doesn't make sense to do this until the 5 stable release. > > > 2016-12-07 19:43 GMT+01:00 Carl Poirier : >> Well, if I use all the libs as local pretties, using the fp-lib-table that >> has been tagged the same will work, won't it? Do we want to support mix and >> matching tags? >> >> On Wed, Dec 7, 2016 at 10:45 AM, Nick Østergaard wrote: >>> >>> Well, the issue os the fact that if a user has choosen (one way or the >>> other) to use all of the local libs he needs to update the fp-lib-table >>> manually. An option is to copy the renamed pretty fors to the old name as to >>> not generate errors for the user. >>> >>> >>> Den 07/12/2016 13.21 skrev "Carl Poirier" : >>> >>> The KIGITHUB variable leads to Github. For using the pretties locally, the >>> fp-lib-table.for-pretty has to be used instead, which is the one that's >>> included by default in the stable release. Anyway, as I had mentioned in >>> another thread very recently, the Github plugin is not even built in the >>> stable release so I don't know how users can get into trouble. >>> >>> Carl >>> >>> On Dec 7, 2016 1:45 AM, "Nick Østergaard" wrote: But this will not help if the user is using them locally. How is that supposed to be handled? 2016-12-07 0:46 GMT+01:00 Carl Poirier : > Hi Nick, > > I do understand but it is not an issue, Just try it out, go to > https://github.com/KiCad/Buttons_Switches_ThroughHole.pretty. > > Carl > > On Tue, Dec 6, 2016 at 5:12 PM, Nick Østergaard > wrote: >> >> Hi Carl >> >> I have found an issue with the lib tagging. I think we decided to not >> remove any libs for the patch releaes. That is for releases where only >> the third number changes. What I see is: >> >> Buttons_Switches_ThroughHole.pretty remaned to >> Buttons_Switches_THT.pretty >> Capacitors_ThroughHole.pretty renamed to Capacitors_THT.pretty >> Connect.pretty renamed to Connectors.pretty >> Terminal_Blocks.pretty renamed to Connectors_Terminal_Blocks.pretty >> Sockets_WAGO734.pretty renamed to Connectors_WAGO.pretty >> Diodes_ThroughHole.pretty renamed to Diodes_THT.pretty >> Display.pretty renamed to Displays.pretty >> Relays_ThroughHole.pretty renamed to Relays_THT.pretty >> Resistors_ThroughHole.pretty renamed to Resistors_THT.pretty >> Sockets_BNC.pretty removed? >> Sockets_Mini-Universal.pretty renamed to >> Connectors_Mini-Universal.pretty >> >> Won't users have to manually update their fp-lib-table? >> >> Repos not tagged, Connectors_Amphenol.pretty Battery_Holders.pretty . >> This looks correct, so that is ok. >> >> The fp-lib-table.for-pretty seems to match the repos tagged. >> >> Those renamed repos will easily summon errors in the users face. I >> hope you understand what I mean. >> >> 2016-12-03 22:54 GMT+01:00 Carl Poirier : >>> I will be tagging the libs in 24h. >>> >>> Carl >>> >>> On Sat, Dec 3, 2016 at 3:00 PM, Adam Wolf >>> >>> wrote: I'll take a look early this week! On Sat, Dec 3, 2016 at 10:09 AM, Wayne Stambaugh wrote: > > Better late than never. I just pushed the 4.0.5 stable release. > Just > a > note to the package devs, you no longer need to set the version > string > at config. You can use KICAD_VERSION_EXTRA to append any package > specific information to the "4.0.5" version string. This will > also > hold > true when building from the source archive when I make the > official >
Re: [Kicad-developers] Release 4.0.5 tagged.
Yes, but lets use the windows use case. A user has 4.0.4 intalled and have fp-lib-table that matches the one used there for local libs. He then uninstalls 4.0.4 and install 4.0.5 (this would be the same as an update with a package manager and possibly osx too), the fp-lib-table is a user preference and will now reference non existing pretty dirs. The user starts pcbnew or cvpcb to add parts and when kicad tries to access one of those libs that do not exist anymore he gets "unexpected" errors. All I ask about is really; what is the desired action? I am ok with just including the rename, but I remember that at some time we said that we should not remove libs for patch releases. This would require a mention in the release note, which is probably also acceptable. 2016-12-07 19:43 GMT+01:00 Carl Poirier : > Well, if I use all the libs as local pretties, using the fp-lib-table that > has been tagged the same will work, won't it? Do we want to support mix and > matching tags? > > On Wed, Dec 7, 2016 at 10:45 AM, Nick Østergaard wrote: >> >> Well, the issue os the fact that if a user has choosen (one way or the >> other) to use all of the local libs he needs to update the fp-lib-table >> manually. An option is to copy the renamed pretty fors to the old name as to >> not generate errors for the user. >> >> >> Den 07/12/2016 13.21 skrev "Carl Poirier" : >> >> The KIGITHUB variable leads to Github. For using the pretties locally, the >> fp-lib-table.for-pretty has to be used instead, which is the one that's >> included by default in the stable release. Anyway, as I had mentioned in >> another thread very recently, the Github plugin is not even built in the >> stable release so I don't know how users can get into trouble. >> >> Carl >> >> On Dec 7, 2016 1:45 AM, "Nick Østergaard" wrote: >>> >>> But this will not help if the user is using them locally. How is that >>> supposed to be handled? >>> >>> 2016-12-07 0:46 GMT+01:00 Carl Poirier : >>> > Hi Nick, >>> > >>> > I do understand but it is not an issue, Just try it out, go to >>> > https://github.com/KiCad/Buttons_Switches_ThroughHole.pretty. >>> > >>> > Carl >>> > >>> > On Tue, Dec 6, 2016 at 5:12 PM, Nick Østergaard >>> > wrote: >>> >> >>> >> Hi Carl >>> >> >>> >> I have found an issue with the lib tagging. I think we decided to not >>> >> remove any libs for the patch releaes. That is for releases where only >>> >> the third number changes. What I see is: >>> >> >>> >> Buttons_Switches_ThroughHole.pretty remaned to >>> >> Buttons_Switches_THT.pretty >>> >> Capacitors_ThroughHole.pretty renamed to Capacitors_THT.pretty >>> >> Connect.pretty renamed to Connectors.pretty >>> >> Terminal_Blocks.pretty renamed to Connectors_Terminal_Blocks.pretty >>> >> Sockets_WAGO734.pretty renamed to Connectors_WAGO.pretty >>> >> Diodes_ThroughHole.pretty renamed to Diodes_THT.pretty >>> >> Display.pretty renamed to Displays.pretty >>> >> Relays_ThroughHole.pretty renamed to Relays_THT.pretty >>> >> Resistors_ThroughHole.pretty renamed to Resistors_THT.pretty >>> >> Sockets_BNC.pretty removed? >>> >> Sockets_Mini-Universal.pretty renamed to >>> >> Connectors_Mini-Universal.pretty >>> >> >>> >> Won't users have to manually update their fp-lib-table? >>> >> >>> >> Repos not tagged, Connectors_Amphenol.pretty Battery_Holders.pretty . >>> >> This looks correct, so that is ok. >>> >> >>> >> The fp-lib-table.for-pretty seems to match the repos tagged. >>> >> >>> >> Those renamed repos will easily summon errors in the users face. I >>> >> hope you understand what I mean. >>> >> >>> >> 2016-12-03 22:54 GMT+01:00 Carl Poirier : >>> >> > I will be tagging the libs in 24h. >>> >> > >>> >> > Carl >>> >> > >>> >> > On Sat, Dec 3, 2016 at 3:00 PM, Adam Wolf >>> >> > >>> >> > wrote: >>> >> >> >>> >> >> I'll take a look early this week! >>> >> >> >>> >> >> On Sat, Dec 3, 2016 at 10:09 AM, Wayne Stambaugh >>> >> >> >>> >> >> wrote: >>> >> >>> >>> >> >>> Better late than never. I just pushed the 4.0.5 stable release. >>> >> >>> Just >>> >> >>> a >>> >> >>> note to the package devs, you no longer need to set the version >>> >> >>> string >>> >> >>> at config. You can use KICAD_VERSION_EXTRA to append any package >>> >> >>> specific information to the "4.0.5" version string. This will >>> >> >>> also >>> >> >>> hold >>> >> >>> true when building from the source archive when I make the >>> >> >>> official >>> >> >>> announcement. Hopefully it wont take more than a week or two to >>> >> >>> get >>> >> >>> get >>> >> >>> documentation, libraries, and most of the packages ready. Please >>> >> >>> let >>> >> >>> me >>> >> >>> know so I can plan the release announcement. Thank you everyone >>> >> >>> for >>> >> >>> you >>> >> >>> efforts. >>> >> >>> >>> >> >>> Cheers, >>> >> >>> >>> >> >>> Wayne >>> >> >>> >>> >> >>> ___ >>> >> >>> Mailing list: https://launchpad.net/~kicad-developers >>> >> >>> Post to : kicad-developers@lists.launchpad.net >>>
Re: [Kicad-developers] Release 4.0.5 tagged.
Well, if I use all the libs as local pretties, using the fp-lib-table that has been tagged the same will work, won't it? Do we want to support mix and matching tags? On Wed, Dec 7, 2016 at 10:45 AM, Nick Østergaard wrote: > Well, the issue os the fact that if a user has choosen (one way or the > other) to use all of the local libs he needs to update the fp-lib-table > manually. An option is to copy the renamed pretty fors to the old name as > to not generate errors for the user. > > Den 07/12/2016 13.21 skrev "Carl Poirier" : > > The KIGITHUB variable leads to Github. For using the pretties locally, the > fp-lib-table.for-pretty has to be used instead, which is the one that's > included by default in the stable release. Anyway, as I had mentioned in > another thread very recently, the Github plugin is not even built in the > stable release so I don't know how users can get into trouble. > > Carl > > On Dec 7, 2016 1:45 AM, "Nick Østergaard" wrote: > >> But this will not help if the user is using them locally. How is that >> supposed to be handled? >> >> 2016-12-07 <20%2016%2012%2007> 0:46 GMT+01:00 Carl Poirier < >> carl.poirie...@gmail.com>: >> > Hi Nick, >> > >> > I do understand but it is not an issue, Just try it out, go to >> > https://github.com/KiCad/Buttons_Switches_ThroughHole.pretty. >> > >> > Carl >> > >> > On Tue, Dec 6, 2016 at 5:12 PM, Nick Østergaard >> wrote: >> >> >> >> Hi Carl >> >> >> >> I have found an issue with the lib tagging. I think we decided to not >> >> remove any libs for the patch releaes. That is for releases where only >> >> the third number changes. What I see is: >> >> >> >> Buttons_Switches_ThroughHole.pretty remaned to >> Buttons_Switches_THT.pretty >> >> Capacitors_ThroughHole.pretty renamed to Capacitors_THT.pretty >> >> Connect.pretty renamed to Connectors.pretty >> >> Terminal_Blocks.pretty renamed to Connectors_Terminal_Blocks.pretty >> >> Sockets_WAGO734.pretty renamed to Connectors_WAGO.pretty >> >> Diodes_ThroughHole.pretty renamed to Diodes_THT.pretty >> >> Display.pretty renamed to Displays.pretty >> >> Relays_ThroughHole.pretty renamed to Relays_THT.pretty >> >> Resistors_ThroughHole.pretty renamed to Resistors_THT.pretty >> >> Sockets_BNC.pretty removed? >> >> Sockets_Mini-Universal.pretty renamed to Connectors_Mini-Universal.pret >> ty >> >> >> >> Won't users have to manually update their fp-lib-table? >> >> >> >> Repos not tagged, Connectors_Amphenol.pretty Battery_Holders.pretty . >> >> This looks correct, so that is ok. >> >> >> >> The fp-lib-table.for-pretty seems to match the repos tagged. >> >> >> >> Those renamed repos will easily summon errors in the users face. I >> >> hope you understand what I mean. >> >> >> >> 2016-12-03 22:54 GMT+01:00 Carl Poirier : >> >> > I will be tagging the libs in 24h. >> >> > >> >> > Carl >> >> > >> >> > On Sat, Dec 3, 2016 at 3:00 PM, Adam Wolf >> >> > >> >> > wrote: >> >> >> >> >> >> I'll take a look early this week! >> >> >> >> >> >> On Sat, Dec 3, 2016 at 10:09 AM, Wayne Stambaugh < >> stambau...@gmail.com> >> >> >> wrote: >> >> >>> >> >> >>> Better late than never. I just pushed the 4.0.5 stable release. >> Just >> >> >>> a >> >> >>> note to the package devs, you no longer need to set the version >> string >> >> >>> at config. You can use KICAD_VERSION_EXTRA to append any package >> >> >>> specific information to the "4.0.5" version string. This will also >> >> >>> hold >> >> >>> true when building from the source archive when I make the official >> >> >>> announcement. Hopefully it wont take more than a week or two to >> get >> >> >>> get >> >> >>> documentation, libraries, and most of the packages ready. Please >> let >> >> >>> me >> >> >>> know so I can plan the release announcement. Thank you everyone >> for >> >> >>> you >> >> >>> efforts. >> >> >>> >> >> >>> Cheers, >> >> >>> >> >> >>> Wayne >> >> >>> >> >> >>> ___ >> >> >>> Mailing list: https://launchpad.net/~kicad-developers >> >> >>> Post to : kicad-developers@lists.launchpad.net >> >> >>> Unsubscribe : https://launchpad.net/~kicad-developers >> >> >>> More help : https://help.launchpad.net/ListHelp >> >> >> >> >> >> >> >> >> >> >> >> ___ >> >> >> Mailing list: https://launchpad.net/~kicad-developers >> >> >> Post to : kicad-developers@lists.launchpad.net >> >> >> Unsubscribe : https://launchpad.net/~kicad-developers >> >> >> More help : https://help.launchpad.net/ListHelp >> >> >> >> >> > >> >> > >> >> > ___ >> >> > Mailing list: https://launchpad.net/~kicad-developers >> >> > Post to : kicad-developers@lists.launchpad.net >> >> > Unsubscribe : https://launchpad.net/~kicad-developers >> >> > More help : https://help.launchpad.net/ListHelp >> >> > >> > >> > >> > > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@l
Re: [Kicad-developers] [RFC] [PATCH] simple C++ tests
This is what I was looking for. Thank you for taking the extra effort to figure this out. Cheers, Wayne On 12/7/2016 1:38 PM, Michael Steinberg wrote: > Hello, > > sorry for the noise, yes, the test cases can themselves be organized > into suites inside the test-executable with Boost.Test (Test-trees so to > say), so we're free to build a gazillion of executables per module or > collect them inside one executable and add a CTest-test for each suite > which is then run with the corresponding runtime arguments instead. We > could use this functionality also for other things. Orson pointed out > that having multiple executables will help speeding things up in case of > distributed parallel builds. > In any case reorganizing stuff will be rather painless due to all the > freedoms. Since I'm seeing it all only from the viewpoint of a developer > people running build machines should have the last word to say, how to > set it up so it blends in nicely. > > Cheers! > Michael > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [RFC] [PATCH] simple C++ tests
On 12/7/2016 1:05 PM, Michael Steinberg wrote: > Hello Wayne, and others too of course! > >> I'm fine with copying the binaries to a single directory. It's not very >> elegant but it's probably the path of least resistance. I'm surprised >> cmake doesn't have a way to temporarily add build libs for testing >> purposes. Maybe they do and I'm just not aware of it. Please make sure >> you add any necessary hooks to clean up the shared test directory to the >> cmake config so as not to leave a bunch of orphaned binaries laying >> around. > > CMake makes it easy to customize the output build directory per target > or shared. That was the most help I was expecting really. If we set a > variable this way, we build to a shared directory, otherwise we don't. > The build system will then figure out if that means to only copy the > stuff from the intermediate build directories, or a full rebuild is > necessary. Also see the last paragraph. > >> I would like finer test granularity as well. It would also be nice if >> tests could be grouped so that you could run say all of the tests on >> libcommon as a group or each individual test within the libcommon group. >> I don't know if boost::unit_test supports this but if it does that >> would be a good thing to implement. > I think we need to differ here on which level the granularity is > intended to be. There's the CTest-level that works on "command" > granularity. The executables themselves are linked to Boost.test, so you > can specify which tests to run inside the executable as well. > CTest granularity could then be multiple executables: > "libcommon.string", "libcommon.foo", "libcommon.bar". It could as well > mean one executable but multiple runs of the same test-executable with > different command line arguments. > I will investigate which if any possibilities there are to define suites > per one executable in Boost.Test, or if test cases are the broadest > thing there, just to get the picture complete. I only want to mention > that CTest and Boost.Test are more or less complementing each other > rather than doing the same thing and there's space to find the best > combination for us. > > I originally intended to actually build kicad into a shared directory on > windows in development and test configurations (no need to run an extra > install if they're directly built into a destination environment, so it > helps the development cycle as well). So it would probably be a (c)make > clean operation to purge the build in this case. What are the benefits > of rather copying them around in a custom build step, since that seems > so natural to you that you take it as given? In the end, I don't care how it is handled but `make clean` should clean up the test binaries as well. If it's handled automatically by cmake, all the better. If not, then you will have add cmake code to clean up the test code. > > Michael > > PS: Sorry that the citing is not perfect, I copied from multiple sources. > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [RFC] [PATCH] simple C++ tests
Hello, sorry for the noise, yes, the test cases can themselves be organized into suites inside the test-executable with Boost.Test (Test-trees so to say), so we're free to build a gazillion of executables per module or collect them inside one executable and add a CTest-test for each suite which is then run with the corresponding runtime arguments instead. We could use this functionality also for other things. Orson pointed out that having multiple executables will help speeding things up in case of distributed parallel builds. In any case reorganizing stuff will be rather painless due to all the freedoms. Since I'm seeing it all only from the viewpoint of a developer people running build machines should have the last word to say, how to set it up so it blends in nicely. Cheers! Michael ___ 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] [PATCH] simple C++ tests
Hello Wayne, and others too of course! I'm fine with copying the binaries to a single directory. It's not very elegant but it's probably the path of least resistance. I'm surprised cmake doesn't have a way to temporarily add build libs for testing purposes. Maybe they do and I'm just not aware of it. Please make sure you add any necessary hooks to clean up the shared test directory to the cmake config so as not to leave a bunch of orphaned binaries laying around. CMake makes it easy to customize the output build directory per target or shared. That was the most help I was expecting really. If we set a variable this way, we build to a shared directory, otherwise we don't. The build system will then figure out if that means to only copy the stuff from the intermediate build directories, or a full rebuild is necessary. Also see the last paragraph. I would like finer test granularity as well. It would also be nice if tests could be grouped so that you could run say all of the tests on libcommon as a group or each individual test within the libcommon group. I don't know if boost::unit_test supports this but if it does that would be a good thing to implement. I think we need to differ here on which level the granularity is intended to be. There's the CTest-level that works on "command" granularity. The executables themselves are linked to Boost.test, so you can specify which tests to run inside the executable as well. CTest granularity could then be multiple executables: "libcommon.string", "libcommon.foo", "libcommon.bar". It could as well mean one executable but multiple runs of the same test-executable with different command line arguments. I will investigate which if any possibilities there are to define suites per one executable in Boost.Test, or if test cases are the broadest thing there, just to get the picture complete. I only want to mention that CTest and Boost.Test are more or less complementing each other rather than doing the same thing and there's space to find the best combination for us. I originally intended to actually build kicad into a shared directory on windows in development and test configurations (no need to run an extra install if they're directly built into a destination environment, so it helps the development cycle as well). So it would probably be a (c)make clean operation to purge the build in this case. What are the benefits of rather copying them around in a custom build step, since that seems so natural to you that you take it as given? Michael PS: Sorry that the citing is not perfect, I copied from multiple sources. ___ 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] Via Stitching
Hi Heikki,
Good catches, thank you for the report. Both issues should be already fixed.
Regards,
Orson
On 12/07/2016 01:11 PM, Heikki Pulkkinen wrote:
> Hi
>
> Yesterday I do some work with Via Stitching cleanup. Cleanup Tracks and
> Vias has been changed quite much past two weeks. I found that
> deleteDanglingTracks() does not work right. It does not remove whole
> dangling trace, just only end tracks. I think, that it does not know other
> tracks than end tracks, because they do not been removed instantly as they
> do before. And that loop is running only ones. I think, that It needs some
> kind of whole trace test. Just adding:
>
> /* keep iterating, because a track connected to the deleted
> track
> * now perhaps is not connected and should be deleted */
> tie( std::ignore, flag_erase ) = m_removed.insert( track );
> modified = true;
> item_erased = true;
> <--*
> }
> }
> } while( item_erased );
>
>
> make it for ever loop.
>
>
> Another conflict is comparison of via type:
>
> @@ -371,10 +383,15 @@ bool TRACKS_CLEANER::clean_vias()
>
> /* Important: these cleanups only do thru hole vias, they don't
> * (yet) handle high density interconnects */
> -if( via->GetViaType() != VIA_THROUGH )
> +if( via->GetViaType() == VIA_THROUGH )
> {
> modified |= remove_duplicates_of_via( via );
>
>
>
>
> Cheers
>
> Heikki
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] Release 4.0.5 tagged.
Well, the issue os the fact that if a user has choosen (one way or the other) to use all of the local libs he needs to update the fp-lib-table manually. An option is to copy the renamed pretty fors to the old name as to not generate errors for the user. Den 07/12/2016 13.21 skrev "Carl Poirier" : The KIGITHUB variable leads to Github. For using the pretties locally, the fp-lib-table.for-pretty has to be used instead, which is the one that's included by default in the stable release. Anyway, as I had mentioned in another thread very recently, the Github plugin is not even built in the stable release so I don't know how users can get into trouble. Carl On Dec 7, 2016 1:45 AM, "Nick Østergaard" wrote: > But this will not help if the user is using them locally. How is that > supposed to be handled? > > 2016-12-07 <20%2016%2012%2007> 0:46 GMT+01:00 Carl Poirier < > carl.poirie...@gmail.com>: > > Hi Nick, > > > > I do understand but it is not an issue, Just try it out, go to > > https://github.com/KiCad/Buttons_Switches_ThroughHole.pretty. > > > > Carl > > > > On Tue, Dec 6, 2016 at 5:12 PM, Nick Østergaard > wrote: > >> > >> Hi Carl > >> > >> I have found an issue with the lib tagging. I think we decided to not > >> remove any libs for the patch releaes. That is for releases where only > >> the third number changes. What I see is: > >> > >> Buttons_Switches_ThroughHole.pretty remaned to > Buttons_Switches_THT.pretty > >> Capacitors_ThroughHole.pretty renamed to Capacitors_THT.pretty > >> Connect.pretty renamed to Connectors.pretty > >> Terminal_Blocks.pretty renamed to Connectors_Terminal_Blocks.pretty > >> Sockets_WAGO734.pretty renamed to Connectors_WAGO.pretty > >> Diodes_ThroughHole.pretty renamed to Diodes_THT.pretty > >> Display.pretty renamed to Displays.pretty > >> Relays_ThroughHole.pretty renamed to Relays_THT.pretty > >> Resistors_ThroughHole.pretty renamed to Resistors_THT.pretty > >> Sockets_BNC.pretty removed? > >> Sockets_Mini-Universal.pretty renamed to Connectors_Mini-Universal.pret > ty > >> > >> Won't users have to manually update their fp-lib-table? > >> > >> Repos not tagged, Connectors_Amphenol.pretty Battery_Holders.pretty . > >> This looks correct, so that is ok. > >> > >> The fp-lib-table.for-pretty seems to match the repos tagged. > >> > >> Those renamed repos will easily summon errors in the users face. I > >> hope you understand what I mean. > >> > >> 2016-12-03 22:54 GMT+01:00 Carl Poirier : > >> > I will be tagging the libs in 24h. > >> > > >> > Carl > >> > > >> > On Sat, Dec 3, 2016 at 3:00 PM, Adam Wolf > >> > > >> > wrote: > >> >> > >> >> I'll take a look early this week! > >> >> > >> >> On Sat, Dec 3, 2016 at 10:09 AM, Wayne Stambaugh < > stambau...@gmail.com> > >> >> wrote: > >> >>> > >> >>> Better late than never. I just pushed the 4.0.5 stable release. > Just > >> >>> a > >> >>> note to the package devs, you no longer need to set the version > string > >> >>> at config. You can use KICAD_VERSION_EXTRA to append any package > >> >>> specific information to the "4.0.5" version string. This will also > >> >>> hold > >> >>> true when building from the source archive when I make the official > >> >>> announcement. Hopefully it wont take more than a week or two to get > >> >>> get > >> >>> documentation, libraries, and most of the packages ready. Please > let > >> >>> me > >> >>> know so I can plan the release announcement. Thank you everyone for > >> >>> you > >> >>> efforts. > >> >>> > >> >>> Cheers, > >> >>> > >> >>> Wayne > >> >>> > >> >>> ___ > >> >>> Mailing list: https://launchpad.net/~kicad-developers > >> >>> Post to : kicad-developers@lists.launchpad.net > >> >>> Unsubscribe : https://launchpad.net/~kicad-developers > >> >>> More help : https://help.launchpad.net/ListHelp > >> >> > >> >> > >> >> > >> >> ___ > >> >> Mailing list: https://launchpad.net/~kicad-developers > >> >> Post to : kicad-developers@lists.launchpad.net > >> >> Unsubscribe : https://launchpad.net/~kicad-developers > >> >> More help : https://help.launchpad.net/ListHelp > >> >> > >> > > >> > > >> > ___ > >> > Mailing list: https://launchpad.net/~kicad-developers > >> > Post to : kicad-developers@lists.launchpad.net > >> > Unsubscribe : https://launchpad.net/~kicad-developers > >> > More help : https://help.launchpad.net/ListHelp > >> > > > > > > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [RFC] [PATCH] simple C++ tests
On 12/7/2016 4:29 AM, Maciej Sumiński wrote: > Hi Michael, > > On 12/06/2016 05:35 PM, Michael Steinberg wrote: >> Hello, >> >> I played around a bit and settled on a quick&easy solution. For running >> the tests on windows binding to the shared libs is a problem with our >> default build, because we have separate output directories per target. >> Only after an install operation are they in one directory for proper >> library lookup. So I added an option to the kicad cmake script to output >> all targets to a single shared directory, this option is implicitly >> activated when unit tests are enabled on windows. It then also adds the >> boost.test dependency. > > It sounds ok, I do not know how else it could be solved on Windows, at > least to be able to easily set up automatic testing. > >> Everything else is just like I described in the last message: CTest can >> be used to run all the test executables, if you want boost.test >> verbosity, you can always run the tests from the command prompt. >> >> Problem left would then be, how we set up the test targets. My initial >> thought would be to have one target per lib/executable. All tests >> related to the common library would then be combined to the >> "common-test" target for example. > > I used to work with projects that had multiple small unit tests and it > was quite neat solution. Do you think it would be much harder to apply > the same rules here? If so, I would not mind having one-to-one relation > between targets and tests, especially that one can easily separate tests > using boost.test judging from the screenshot you posted. I would like finer test granularity as well. It would also be nice if tests could be grouped so that you could run say all of the tests on libcommon as a group or each individual test within the libcommon group. I don't know if boost::unit_test supports this but if it does that would be a good thing to implement. > > Regards, > Orson > >> Here's a screenshot for the targets, RUN_TESTS (CTest) output, >> boost.test output and the shared stage dir: >> https://s17.postimg.org/p5ktjhoe5/kicad_unit_tests.png >> >> Am I making any sense? I might not be aware of all the things you expect >> from this. >> >> Michael >> >> >> ___ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : kicad-developers@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp > > > > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [RFC] [PATCH] simple C++ tests
On 12/6/2016 11:35 AM, Michael Steinberg wrote: > Hello, > > I played around a bit and settled on a quick&easy solution. For running > the tests on windows binding to the shared libs is a problem with our > default build, because we have separate output directories per target. > Only after an install operation are they in one directory for proper > library lookup. So I added an option to the kicad cmake script to output > all targets to a single shared directory, this option is implicitly > activated when unit tests are enabled on windows. It then also adds the > boost.test dependency. I'm fine with copying the binaries to a single directory. It's not very elegant but it's probably the path of least resistance. I'm surprised cmake doesn't have a way to temporarily add build libs for testing purposes. Maybe they do and I'm just not aware of it. Please make sure you add any necessary hooks to clean up the shared test directory to the cmake config so as not to leave a bunch of orphaned binaries laying around. > Everything else is just like I described in the last message: CTest can > be used to run all the test executables, if you want boost.test > verbosity, you can always run the tests from the command prompt. > > Problem left would then be, how we set up the test targets. My initial > thought would be to have one target per lib/executable. All tests > related to the common library would then be combined to the > "common-test" target for example. > > Here's a screenshot for the targets, RUN_TESTS (CTest) output, > boost.test output and the shared stage dir: > https://s17.postimg.org/p5ktjhoe5/kicad_unit_tests.png > > Am I making any sense? I might not be aware of all the things you expect > from this. > > Michael > > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Release 4.0.5 tagged.
Hi, On Wed, Dec 07, 2016 at 07:21:32AM -0500, Carl Poirier wrote: > The KIGITHUB variable leads to Github. For using the pretties locally, the > fp-lib-table.for-pretty has to be used instead, which is the one that's > included by default in the stable release. Anyway, as I had mentioned in > another thread very recently, the Github plugin is not even built in the > stable release so I don't know how users can get into trouble. The main reason we don't build it in Debian is the OpenSSL dependency, which is technically a violation of our own licence terms. If the package is linked against libcurl-gnutls and the OpenSSL init code removed, it would be fine to ship. 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] Release 4.0.5 tagged.
The KIGITHUB variable leads to Github. For using the pretties locally, the fp-lib-table.for-pretty has to be used instead, which is the one that's included by default in the stable release. Anyway, as I had mentioned in another thread very recently, the Github plugin is not even built in the stable release so I don't know how users can get into trouble. Carl On Dec 7, 2016 1:45 AM, "Nick Østergaard" wrote: > But this will not help if the user is using them locally. How is that > supposed to be handled? > > 2016-12-07 0:46 GMT+01:00 Carl Poirier : > > Hi Nick, > > > > I do understand but it is not an issue, Just try it out, go to > > https://github.com/KiCad/Buttons_Switches_ThroughHole.pretty. > > > > Carl > > > > On Tue, Dec 6, 2016 at 5:12 PM, Nick Østergaard > wrote: > >> > >> Hi Carl > >> > >> I have found an issue with the lib tagging. I think we decided to not > >> remove any libs for the patch releaes. That is for releases where only > >> the third number changes. What I see is: > >> > >> Buttons_Switches_ThroughHole.pretty remaned to > Buttons_Switches_THT.pretty > >> Capacitors_ThroughHole.pretty renamed to Capacitors_THT.pretty > >> Connect.pretty renamed to Connectors.pretty > >> Terminal_Blocks.pretty renamed to Connectors_Terminal_Blocks.pretty > >> Sockets_WAGO734.pretty renamed to Connectors_WAGO.pretty > >> Diodes_ThroughHole.pretty renamed to Diodes_THT.pretty > >> Display.pretty renamed to Displays.pretty > >> Relays_ThroughHole.pretty renamed to Relays_THT.pretty > >> Resistors_ThroughHole.pretty renamed to Resistors_THT.pretty > >> Sockets_BNC.pretty removed? > >> Sockets_Mini-Universal.pretty renamed to Connectors_Mini-Universal.pret > ty > >> > >> Won't users have to manually update their fp-lib-table? > >> > >> Repos not tagged, Connectors_Amphenol.pretty Battery_Holders.pretty . > >> This looks correct, so that is ok. > >> > >> The fp-lib-table.for-pretty seems to match the repos tagged. > >> > >> Those renamed repos will easily summon errors in the users face. I > >> hope you understand what I mean. > >> > >> 2016-12-03 22:54 GMT+01:00 Carl Poirier : > >> > I will be tagging the libs in 24h. > >> > > >> > Carl > >> > > >> > On Sat, Dec 3, 2016 at 3:00 PM, Adam Wolf > >> > > >> > wrote: > >> >> > >> >> I'll take a look early this week! > >> >> > >> >> On Sat, Dec 3, 2016 at 10:09 AM, Wayne Stambaugh < > stambau...@gmail.com> > >> >> wrote: > >> >>> > >> >>> Better late than never. I just pushed the 4.0.5 stable release. > Just > >> >>> a > >> >>> note to the package devs, you no longer need to set the version > string > >> >>> at config. You can use KICAD_VERSION_EXTRA to append any package > >> >>> specific information to the "4.0.5" version string. This will also > >> >>> hold > >> >>> true when building from the source archive when I make the official > >> >>> announcement. Hopefully it wont take more than a week or two to get > >> >>> get > >> >>> documentation, libraries, and most of the packages ready. Please > let > >> >>> me > >> >>> know so I can plan the release announcement. Thank you everyone for > >> >>> you > >> >>> efforts. > >> >>> > >> >>> Cheers, > >> >>> > >> >>> Wayne > >> >>> > >> >>> ___ > >> >>> Mailing list: https://launchpad.net/~kicad-developers > >> >>> Post to : kicad-developers@lists.launchpad.net > >> >>> Unsubscribe : https://launchpad.net/~kicad-developers > >> >>> More help : https://help.launchpad.net/ListHelp > >> >> > >> >> > >> >> > >> >> ___ > >> >> Mailing list: https://launchpad.net/~kicad-developers > >> >> Post to : kicad-developers@lists.launchpad.net > >> >> Unsubscribe : https://launchpad.net/~kicad-developers > >> >> More help : https://help.launchpad.net/ListHelp > >> >> > >> > > >> > > >> > ___ > >> > Mailing list: https://launchpad.net/~kicad-developers > >> > Post to : kicad-developers@lists.launchpad.net > >> > Unsubscribe : https://launchpad.net/~kicad-developers > >> > More help : https://help.launchpad.net/ListHelp > >> > > > > > > ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [RFC] [PATCH] simple C++ tests
On 12/07/2016 10:55 AM, Maciej Sumiński wrote: > On 12/07/2016 10:35 AM, Michael Steinberg wrote: >> Hello Orson, >> >> >> Am 07.12.2016 um 10:29 schrieb Maciej Sumiński: >>> I used to work with projects that had multiple small unit tests and it >>> was quite neat solution. Do you think it would be much harder to apply >>> the same rules here? If so, I would not mind having one-to-one relation >>> between targets and tests, especially that one can easily separate tests >>> using boost.test judging from the screenshot you posted. >>> >>> Regards, >>> Orson >> That would absolutely be possible, my intention avoiding that on the >> first shot was only that I feared having a full executable link process >> per test/test case might be a bit troublesome in the long run. Did you >> have no problems with that, how many tests were there, did it slow down >> the build process at all? No matter how many test targets we produce, >> CTest will only ever say "passed" or "not passed" for each without any >> further information of what is the cause, if I'm not completely mistaken. >> >> Michael > > Linking against a shared library (e.g. _pcbnew.kiface) should be quick. > Tom has been testing a similar approach [1], though without using CTest, > but it shows the idea. > > CTest is able to give extra information once a build fails [2]. > Apparently whatever approach we choose we will have more or less the > same information available. I do not really see any exceptional benefit > of one method over the other, so IMHO we can go with whatever is easier > to set up. > > Regards, > Orson > > 1. > https://github.com/twlostow/kicad-dev/commit/bec46081ea3bf0e2862615fc6040a86beda5785f > 2. https://cmake.org/cmake/help/v2.8.8/ctest.html#opt%3a--output-on-failure One thing worth checking is whether boost.test continues tests after a test fails. Full report is a valuable information, sometimes I was able to tell what went wrong without launching gdb, but simply by looking at a list of failed tests. Regards, Orson 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] [RFC] [PATCH] simple C++ tests
On 12/07/2016 10:35 AM, Michael Steinberg wrote: > Hello Orson, > > > Am 07.12.2016 um 10:29 schrieb Maciej Sumiński: >> I used to work with projects that had multiple small unit tests and it >> was quite neat solution. Do you think it would be much harder to apply >> the same rules here? If so, I would not mind having one-to-one relation >> between targets and tests, especially that one can easily separate tests >> using boost.test judging from the screenshot you posted. >> >> Regards, >> Orson > That would absolutely be possible, my intention avoiding that on the > first shot was only that I feared having a full executable link process > per test/test case might be a bit troublesome in the long run. Did you > have no problems with that, how many tests were there, did it slow down > the build process at all? No matter how many test targets we produce, > CTest will only ever say "passed" or "not passed" for each without any > further information of what is the cause, if I'm not completely mistaken. > > Michael Linking against a shared library (e.g. _pcbnew.kiface) should be quick. Tom has been testing a similar approach [1], though without using CTest, but it shows the idea. CTest is able to give extra information once a build fails [2]. Apparently whatever approach we choose we will have more or less the same information available. I do not really see any exceptional benefit of one method over the other, so IMHO we can go with whatever is easier to set up. Regards, Orson 1. https://github.com/twlostow/kicad-dev/commit/bec46081ea3bf0e2862615fc6040a86beda5785f 2. https://cmake.org/cmake/help/v2.8.8/ctest.html#opt%3a--output-on-failure 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] [RFC] [PATCH] simple C++ tests
Hello Orson, Am 07.12.2016 um 10:29 schrieb Maciej Sumiński: I used to work with projects that had multiple small unit tests and it was quite neat solution. Do you think it would be much harder to apply the same rules here? If so, I would not mind having one-to-one relation between targets and tests, especially that one can easily separate tests using boost.test judging from the screenshot you posted. Regards, Orson That would absolutely be possible, my intention avoiding that on the first shot was only that I feared having a full executable link process per test/test case might be a bit troublesome in the long run. Did you have no problems with that, how many tests were there, did it slow down the build process at all? No matter how many test targets we produce, CTest will only ever say "passed" or "not passed" for each without any further information of what is the cause, if I'm not completely mistaken. Michael ___ 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] [PATCH] simple C++ tests
Hi Michael, On 12/06/2016 05:35 PM, Michael Steinberg wrote: > Hello, > > I played around a bit and settled on a quick&easy solution. For running > the tests on windows binding to the shared libs is a problem with our > default build, because we have separate output directories per target. > Only after an install operation are they in one directory for proper > library lookup. So I added an option to the kicad cmake script to output > all targets to a single shared directory, this option is implicitly > activated when unit tests are enabled on windows. It then also adds the > boost.test dependency. It sounds ok, I do not know how else it could be solved on Windows, at least to be able to easily set up automatic testing. > Everything else is just like I described in the last message: CTest can > be used to run all the test executables, if you want boost.test > verbosity, you can always run the tests from the command prompt. > > Problem left would then be, how we set up the test targets. My initial > thought would be to have one target per lib/executable. All tests > related to the common library would then be combined to the > "common-test" target for example. I used to work with projects that had multiple small unit tests and it was quite neat solution. Do you think it would be much harder to apply the same rules here? If so, I would not mind having one-to-one relation between targets and tests, especially that one can easily separate tests using boost.test judging from the screenshot you posted. Regards, Orson > Here's a screenshot for the targets, RUN_TESTS (CTest) output, > boost.test output and the shared stage dir: > https://s17.postimg.org/p5ktjhoe5/kicad_unit_tests.png > > Am I making any sense? I might not be aware of all the things you expect > from this. > > Michael > > > ___ > 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 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
