Re: [Kicad-developers] [PATCH] Produce generated files in CMAKE_BINARY_DIR rather than in-source

Hmm. Folks, I don't necessarily have time to test this at the moment, with the RC testing I'm doing, but if this works ok, it might be better than a few workarounds I put in place for the OS X builds. Adam Wolf On Sun, Sep 13, 2015 at 11:26 PM, Michael Beardsworth < beardswo...@google.com>

Re: [Kicad-developers] [PATCH] Produce generated files in CMAKE_BINARY_DIR rather than in-source

Adam, Are you not able to build out of source builds on OSX? I've never done an in source built on either windows or linux so I'm a bit surprised by this statement. AFAICT, this patch merely moves the source files generated by CMake from the source path to the build path. Do any of these files

Re: [Kicad-developers] [PATCH] Fixed a False BZR Version Number Built From Local Branch of GIT-Source-Mirror

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:

Re: [Kicad-developers] [PATCH] Fixed a False BZR Version Number Built From Local Branch of GIT-Source-Mirror

I rolled back the changes so all should be well now. That's the beauty of using version control. On 9/14/2015 1:35 AM, Nick Østergaard wrote: > I was not able to reproduce the problem in my checkout, but I guess if > I remove the origin remote I should be able to now. But I am not sure > what is

Re: [Kicad-developers] comments and questions on SEARCH_STACK

On 9/13/2015 11:31 PM, Cirilo Bernardo wrote: > Hi folks, > > I was just looking into how KiCad currently handles partial paths for > files and I have found: > > (a) 3D model paths are now resolved exclusively via the KISYS3DMOD > environment variable > > (b) kiface_i.cpp contains what appears

Re: [Kicad-developers] [PATCH] Produce generated files in CMAKE_BINARY_DIR rather than in-source

I had forgotten about the upcoming dependency changes. The builds work fine, but I have some special scripts that make sure that the build tree is "really really clean", as I've had some troubles before with things being left over, and having it so that I just had a single "build artifacts"

[Kicad-developers] [PATCH] Fix assertion failure on attempt to orient a selected label

SCH_EDIT_FRAME::OnOrient uses SCH_COLLECTOR to filter for only orientable items. The problem is that it only does this for an unselected item. If the item is returned by SCH_SCREEN::GetCurItem it'll skip that part and go ahead trying to orient it. Then an assertion failure "Schematic object

Re: [Kicad-developers] comments and questions on SEARCH_STACK

Hi, moreover it seems that $KIPRJMOD variable is not understood when changing a path in 3D model selection that has already that value configured (Footprint Properties, 3D settings, 3D shape name) It would be also useful to use/insert '$KIPRJMOD' variable when choosing relative path.

Re: [Kicad-developers] Build failed in Jenkins: kicad-noscript-fedora20 #686

Please ignore this. 2015-09-14 1:34 GMT+02:00 Miguel Angel Ajo : > See > > -- > Started by upstream project "kicad-full" build number 801 > originally caused by: > Started by an

[Kicad-developers] Build failed in Jenkins: kicad-noscript-fedora20 #686

See -- Started by upstream project "kicad-full" build number 801 originally caused by: Started by an SCM change Started by upstream project "kicad-full" build number 802 originally caused by:

Re: [Kicad-developers] Can I move values in footprints library back to silkscreen?

W dniu 14.09.2015 o 08:41, Lorenzo Marcantonio pisze: On Sun, Sep 13, 2015 at 08:09:26PM -0400, Carl Poirier wrote: Could the plot values checkbox be fixed easily? Since it's a "fix" I suggest it for integration in 4.0. I'm against this modification, since it's bloat for a single use case. Me

[Kicad-developers] BOX2::SetMaximum()

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

Re: [Kicad-developers] comments and questions on SEARCH_STACK

On 9/14/2015 10:29 AM, ea...@katamail.com wrote: > Hi, > moreover it seems that $KIPRJMOD variable is not understood when > changing a path in 3D model selection that has already that value > configured > (Footprint Properties, 3D settings, 3D shape name) Are you saying using

Re: [Kicad-developers] [PATCH] Fix assertion failure on attempt to orient a selected label

On 9/14/2015 1:03 PM, Chris Pavlina wrote: > Well, you're welcome to try to find a non-hackish way to ensure that OnOrient > is not called for nonorientable objects even when the user has selected one. > I failed to do so. > > Why should that be a failure, anyway? It's not illegal to attempt to

Re: [Kicad-developers] [PATCH] Fix assertion failure on attempt to orient a selected label

This should probably be a wxASSERT rather than a wxFAIL_MSG so in release builds it would not fail. The assertion was put there so that who ever wrote the code that allowed objects that cannot be oriented to be passed to OnOrient would get a reminder of there error. I would prefer that OnOrient

Re: [Kicad-developers] [PATCH] Fix assertion failure on attempt to orient a selected label

Well, you're welcome to try to find a non-hackish way to ensure that OnOrient is not called for nonorientable objects even when the user has selected one. I failed to do so. Why should that be a failure, anyway? It's not illegal to attempt to orient a non-orientable object. I can still press Y

Re: [Kicad-developers] [PATCH] Fix assertion failure on attempt to orient a selected label

How about leaving the assert rather than the fail in there as a reminder to developers in case it gets lost in the noise (which these things tend to do). It will compile away on release builds which is the desired behavior. On 9/14/2015 1:35 PM, Chris Pavlina wrote: > Oh, indeed. It's begging to

Re: [Kicad-developers] comments and questions on SEARCH_STACK

2015-09-14 19:05 GMT+02:00 Wayne Stambaugh : > On 9/14/2015 10:29 AM, ea...@katamail.com wrote: >> Hi, >> moreover it seems that $KIPRJMOD variable is not understood when >> changing a path in 3D model selection that has already that value >> configured >> (Footprint

Re: [Kicad-developers] [PATCH] Fixed a False BZR Version Number Built From Local Branch of GIT-Source-Mirror

On 9/13/2015 11:40 PM, Joseph Chen wrote: > @Wayne, > > In case of emergency, you can reverse my previous patch by applying the > attached patch. It will revert to the clean state as before for the > single file of CreateGitVersionHearder.cmake. > > I am embarrassed that the previous patch

Re: [Kicad-developers] BOX2::SetMaximum()

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

Re: [Kicad-developers] [PATCH] Fix assertion failure on attempt to orient a selected label

Oh, indeed. It's begging to be refactored. But as it stands, kicad crashes (well, throws up a dialog asking the user if they would like it to crash ;) if you press X or Y whilst holding a label. I hoped to get at least _that_ fixed before the release, because that's quite broken. On Mon, Sep

Re: [Kicad-developers] [PATCH] Produce generated files in CMAKE_BINARY_DIR rather than in-source

Michael, If you have been following this thread with Adam's comments, you've seen that your patch doesn't address the 800 pound gorilla in the room that is the dependency library build stuff (namely boost and wxwidgets) that nullifies the usefulness of your patch. That being said, your patch

Re: [Kicad-developers] Version 4 stable branch rc1 released.

It would be nice if we had .deb packages for debian and related systems :3. On Mon, Sep 14, 2015 at 5:50 PM, Ian Woloschin wrote: > I believe I have a working set of ebuilds for Gentoo/Funtoo, located here: > > https://github.com/iwoloschin/overlay > > I've split KiCad

Re: [Kicad-developers] Version 4 stable branch rc1 released.

I believe I have a working set of ebuilds for Gentoo/Funtoo, located here: https://github.com/iwoloschin/overlay I've split KiCad (binaries) and kicad-libraries (components & footprints) into two separate ebuilds, though I'm not sure it's necessary. I've done very minimal testing at this point,

Re: [Kicad-developers] Version 4 stable branch rc1 released.

Mark, Isn't that what's in the reynauld PPA? On Sep 14, 2015 4:54 PM, "Mark Roszko" wrote: > It would be nice if we had .deb packages for debian and related systems > :3. > > On Mon, Sep 14, 2015 at 5:50 PM, Ian Woloschin wrote: > > I believe I have

Re: [Kicad-developers] Version 4 stable branch rc1 released.

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

Re: [Kicad-developers] comments and questions on SEARCH_STACK

On Mon, Sep 14, 2015 at 11:47 PM, Wayne Stambaugh wrote: > On 9/13/2015 11:31 PM, Cirilo Bernardo wrote: > > Hi folks, > > > > I was just looking into how KiCad currently handles partial paths for > > files and I have found: > > > > (a) 3D model paths are now resolved

Re: [Kicad-developers] Eeschema ERC should detect unmatched local labels

@JP, Attached you can find the patch file for the improvement of optional ERC's detecting local labels. Short description: With this patch, there is an added extra check box inside ERC pop-up window, which by default is "un-checked". This extra check box has a name "Check

Re: [Kicad-developers] Block select settings

On 09/13/2015 10:45 PM, bob smith wrote: > Hi, > > Possibly working on a feature, just wanted to bounce my ideas off you guys. > > The basic idea is as follows: > > As you block select footprints/symbols, the settings dialog shows the > settings that are common to all of the selected

Re: [Kicad-developers] [PATCH] Fix assertion failure on attempt to orient a selected label

Well, personally, I don't like it - as developers looking for things to refactor aren't the only people who use debug builds. But I also see your point about not wanting it to get lost in the noise, and I'm not sure how else to manage that. I really think we ought to have a proper place to

Re: [Kicad-developers] Can I move values in footprints library back to silkscreen?

On Mon, Sep 14, 2015 at 05:49:16PM +0200, nnn wrote: > and lack of layers for reference designators. If values must stay on > F.Fab/B.Fab, what about adding %R (scaled, centered, outlined) on They don't *have* to stay on Fab, it's only a library convention. You can put them (almost) on any layer,

Re: [Kicad-developers] Can I move values in footprints library back to silkscreen?

Ok but my question is if I can move values from fab to silks (hidden) as they were before in all pretty repos (and change convention) and use Fab layers as assembly layers (as in IPC7351) to provide users ready to use assembly layer with reference designators. I hoped that some discussion here

Re: [Kicad-developers] comments and questions on SEARCH_STACK

2015-09-14 19:56 GMT+02:00 Wayne Stambaugh : > On 9/14/2015 1:41 PM, Nick Østergaard wrote: >> 2015-09-14 19:05 GMT+02:00 Wayne Stambaugh : >>> On 9/14/2015 10:29 AM, ea...@katamail.com wrote: Hi, moreover it seems that $KIPRJMOD variable is

Re: [Kicad-developers] Version 4 stable branch rc1 released.

A dedicated PPA is available for kicad V4 branch: ppa:js-reynaud/kicad-4 Regards, Le 13/09/2015 17:37, Wayne Stambaugh a écrit : > The libraries and documentation are maintained separately from the > source. For now I would just use a snapshot of the current libraries > and docs. As part of

Re: [Kicad-developers] Can I move values in footprints library back to silkscreen?

On Sun, Sep 13, 2015 at 08:09:26PM -0400, Carl Poirier wrote: > Could the plot values checkbox be fixed easily? Since it's a "fix" I > suggest it for integration in 4.0. I'm against this modification, since it's bloat for a single use case. Multiplotting can be done with scripting, by the way.

Re: [Kicad-developers] Eeschema ERC should detect unmatched local labels

Le 14/09/2015 06:17, Joseph Chen a écrit : > @Wayne and @JP, > > Could try ERC on this simple schematic file? > > Attached, you can find a test schematic file that has an unintended > unmatched local labels, and current kicad ERC does not detect them. > > In the test schematic file, there is a