Re: [Kicad-developers] Rev 6350, abs vs std::abs

[Wayne Stambaugh]

JP,

Please add  to math_for_graphic.cpp to see if it resolves the
issue?  It does look a bit odd using both abs() and std::abs() in the
same source file.

Thanks,

Wayne

On 12/7/2015 8:28 AM, Chris Pavlina wrote:
> It is indeed difficult to test an issue that doesn't appear on your computer, 
> but from a quick look around, it looks like the correct way is to leave 
> std::abs, but add #include . Unlike stdlib.h, cstdlib defines 
> overloads for all the integer widths, reducing the possibility of a bad 
> mistake when using it with something longer than an int:
> 
> http://www.cplusplus.com/reference/cstdlib/abs/
> 
> Perhaps an oversight on my part not to have included that in the first place. 
> Maybe you could give that a try? The usage would be much more obvious then.
> 
> 
> On Mon, Dec 07, 2015 at 02:17:19PM +0100, jp charras wrote:
>> Le 07/12/2015 13:51, Chris Pavlina a écrit :
>>> Mostly directed at JP:
>>>
>>> Back in June, I went through and changed a few 'weird' things we were 
>>> doing, including using C abs instead of C++ std::abs:
>>>
>>> http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/revision/5831
>>>
>>> You just changed it back:
>>>
>>> http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/revision/6350
>>>
>>> What compiler could possibly have an issue with that? std::abs is, for very 
>>> good reason, the preferred way to find absolute value in C++. As such, if 
>>> there is some obscure reason we need to use abs(), would it kill you to 
>>> leave some explanation behind so nobody else also gets confused by that? A 
>>> real explanation in the commit message would be extremely helpful, as 
>>> possibly would a comment in the vicinity of the intentionally nonstandard 
>>> code.
>>>
>>> --
>>> Chris
>>
>>
>> std::abs is preferable to std, and I had no issue on my computer.
>> It is not so easy to fix an issue (using std::abs with integers,
>> std::abs used with floats did not created issues) which does not appears
>> on your computer.
>>
>> But here is my reason:
>>
>>> See 
>>>
>>> Changes:
>>>
>>> [jean-pierre charras] Kicad manager: fix a potential bug which could crash 
>>> Kicad manager. math_for_graphics.cpp: remove useless includes.
>>>
>>> --
>>> Started by an SCM change
>>> Building on master in workspace 
>>> $ bzr revision-info -d 
>>> info result: bzr revision-info -d 
>>>  returned 0. Command output: 
>>> "6348 jp.char...@wanadoo.fr-20151207092209-7rby34qymt287ho6
>>> " stderr: ""
>>> [kicad-full] $ bzr pull --overwrite lp:kicad
>>> You have not informed bzr of your Launchpad ID, and you must do this to
>>> write to Launchpad or access private data.  See "bzr help launchpad-login".
>>> http://bazaar.launchpad.net/~kicad-product-committers/kicad/product is 
>>> permanently redirected to 
>>> http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/changes
>>> You have not informed bzr of your Launchpad ID, and you must do this to
>>> write to Launchpad or access private data.  See "bzr help launchpad-login".
>>>  M  kicad/class_treeproject_item.cpp
>>>  M  polygon/math_for_graphics.cpp
>>> All changes applied successfully.
>>> Now on revision 6349.
>>> [kicad-full] $ bzr revert
>>> $ bzr revision-info -d 
>>> info result: bzr revision-info -d 
>>>  returned 0. Command output: 
>>> "6349 jp.char...@wanadoo.fr-20151207092431-90sr06sy0jhwwg2f
>>> " stderr: ""
>>> [kicad-full] $ bzr log -v -r 
>>> revid:jp.char...@wanadoo.fr-20151207092209-7rby34qymt287ho6..revid:jp.char...@wanadoo.fr-20151207092431-90sr06sy0jhwwg2f
>>>  --long --show-ids
>>> Getting local revision...
>>> $ bzr revision-info -d 
>>> info result: bzr revision-info -d 
>>>  returned 0. Command output: 
>>> "6349 jp.char...@wanadoo.fr-20151207092431-90sr06sy0jhwwg2f
>>> " stderr: ""
>>> RevisionState revno:6349 
>>> revid:jp.char...@wanadoo.fr-20151207092431-90sr06sy0jhwwg2f
>>> [kicad-full] $ /bin/sh -xe /tmp/hudson8903420887098700890.sh
>>> + OPTS=' -DCMAKE_BUILD_TYPE=Debug -DBUILD_GITHUB_PLUGIN=ON 
>>> -DKICAD_SCRIPTING=ON -DKICAD_SCRIPTING_MODULES=ON 
>>> -DKICAD_SCRIPTING_WXPYTHON=ON'
>>> + '[' -d build ']'
>>> + cd build
>>> + /usr/bin/cmake .. -DCMAKE_BUILD_TYPE=Debug -DBUILD_GITHUB_PLUGIN=ON 
>>> -DKICAD_SCRIPTING=ON -DKICAD_SCRIPTING_MODULES=ON 
>>> -DKICAD_SCRIPTING_WXPYTHON=ON
>>> -- Kicad install dir: 
>>> -- Check for installed OpenGL -- found
>>> -- Found Glew: /usr/lib64/libGLEW.so
>>> -- Check for installed GLEW -- found
>>> -- Check for installed Cairo -- found
>>> -- Check for installed Python Interpreter -- found
>>> -- Python module install path: 

Re: [Kicad-developers] Rev 6350, abs vs std::abs

[jp charras]

Le 07/12/2015 14:28, Chris Pavlina a écrit :
> It is indeed difficult to test an issue that doesn't appear on your
> computer, but from a quick look around, it looks like the correct way
> is to leave std::abs, but add #include . Unlike stdlib.h,
> cstdlib defines overloads for all the integer widths, reducing the
> possibility of a bad mistake when using it with something longer than
> an int:
> 
> http://www.cplusplus.com/reference/cstdlib/abs/
> 
> Perhaps an oversight on my part not to have included that in the
> first place. Maybe you could give that a try? The usage would be much
> more obvious then.


Looks like including both cstdlib (for ints) and cmath (for floats) is
needed for std::abs.

Fixed now.

Thanks.


-- 
Jean-Pierre CHARRAS

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [patch] default kicad_common to environment variables

[Adam Wolf]

The test build is going now, will be done within 30 minutes.

Adam Wolf

On Mon, Dec 7, 2015 at 9:31 AM, Wayne Stambaugh 
wrote:

> Adam,
>
> I forgot to ask, do you want me to go ahead with this patch?
>
> Thanks,
>
> Wayne
>
> On 12/6/2015 7:13 PM, Adam Wolf wrote:
> > When are you planning on doing the 4.0.1 release? Todayish or in about 7
> > days?
> >
> > Adam Wolf
> >
> >
> > On Sun, Dec 6, 2015, 5:41 PM Wayne Stambaugh  > > wrote:
> >
> > On 12/6/2015 3:52 PM, Adam Wolf wrote:
> > > If it would help the installer, would it help if we ifdef OSX out,
> > and I
> > > test on OS X next week and we remove the ifdef?
> > >
> > > I am also relatively comfortable applying this on OS X without
> testing
> > > it.  I have been neck deep in that code over the last few weeks
> > because
> > > of the 3D modules work I was doing for OS X in prep for 4.0.0 and
> it
> > > looks OK to me.
> >
> > If your comfortable with it, I will commit it to the product branch
> and
> > merge it into the 4.0 branch for the 4.0.1 release.  Let me know if
> > that's what you want me to do.  This is one of the rare exceptions I
> > will make as far as back porting non-critical bugs.
> >
> > >
> > > Either way, I know I can test this early this week.
> > >
> > > Adam Wolf
> > >
> > > On Sun, Dec 6, 2015 at 2:48 PM, Nick Østergaard  > 
> > > >> wrote:
> > >
> > > I am very tempted to just apply this to the 4.0.0 windows
> > installer,
> > > just such that the libs will actually work when people install
> > them.
> > >
> > > Should I refrain from this?
> > >
> > > I have tested the patch on windows and linux. It works as
> > expected.
> > >
> > > 2015-12-04 15:21 GMT+01:00 Wayne Stambaugh
> > 
> > > >>:
> > > > Obviously this patch is only going to be useful for the
> > first time
> > > kicad
> > > > is run.  Existing installs will change.  I'm fine with
> > applying it
> > > once
> > > > it has been tested on OSX and Linux.  I'm at my bandwidth
> > limit so I'm
> > > > going to need some help with the testing.
> > > >
> > > > On 12/4/2015 9:08 AM, Mark Roszko wrote:
> > > >> 1. Users can install anywhere
> > > >> 2. x86 vs x64
> > > >>
> > > >> 32-bit on XP => Program Files
> > > >> 32-bit on 64-bit => Program Files (x86)
> > > >> 64 on 64-bit => Program Files
> > > >> 64 on the rare 64-bit XP => Program Files (x64)
> > > >>
> > > >> ___
> > > >> 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] Full integration to Github

[Mark Roszko]

So I did just a import of "open" issues from launchpad.
https://github.com/marekr/kicad-issue-test/issues?page=7=is%3Aissue+is%3Aopen

1. Github's API rate limiting is extreme, they trip on "abuse
detection" really really often so it took ~24 hours just to get 700
issues and only partial comments
2. I stopped it because I had people complaining github was spamming
them with notifications. This is because the @ mentions from launchpad
were being copied. You would think they would be smart enough to
disable notifications for API posted issues or make it an option to
silence it.





So what can I say:
1. Importing the entire set (open and closed) of issues would take a
very long time with the rate limiting. I would say all the closed
issues on LP are honestly useless and don't need to be moved as they
can stay archived there forever, god forbid anyone every needs to look
at one.
2. "Syncing" GH to LP open bugs would require a script/bot to keep
checking and posting comments between the two.





Personally what I would suggest:
1. We don't have to use github issues, it is an option to disable them.
2. There's always the option to self host our own bug tracker
separately from source control, with JIRA no longer melting the kicad
website server, perhaps something as simple as Trac could run on it?
Then you get a bug tracker that's arguably more user friendly than
launchpad and more fleshed out than github (they even calls their
lightweight so).
a. we can shove in a github login plugin :D
b. there's a plugin to sync launchpad to trac.




Otherwise, we can just import like I did and call it a day.

___
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] FindGLM script

[Wayne Stambaugh]

Orson,

I think the patch has been tested on all platforms so go ahead and
commit it if you comfortable with the changes.

Thanks,

Wayne

On 12/7/2015 7:38 AM, Maciej Sumiński wrote:
> Hi Cirilo,
> 
> Thank you for the FindGLM script. I had to modify it slightly, as it did
> not work with CMake 3.4.0 (problem with STREQUAL).
> 
> Here is complete patch [1], that I applied to KiCad in order to use the
> system glm library (0.9.7 in my case). If there are no problems with
> other platforms/library versions, I guess it might be committed.
> 
> Regards,
> Orson
> 
> 1. https://orson.net.pl/pub/glm.patch
> 
> On 12/06/2015 11:17 PM, Cirilo Bernardo wrote:
>> Thanks Bernhard,
>>
>>  I just checked on MSYS2 and it works as well. Can someone push the
>> FindGLM.cmake script on
>> google drive into the kicad/CMakeModules directory? I'll create a branch
>> later and see if there are
>> any issues encountered when I delete the glm source from the tree and use
>> find_package +
>> include-directories. Even if there are any issues to be resolved, with the
>> script installed Orson and
>> Tom should be able to move the GAL code to the external glm lib whenever
>> it's convenient.
>>
>> - Cirilo
>>
>>
>> On Mon, Dec 7, 2015 at 8:55 AM, Bernhard Stegmaier 
>> wrote:
>>
>>> … works fine on OS X with a MacPorts installed glm:
>>>
>>> bstegmaier$ cmake .
>>> -- The CXX compiler identification is AppleClang 7.0.0.7000176
>>> -- The C compiler identification is AppleClang 7.0.0.7000176
>>> -- Check for working CXX compiler:
>>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
>>> -- Check for working CXX compiler:
>>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
>>> -- works
>>> -- Detecting CXX compiler ABI info
>>> -- Detecting CXX compiler ABI info - done
>>> -- Detecting CXX compile features
>>> -- Detecting CXX compile features - done
>>> -- Check for working C compiler:
>>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
>>> -- Check for working C compiler:
>>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
>>> -- works
>>> -- Detecting C compiler ABI info
>>> -- Detecting C compiler ABI info - done
>>> -- Detecting C compile features
>>> -- Detecting C compile features - done
>>> -- Found GLM: /opt/local/include/glm (found suitable version "0.9.6.3",
>>> minimum required is "0.9.5.4")
>>> -- Configuring done
>>> -- Generating done
>>> -- Build files have been written to:
>>> /Volumes/OSXData/Users/bstegmaier/glm-test
>>>
>>>
>>> Regards,
>>> Bernhard
>>>
>>> On 06.12.2015, at 22:30, Cirilo Bernardo 
>>> wrote:
>>>
>>> I've written a FindGLM script to help with the effort to remove glm source
>>> code from
>>> the kicad tree.  This works on Linux (well, at least Debian) but needs
>>> some testing
>>> on MSYS2 and OSX. I believe this script is necessary because:
>>>
>>> 1. Different distributions are erratic in the inclusion of a FindGLM
>>> script or the
>>> newer glmConfig script.
>>> 2. All other versions of the FindGLM script which I have seen are
>>> defective -
>>> they do not support version checking.
>>> 3. The glmConfig script, even if it exists and is installed, is also
>>> defective
>>> since the version information is hard-coded into the CMakeLists.txt file
>>> which generates the glmConfig script rather than taking the values from the
>>> setup.hpp file.
>>> 4. This script should work for all known versions of glm from the 0.9.4
>>> version
>>> included in the kicad tree to the 0.9.8 development version.
>>>
>>>
>>> https://drive.google.com/folderview?id=0By_XTJN-s8aXel9BZjA2ZFlGckU=sharing
>>>
>>> - Cirilo
>>> ___
>>> 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] [patch] default kicad_common to environment variables

[Wayne Stambaugh]

Adam,

I forgot to ask, do you want me to go ahead with this patch?

Thanks,

Wayne

On 12/6/2015 7:13 PM, Adam Wolf wrote:
> When are you planning on doing the 4.0.1 release? Todayish or in about 7
> days?
> 
> Adam Wolf
> 
> 
> On Sun, Dec 6, 2015, 5:41 PM Wayne Stambaugh  > wrote:
> 
> On 12/6/2015 3:52 PM, Adam Wolf wrote:
> > If it would help the installer, would it help if we ifdef OSX out,
> and I
> > test on OS X next week and we remove the ifdef?
> >
> > I am also relatively comfortable applying this on OS X without testing
> > it.  I have been neck deep in that code over the last few weeks
> because
> > of the 3D modules work I was doing for OS X in prep for 4.0.0 and it
> > looks OK to me.
> 
> If your comfortable with it, I will commit it to the product branch and
> merge it into the 4.0 branch for the 4.0.1 release.  Let me know if
> that's what you want me to do.  This is one of the rare exceptions I
> will make as far as back porting non-critical bugs.
> 
> >
> > Either way, I know I can test this early this week.
> >
> > Adam Wolf
> >
> > On Sun, Dec 6, 2015 at 2:48 PM, Nick Østergaard  
> > >> wrote:
> >
> > I am very tempted to just apply this to the 4.0.0 windows
> installer,
> > just such that the libs will actually work when people install
> them.
> >
> > Should I refrain from this?
> >
> > I have tested the patch on windows and linux. It works as
> expected.
> >
> > 2015-12-04 15:21 GMT+01:00 Wayne Stambaugh
> 
> > >>:
> > > Obviously this patch is only going to be useful for the
> first time
> > kicad
> > > is run.  Existing installs will change.  I'm fine with
> applying it
> > once
> > > it has been tested on OSX and Linux.  I'm at my bandwidth
> limit so I'm
> > > going to need some help with the testing.
> > >
> > > On 12/4/2015 9:08 AM, Mark Roszko wrote:
> > >> 1. Users can install anywhere
> > >> 2. x86 vs x64
> > >>
> > >> 32-bit on XP => Program Files
> > >> 32-bit on 64-bit => Program Files (x86)
> > >> 64 on 64-bit => Program Files
> > >> 64 on the rare 64-bit XP => Program Files (x64)
> > >>
> > >> ___
> > >> 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] Rev 6350, abs vs std::abs

[Chris Pavlina]

It is indeed difficult to test an issue that doesn't appear on your computer, 
but from a quick look around, it looks like the correct way is to leave 
std::abs, but add #include . Unlike stdlib.h, cstdlib defines 
overloads for all the integer widths, reducing the possibility of a bad mistake 
when using it with something longer than an int:

http://www.cplusplus.com/reference/cstdlib/abs/

Perhaps an oversight on my part not to have included that in the first place. 
Maybe you could give that a try? The usage would be much more obvious then.


On Mon, Dec 07, 2015 at 02:17:19PM +0100, jp charras wrote:
> Le 07/12/2015 13:51, Chris Pavlina a écrit :
> > Mostly directed at JP:
> > 
> > Back in June, I went through and changed a few 'weird' things we were 
> > doing, including using C abs instead of C++ std::abs:
> > 
> > http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/revision/5831
> > 
> > You just changed it back:
> > 
> > http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/revision/6350
> > 
> > What compiler could possibly have an issue with that? std::abs is, for very 
> > good reason, the preferred way to find absolute value in C++. As such, if 
> > there is some obscure reason we need to use abs(), would it kill you to 
> > leave some explanation behind so nobody else also gets confused by that? A 
> > real explanation in the commit message would be extremely helpful, as 
> > possibly would a comment in the vicinity of the intentionally nonstandard 
> > code.
> > 
> > --
> > Chris
> 
> 
> std::abs is preferable to std, and I had no issue on my computer.
> It is not so easy to fix an issue (using std::abs with integers,
> std::abs used with floats did not created issues) which does not appears
> on your computer.
> 
> But here is my reason:
> 
> > See 
> > 
> > Changes:
> > 
> > [jean-pierre charras] Kicad manager: fix a potential bug which could crash 
> > Kicad manager. math_for_graphics.cpp: remove useless includes.
> > 
> > --
> > Started by an SCM change
> > Building on master in workspace 
> > $ bzr revision-info -d 
> > info result: bzr revision-info -d 
> >  returned 0. Command output: 
> > "6348 jp.char...@wanadoo.fr-20151207092209-7rby34qymt287ho6
> > " stderr: ""
> > [kicad-full] $ bzr pull --overwrite lp:kicad
> > You have not informed bzr of your Launchpad ID, and you must do this to
> > write to Launchpad or access private data.  See "bzr help launchpad-login".
> > http://bazaar.launchpad.net/~kicad-product-committers/kicad/product is 
> > permanently redirected to 
> > http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/changes
> > You have not informed bzr of your Launchpad ID, and you must do this to
> > write to Launchpad or access private data.  See "bzr help launchpad-login".
> >  M  kicad/class_treeproject_item.cpp
> >  M  polygon/math_for_graphics.cpp
> > All changes applied successfully.
> > Now on revision 6349.
> > [kicad-full] $ bzr revert
> > $ bzr revision-info -d 
> > info result: bzr revision-info -d 
> >  returned 0. Command output: 
> > "6349 jp.char...@wanadoo.fr-20151207092431-90sr06sy0jhwwg2f
> > " stderr: ""
> > [kicad-full] $ bzr log -v -r 
> > revid:jp.char...@wanadoo.fr-20151207092209-7rby34qymt287ho6..revid:jp.char...@wanadoo.fr-20151207092431-90sr06sy0jhwwg2f
> >  --long --show-ids
> > Getting local revision...
> > $ bzr revision-info -d 
> > info result: bzr revision-info -d 
> >  returned 0. Command output: 
> > "6349 jp.char...@wanadoo.fr-20151207092431-90sr06sy0jhwwg2f
> > " stderr: ""
> > RevisionState revno:6349 
> > revid:jp.char...@wanadoo.fr-20151207092431-90sr06sy0jhwwg2f
> > [kicad-full] $ /bin/sh -xe /tmp/hudson8903420887098700890.sh
> > + OPTS=' -DCMAKE_BUILD_TYPE=Debug -DBUILD_GITHUB_PLUGIN=ON 
> > -DKICAD_SCRIPTING=ON -DKICAD_SCRIPTING_MODULES=ON 
> > -DKICAD_SCRIPTING_WXPYTHON=ON'
> > + '[' -d build ']'
> > + cd build
> > + /usr/bin/cmake .. -DCMAKE_BUILD_TYPE=Debug -DBUILD_GITHUB_PLUGIN=ON 
> > -DKICAD_SCRIPTING=ON -DKICAD_SCRIPTING_MODULES=ON 
> > -DKICAD_SCRIPTING_WXPYTHON=ON
> > -- Kicad install dir: 
> > -- Check for installed OpenGL -- found
> > -- Found Glew: /usr/lib64/libGLEW.so
> > -- Check for installed GLEW -- found
> > -- Check for installed Cairo -- found
> > -- Check for installed Python Interpreter -- found
> > -- Python module install path: lib/python2.6/site-packages
> > -- wxPython version 3.0 found.
> > -- Configuring done
> > -- Generating done
> > -- Build files have been written to: 
> > 
> > + rm -f 

Re: [Kicad-developers] [patch] default kicad_common to environment variables

[Nick Østergaard]

I just noticed that on linux at least, that when I set KISYSMOD=/tmp
(nothing else)  I do get KISYSMOD=/tmp in the configure paths dialog,
good, but I have a KISYS3DMOD=/packages3d/tmp

That would be totally wrong. I did definitely not expect the tmp to be
appended after packages3d.

2015-12-07 16:36 GMT+01:00 Adam Wolf :
> The test build is going now, will be done within 30 minutes.
>
> Adam Wolf
>
> On Mon, Dec 7, 2015 at 9:31 AM, Wayne Stambaugh 
> wrote:
>>
>> Adam,
>>
>> I forgot to ask, do you want me to go ahead with this patch?
>>
>> Thanks,
>>
>> Wayne
>>
>> On 12/6/2015 7:13 PM, Adam Wolf wrote:
>> > When are you planning on doing the 4.0.1 release? Todayish or in about 7
>> > days?
>> >
>> > Adam Wolf
>> >
>> >
>> > On Sun, Dec 6, 2015, 5:41 PM Wayne Stambaugh > > > wrote:
>> >
>> > On 12/6/2015 3:52 PM, Adam Wolf wrote:
>> > > If it would help the installer, would it help if we ifdef OSX out,
>> > and I
>> > > test on OS X next week and we remove the ifdef?
>> > >
>> > > I am also relatively comfortable applying this on OS X without
>> > testing
>> > > it.  I have been neck deep in that code over the last few weeks
>> > because
>> > > of the 3D modules work I was doing for OS X in prep for 4.0.0 and
>> > it
>> > > looks OK to me.
>> >
>> > If your comfortable with it, I will commit it to the product branch
>> > and
>> > merge it into the 4.0 branch for the 4.0.1 release.  Let me know if
>> > that's what you want me to do.  This is one of the rare exceptions I
>> > will make as far as back porting non-critical bugs.
>> >
>> > >
>> > > Either way, I know I can test this early this week.
>> > >
>> > > Adam Wolf
>> > >
>> > > On Sun, Dec 6, 2015 at 2:48 PM, Nick Østergaard > > 
>> > > >> wrote:
>> > >
>> > > I am very tempted to just apply this to the 4.0.0 windows
>> > installer,
>> > > just such that the libs will actually work when people install
>> > them.
>> > >
>> > > Should I refrain from this?
>> > >
>> > > I have tested the patch on windows and linux. It works as
>> > expected.
>> > >
>> > > 2015-12-04 15:21 GMT+01:00 Wayne Stambaugh
>> > 
>> > > >>:
>> > > > Obviously this patch is only going to be useful for the
>> > first time
>> > > kicad
>> > > > is run.  Existing installs will change.  I'm fine with
>> > applying it
>> > > once
>> > > > it has been tested on OSX and Linux.  I'm at my bandwidth
>> > limit so I'm
>> > > > going to need some help with the testing.
>> > > >
>> > > > On 12/4/2015 9:08 AM, Mark Roszko wrote:
>> > > >> 1. Users can install anywhere
>> > > >> 2. x86 vs x64
>> > > >>
>> > > >> 32-bit on XP => Program Files
>> > > >> 32-bit on 64-bit => Program Files (x86)
>> > > >> 64 on 64-bit => Program Files
>> > > >> 64 on the rare 64-bit XP => Program Files (x64)
>> > > >>
>> > > >> ___
>> > > >> 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] Full integration to Github

[Eldar Khayrullin]

Hi.
Maybe one need to run script that add message to all open bugs in launchpad.
Message like that: If we want to add new message click to this link ...
Message consists link to another script that (or instruction how) check 
and if need
open new bug on Github with name copied from Launchpad and first message 
that

consist link to this issue and previous messages on launchpad.
One need to add block to any new bugs in launchpad now.

PS: I think that need to have all (code, bug tracker, pull request) in 
one place,

because they all related.

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [patch] default kicad_common to environment variables

[Adam Wolf]

To clarify, by "results", I mean "shows up in the path manager as".  I
wonder if we're doing something later, hmm.

Adam Wolf

On Mon, Dec 7, 2015 at 11:09 AM, Adam Wolf 
wrote:

> It works fine on OS X.
>
> I found a weirdess with AppendDir, however, that I don't think should hold
> this patch up, but I want to mention on the list.
>
> If tmpfilename is set to something like "helloworld",
>
> tmpFileName.AppendDir( wxT( "packages3d" ) );
>
> results in "packages3d/helloworld", which is not what I expected.  If you
> add slashes, however, and set  tmpFileName to "/helloworld/",
>
> tmpFileName.AppendDir( wxT( "packages3d" ) );
>
> results in "/helloworld/packages3d".
>
> *sigh*
>
> Adam Wolf
>
>
> On Mon, Dec 7, 2015 at 9:36 AM, Adam Wolf 
> wrote:
>
>> The test build is going now, will be done within 30 minutes.
>>
>> Adam Wolf
>>
>> On Mon, Dec 7, 2015 at 9:31 AM, Wayne Stambaugh 
>> wrote:
>>
>>> Adam,
>>>
>>> I forgot to ask, do you want me to go ahead with this patch?
>>>
>>> Thanks,
>>>
>>> Wayne
>>>
>>> On 12/6/2015 7:13 PM, Adam Wolf wrote:
>>> > When are you planning on doing the 4.0.1 release? Todayish or in about
>>> 7
>>> > days?
>>> >
>>> > Adam Wolf
>>> >
>>> >
>>> > On Sun, Dec 6, 2015, 5:41 PM Wayne Stambaugh >> > > wrote:
>>> >
>>> > On 12/6/2015 3:52 PM, Adam Wolf wrote:
>>> > > If it would help the installer, would it help if we ifdef OSX
>>> out,
>>> > and I
>>> > > test on OS X next week and we remove the ifdef?
>>> > >
>>> > > I am also relatively comfortable applying this on OS X without
>>> testing
>>> > > it.  I have been neck deep in that code over the last few weeks
>>> > because
>>> > > of the 3D modules work I was doing for OS X in prep for 4.0.0
>>> and it
>>> > > looks OK to me.
>>> >
>>> > If your comfortable with it, I will commit it to the product
>>> branch and
>>> > merge it into the 4.0 branch for the 4.0.1 release.  Let me know if
>>> > that's what you want me to do.  This is one of the rare exceptions
>>> I
>>> > will make as far as back porting non-critical bugs.
>>> >
>>> > >
>>> > > Either way, I know I can test this early this week.
>>> > >
>>> > > Adam Wolf
>>> > >
>>> > > On Sun, Dec 6, 2015 at 2:48 PM, Nick Østergaard <
>>> oe.n...@gmail.com
>>> > 
>>> > > >> wrote:
>>> > >
>>> > > I am very tempted to just apply this to the 4.0.0 windows
>>> > installer,
>>> > > just such that the libs will actually work when people
>>> install
>>> > them.
>>> > >
>>> > > Should I refrain from this?
>>> > >
>>> > > I have tested the patch on windows and linux. It works as
>>> > expected.
>>> > >
>>> > > 2015-12-04 15:21 GMT+01:00 Wayne Stambaugh
>>> > 
>>> > > >> >>>:
>>> > > > Obviously this patch is only going to be useful for the
>>> > first time
>>> > > kicad
>>> > > > is run.  Existing installs will change.  I'm fine with
>>> > applying it
>>> > > once
>>> > > > it has been tested on OSX and Linux.  I'm at my bandwidth
>>> > limit so I'm
>>> > > > going to need some help with the testing.
>>> > > >
>>> > > > On 12/4/2015 9:08 AM, Mark Roszko wrote:
>>> > > >> 1. Users can install anywhere
>>> > > >> 2. x86 vs x64
>>> > > >>
>>> > > >> 32-bit on XP => Program Files
>>> > > >> 32-bit on 64-bit => Program Files (x86)
>>> > > >> 64 on 64-bit => Program Files
>>> > > >> 64 on the rare 64-bit XP => Program Files (x64)
>>> > > >>
>>> > > >> ___
>>> > > >> 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 : 

Re: [Kicad-developers] [patch] default kicad_common to environment variables

[Adam Wolf]

It works fine on OS X.

I found a weirdess with AppendDir, however, that I don't think should hold
this patch up, but I want to mention on the list.

If tmpfilename is set to something like "helloworld",

tmpFileName.AppendDir( wxT( "packages3d" ) );

results in "packages3d/helloworld", which is not what I expected.  If you
add slashes, however, and set  tmpFileName to "/helloworld/",

tmpFileName.AppendDir( wxT( "packages3d" ) );

results in "/helloworld/packages3d".

*sigh*

Adam Wolf


On Mon, Dec 7, 2015 at 9:36 AM, Adam Wolf 
wrote:

> The test build is going now, will be done within 30 minutes.
>
> Adam Wolf
>
> On Mon, Dec 7, 2015 at 9:31 AM, Wayne Stambaugh 
> wrote:
>
>> Adam,
>>
>> I forgot to ask, do you want me to go ahead with this patch?
>>
>> Thanks,
>>
>> Wayne
>>
>> On 12/6/2015 7:13 PM, Adam Wolf wrote:
>> > When are you planning on doing the 4.0.1 release? Todayish or in about 7
>> > days?
>> >
>> > Adam Wolf
>> >
>> >
>> > On Sun, Dec 6, 2015, 5:41 PM Wayne Stambaugh > > > wrote:
>> >
>> > On 12/6/2015 3:52 PM, Adam Wolf wrote:
>> > > If it would help the installer, would it help if we ifdef OSX out,
>> > and I
>> > > test on OS X next week and we remove the ifdef?
>> > >
>> > > I am also relatively comfortable applying this on OS X without
>> testing
>> > > it.  I have been neck deep in that code over the last few weeks
>> > because
>> > > of the 3D modules work I was doing for OS X in prep for 4.0.0 and
>> it
>> > > looks OK to me.
>> >
>> > If your comfortable with it, I will commit it to the product branch
>> and
>> > merge it into the 4.0 branch for the 4.0.1 release.  Let me know if
>> > that's what you want me to do.  This is one of the rare exceptions I
>> > will make as far as back porting non-critical bugs.
>> >
>> > >
>> > > Either way, I know I can test this early this week.
>> > >
>> > > Adam Wolf
>> > >
>> > > On Sun, Dec 6, 2015 at 2:48 PM, Nick Østergaard <
>> oe.n...@gmail.com
>> > 
>> > > >> wrote:
>> > >
>> > > I am very tempted to just apply this to the 4.0.0 windows
>> > installer,
>> > > just such that the libs will actually work when people install
>> > them.
>> > >
>> > > Should I refrain from this?
>> > >
>> > > I have tested the patch on windows and linux. It works as
>> > expected.
>> > >
>> > > 2015-12-04 15:21 GMT+01:00 Wayne Stambaugh
>> > 
>> > > >>:
>> > > > Obviously this patch is only going to be useful for the
>> > first time
>> > > kicad
>> > > > is run.  Existing installs will change.  I'm fine with
>> > applying it
>> > > once
>> > > > it has been tested on OSX and Linux.  I'm at my bandwidth
>> > limit so I'm
>> > > > going to need some help with the testing.
>> > > >
>> > > > On 12/4/2015 9:08 AM, Mark Roszko wrote:
>> > > >> 1. Users can install anywhere
>> > > >> 2. x86 vs x64
>> > > >>
>> > > >> 32-bit on XP => Program Files
>> > > >> 32-bit on 64-bit => Program Files (x86)
>> > > >> 64 on 64-bit => Program Files
>> > > >> 64 on the rare 64-bit XP => Program Files (x64)
>> > > >>
>> > > >> ___
>> > > >> 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
>> > 
>> > > 

Re: [Kicad-developers] [patch] default kicad_common to environment variables

[Nick Østergaard]

Yes, I noticed that too. :)

2015-12-07 18:14 GMT+01:00 Adam Wolf :
> To clarify, by "results", I mean "shows up in the path manager as".  I
> wonder if we're doing something later, hmm.
>
> Adam Wolf
>
> On Mon, Dec 7, 2015 at 11:09 AM, Adam Wolf 
> wrote:
>>
>> It works fine on OS X.
>>
>> I found a weirdess with AppendDir, however, that I don't think should hold
>> this patch up, but I want to mention on the list.
>>
>> If tmpfilename is set to something like "helloworld",
>>
>> tmpFileName.AppendDir( wxT( "packages3d" ) );
>>
>> results in "packages3d/helloworld", which is not what I expected.  If you
>> add slashes, however, and set  tmpFileName to "/helloworld/",
>>
>> tmpFileName.AppendDir( wxT( "packages3d" ) );
>>
>> results in "/helloworld/packages3d".
>>
>> *sigh*
>>
>> Adam Wolf
>>
>>
>> On Mon, Dec 7, 2015 at 9:36 AM, Adam Wolf 
>> wrote:
>>>
>>> The test build is going now, will be done within 30 minutes.
>>>
>>> Adam Wolf
>>>
>>> On Mon, Dec 7, 2015 at 9:31 AM, Wayne Stambaugh 
>>> wrote:

 Adam,

 I forgot to ask, do you want me to go ahead with this patch?

 Thanks,

 Wayne

 On 12/6/2015 7:13 PM, Adam Wolf wrote:
 > When are you planning on doing the 4.0.1 release? Todayish or in about
 > 7
 > days?
 >
 > Adam Wolf
 >
 >
 > On Sun, Dec 6, 2015, 5:41 PM Wayne Stambaugh  > wrote:
 >
 > On 12/6/2015 3:52 PM, Adam Wolf wrote:
 > > If it would help the installer, would it help if we ifdef OSX
 > out,
 > and I
 > > test on OS X next week and we remove the ifdef?
 > >
 > > I am also relatively comfortable applying this on OS X without
 > testing
 > > it.  I have been neck deep in that code over the last few weeks
 > because
 > > of the 3D modules work I was doing for OS X in prep for 4.0.0
 > and it
 > > looks OK to me.
 >
 > If your comfortable with it, I will commit it to the product
 > branch and
 > merge it into the 4.0 branch for the 4.0.1 release.  Let me know
 > if
 > that's what you want me to do.  This is one of the rare exceptions
 > I
 > will make as far as back porting non-critical bugs.
 >
 > >
 > > Either way, I know I can test this early this week.
 > >
 > > Adam Wolf
 > >
 > > On Sun, Dec 6, 2015 at 2:48 PM, Nick Østergaard
 >  
 > > >> wrote:
 > >
 > > I am very tempted to just apply this to the 4.0.0 windows
 > installer,
 > > just such that the libs will actually work when people
 > install
 > them.
 > >
 > > Should I refrain from this?
 > >
 > > I have tested the patch on windows and linux. It works as
 > expected.
 > >
 > > 2015-12-04 15:21 GMT+01:00 Wayne Stambaugh
 > 
 > >  >>:
 > > > Obviously this patch is only going to be useful for the
 > first time
 > > kicad
 > > > is run.  Existing installs will change.  I'm fine with
 > applying it
 > > once
 > > > it has been tested on OSX and Linux.  I'm at my bandwidth
 > limit so I'm
 > > > going to need some help with the testing.
 > > >
 > > > On 12/4/2015 9:08 AM, Mark Roszko wrote:
 > > >> 1. Users can install anywhere
 > > >> 2. x86 vs x64
 > > >>
 > > >> 32-bit on XP => Program Files
 > > >> 32-bit on 64-bit => Program Files (x86)
 > > >> 64 on 64-bit => Program Files
 > > >> 64 on the rare 64-bit XP => Program Files (x64)
 > > >>
 > > >> ___
 > > >> 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] PATCH: bugfix for IDF export

[Cirilo Bernardo]

The attached patch fixes the following bugs in the IDF export:

1. incorrect orientation of components on the bottom side of the board
when the #D model rotation is non-zero

2. failure to export when some components have no model set

- Cirilo
=== modified file 'pcbnew/exporters/export_idf.cpp'
--- pcbnew/exporters/export_idf.cpp	2015-08-23 21:37:01 +
+++ pcbnew/exporters/export_idf.cpp	2015-12-07 07:14:38 +
@@ -376,7 +376,8 @@
 
 for( S3D_MASTER* modfile = aModule->Models(); modfile != 0; modfile = modfile->Next() )
 {
-if( !modfile->Is3DType( S3D_MASTER::FILE3D_IDF ) )
+if( !modfile->Is3DType( S3D_MASTER::FILE3D_IDF )
+|| modfile->GetShape3DFullFilename().empty() )
 continue;
 
 if( refdes.empty() )
@@ -408,7 +409,6 @@
 
 if( top )
 {
-rotz += modfile->m_MatRotation.z;
 locy = -locy;
 RotatePoint( , , aModule->GetOrientation() );
 locy = -locy;
@@ -416,6 +416,7 @@
 
 if( !top )
 {
+lrot = -lrot;
 RotatePoint( , , aModule->GetOrientation() );
 locy = -locy;
 

___
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] ancient autorouter code

[jp charras]

Le 07/12/2015 06:13, Henner Zeller a écrit :
> On 6 December 2015 at 20:58, Adam Wolf  wrote:
>> I believe that there was integration done so that if you click the
>> autorouter button, it tells you in the status bar to put the jar in a
>> certain path, at which point the button works like it did before--actually,
>> a little better, because for some reason Java remembers the path and I don't
>> need to browse to the project every time I open it up.
> 
> That would indeed be good, as the file browser is pretty annoying that way.
> 
> Sounds like documentation would be good somewhere. Does anyone know
> how this is supposed to work ?
> (I recently had a small throwaway board where I didn't mind a crappy
> autorouter result).
> 
> -h
> 
>>
>> I don't remember when this was but this was after the online service went
>> down.
>>
>> Adam Wolf
>>
>> On Sun, Dec 6, 2015 at 5:04 PM, Henner Zeller  wrote:
>>>
>>> On 31 July 2015 at 08:47, Wayne Stambaugh  wrote:
 I'm confused, are we talking about the freerouting.net link or KiCad's
 internal autorouter?  If the link to freerouting.net is still active, it
 should be removed from KiCad since it is no longer active.  I thought
 this was removed already.
>>>
>>> I had a look: the freeroute program still exists, but it is now a GNU
>>> licenced code out there ( https://github.com/nikropht/FreeRouting ) -
>>> it is possible to run as standalone on your computer.
>>>
>>> From what it looks like, there was an online version available that
>>> doesn't exist anymore, so the button 'Export ... and launch Freeroute'
>>> should probably be removed (or the FreeRouting program hacked so that
>>> it can run as a daemon listening on a socket for a local network
>>> service).
>>>
>>> So for Kicad
>>>   - remove the middle button in the Free-Route dialog that sends it to
>>> the external router
>>>  - The menu button 'Freeroute' should be renamed 'External routing
>>> (Specctra export)' or something, so that it is more neutral.

In Freeroute dialog, the middle button is enabled when the file
freeroute.jar is found in paths known by Kicad (in kicad bin files).

Since a long time it does not use the on-line version (roughly since it
was removed).

When clicking on it, the Freeroute is launched (if Java exists, of
course) and loads the right .dsn file.
There is no reason to remove this button.
You just have to copy freeroute.jar to your PC, where Kicad binaries are.

A separate Specctra export button already exists, always enabled.

>>>
>>> -h
 On 7/31/2015 10:51 AM, Al Thomason wrote:
> Is this still the link to: http://www.freerouting.net/  ?
>
> If so, there was some CnD letters as well as perhaps other problems for
> the
> author - in the end, this resource has been taken off-line.  See above
> URL
> for more details.
>
> -al-
>
>
> -Original Message-
> From: Kicad-developers
>
> [mailto:kicad-developers-bounces+thomason.al=gmail@lists.launchpad.net]
> On Behalf Of Wayne Stambaugh
> Sent: Friday, July 31, 2015 5:36 AM
> To: kicad-developers@lists.launchpad.net
> Subject: Re: [Kicad-developers] ancient autorouter code
>
> I haven't used the autorouter in a long time but it should still
> function
> properly despite it's limited usefulness.  I see no reason to remove it
> for
> the stable release unless it is completely broken.  For some really
> simple
> boards it still may be useful.
>
> On 7/30/2015 8:52 PM, Cirilo Bernardo wrote:
>> As long as I can remember the docs have mentioned a built-in
>> autorouter.
>> For just as long I've never been aware of anyone using it or improving
>> the code. Could we kill this before a stable release?
>>
>> - Cirilo


-- 
Jean-Pierre CHARRAS

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] PATCH: bugfix for IDF export

[jp charras]

Le 07/12/2015 09:07, Cirilo Bernardo a écrit :
> The attached patch fixes the following bugs in the IDF export:
> 
> 1. incorrect orientation of components on the bottom side of the board
> when the #D model rotation is non-zero
> 
> 2. failure to export when some components have no model set
> 
> - Cirilo
> 

Committed. Thanks.


-- 
Jean-Pierre CHARRAS

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Jenkins build is back to normal : KiCad (Linux, all options, Debug) #948

[Miguel Angel Ajo]

See 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [patch] default kicad_common to environment variables

[Nick Østergaard]

2015-12-06 23:01 GMT+01:00 Wayne Stambaugh :
> On 12/6/2015 3:48 PM, Nick Østergaard wrote:
>> I am very tempted to just apply this to the 4.0.0 windows installer,
>> just such that the libs will actually work when people install them.
>>
>> Should I refrain from this?
>
> Please hold off.  I would rather not have the windows 4.0.0 package use
> different code than the Linux and OSX 4.0.0 packages.  I hope to role
> out at 4.0.1 release with the GAL crash fix in the next couple of days.
>  I was trying to get it done today but it just didn't happen.  I can
> include this patch as well as long as it doesn't break anything.
>
>>
>> I have tested the patch on windows and linux. It works as expected.
>
> Did you delete all of your old kicad config files and do a "clean" install?

I am not exactly sure what a "clean" install has anything to do with
the default conf. The use case is just to have it set to working paths
when a user installs KiCad. So it was tested by not having a clean
conf to see if it kept the paths and then close kicad, remove the
conf, and start kicad (pcbnew) to verify that the paths were changed.

>>
>> 2015-12-04 15:21 GMT+01:00 Wayne Stambaugh :
>>> Obviously this patch is only going to be useful for the first time kicad
>>> is run.  Existing installs will change.  I'm fine with applying it once
>>> it has been tested on OSX and Linux.  I'm at my bandwidth limit so I'm
>>> going to need some help with the testing.
>>>
>>> On 12/4/2015 9:08 AM, Mark Roszko wrote:
 1. Users can install anywhere
 2. x86 vs x64

 32-bit on XP => Program Files
 32-bit on 64-bit => Program Files (x86)
 64 on 64-bit => Program Files
 64 on the rare 64-bit XP => Program Files (x64)

 ___
 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

[Kicad-developers] Build failed in Jenkins: KiCad (Linux, all options, Debug) #947

[Miguel Angel Ajo]

See 

Changes:

[jean-pierre charras] Kicad manager: fix a potential bug which could crash 
Kicad manager. math_for_graphics.cpp: remove useless includes.

--
Started by an SCM change
Building on master in workspace 
$ bzr revision-info -d 
info result: bzr revision-info -d  
returned 0. Command output: "6348 
jp.char...@wanadoo.fr-20151207092209-7rby34qymt287ho6
" stderr: ""
[kicad-full] $ bzr pull --overwrite lp:kicad
You have not informed bzr of your Launchpad ID, and you must do this to
write to Launchpad or access private data.  See "bzr help launchpad-login".
http://bazaar.launchpad.net/~kicad-product-committers/kicad/product is 
permanently redirected to 
http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/changes
You have not informed bzr of your Launchpad ID, and you must do this to
write to Launchpad or access private data.  See "bzr help launchpad-login".
 M  kicad/class_treeproject_item.cpp
 M  polygon/math_for_graphics.cpp
All changes applied successfully.
Now on revision 6349.
[kicad-full] $ bzr revert
$ bzr revision-info -d 
info result: bzr revision-info -d  
returned 0. Command output: "6349 
jp.char...@wanadoo.fr-20151207092431-90sr06sy0jhwwg2f
" stderr: ""
[kicad-full] $ bzr log -v -r 
revid:jp.char...@wanadoo.fr-20151207092209-7rby34qymt287ho6..revid:jp.char...@wanadoo.fr-20151207092431-90sr06sy0jhwwg2f
 --long --show-ids
Getting local revision...
$ bzr revision-info -d 
info result: bzr revision-info -d  
returned 0. Command output: "6349 
jp.char...@wanadoo.fr-20151207092431-90sr06sy0jhwwg2f
" stderr: ""
RevisionState revno:6349 
revid:jp.char...@wanadoo.fr-20151207092431-90sr06sy0jhwwg2f
[kicad-full] $ /bin/sh -xe /tmp/hudson8903420887098700890.sh
+ OPTS=' -DCMAKE_BUILD_TYPE=Debug -DBUILD_GITHUB_PLUGIN=ON -DKICAD_SCRIPTING=ON 
-DKICAD_SCRIPTING_MODULES=ON -DKICAD_SCRIPTING_WXPYTHON=ON'
+ '[' -d build ']'
+ cd build
+ /usr/bin/cmake .. -DCMAKE_BUILD_TYPE=Debug -DBUILD_GITHUB_PLUGIN=ON 
-DKICAD_SCRIPTING=ON -DKICAD_SCRIPTING_MODULES=ON -DKICAD_SCRIPTING_WXPYTHON=ON
-- Kicad install dir: 
-- Check for installed OpenGL -- found
-- Found Glew: /usr/lib64/libGLEW.so
-- Check for installed GLEW -- found
-- Check for installed Cairo -- found
-- Check for installed Python Interpreter -- found
-- Python module install path: lib/python2.6/site-packages
-- wxPython version 3.0 found.
-- Configuring done
-- Generating done
-- Build files have been written to: 

+ rm -f pcbnew/scripting/pcbnewPYTHON_wrap.cxx.o
+ rm -f pcbnew/scripting/pcbnewPYTHON_wrap.cxx
+ make -j4
[  0%] Built target page_layout_lexer_source_files
[  1%] Built target boost
[  1%] Generating version string header
[  1%] Built target netlist_lexer_source_files
-- Using Bazaar to determine build version string.
[  1%] Built target fp_lib_table_lexer_source_files
[  1%] Generating headers containing GLSL source code
[  1%] Built target pcb_lexer_source_files
Headers are up-to-date
[  1%] Built target shader_headers
[  1%] [  1%] Built target specctra_lexer_source_files
Built target pcb_plot_lexer_source_files
[  1%] Built target cmp_library_lexer_source_files
[  1%] Built target avhttp
[  1%] Built target dialog_bom_cfg_lexer_source_files
[  1%] Built target field_template_lexer_source_files
-- Bazaar version control system version 2.1.1 found.
[  2%] Built target lib_dxf
[  2%] Built target idf3
[  3%] Built target potrace
[  3%] Built target pcb_calculator_lexer_source_files
[  3%] Built target dxf2idf
[ 32%] [ 32%] Built target bitmaps
Built target idfcyl
[ 32%] Built target lib-dependencies
[ 32%] Built target idfrect
[ 32%] Built target idf2vrml
-- Writing 
 file 
with version: (2015-12-07 BZR 6349)
[ 32%] Built target version_header
Scanning dependencies of target polygon
[ 32%] Building CXX object 
polygon/CMakeFiles/polygon.dir/math_for_graphics.cpp.o
[ 34%] Built target gal
[ 34%] Built target github_plugin
: In 
function ‘double GetPointToLineSegmentDistance(int, int, int, int, int, int)’:
:467: 
error: call of overloaded ‘abs(int)’ is ambiguous
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/cmath:94: 
note: candidates are: double std::abs(double)
/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/cmath:98: 
note: float std::abs(float)

Re: [Kicad-developers] FindGLM script

[Maciej Sumiński]

Hi Cirilo,

Thank you for the FindGLM script. I had to modify it slightly, as it did
not work with CMake 3.4.0 (problem with STREQUAL).

Here is complete patch [1], that I applied to KiCad in order to use the
system glm library (0.9.7 in my case). If there are no problems with
other platforms/library versions, I guess it might be committed.

Regards,
Orson

1. https://orson.net.pl/pub/glm.patch

On 12/06/2015 11:17 PM, Cirilo Bernardo wrote:
> Thanks Bernhard,
> 
>  I just checked on MSYS2 and it works as well. Can someone push the
> FindGLM.cmake script on
> google drive into the kicad/CMakeModules directory? I'll create a branch
> later and see if there are
> any issues encountered when I delete the glm source from the tree and use
> find_package +
> include-directories. Even if there are any issues to be resolved, with the
> script installed Orson and
> Tom should be able to move the GAL code to the external glm lib whenever
> it's convenient.
> 
> - Cirilo
> 
> 
> On Mon, Dec 7, 2015 at 8:55 AM, Bernhard Stegmaier 
> wrote:
> 
>> … works fine on OS X with a MacPorts installed glm:
>>
>> bstegmaier$ cmake .
>> -- The CXX compiler identification is AppleClang 7.0.0.7000176
>> -- The C compiler identification is AppleClang 7.0.0.7000176
>> -- Check for working CXX compiler:
>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
>> -- Check for working CXX compiler:
>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
>> -- works
>> -- Detecting CXX compiler ABI info
>> -- Detecting CXX compiler ABI info - done
>> -- Detecting CXX compile features
>> -- Detecting CXX compile features - done
>> -- Check for working C compiler:
>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
>> -- Check for working C compiler:
>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
>> -- works
>> -- Detecting C compiler ABI info
>> -- Detecting C compiler ABI info - done
>> -- Detecting C compile features
>> -- Detecting C compile features - done
>> -- Found GLM: /opt/local/include/glm (found suitable version "0.9.6.3",
>> minimum required is "0.9.5.4")
>> -- Configuring done
>> -- Generating done
>> -- Build files have been written to:
>> /Volumes/OSXData/Users/bstegmaier/glm-test
>>
>>
>> Regards,
>> Bernhard
>>
>> On 06.12.2015, at 22:30, Cirilo Bernardo 
>> wrote:
>>
>> I've written a FindGLM script to help with the effort to remove glm source
>> code from
>> the kicad tree.  This works on Linux (well, at least Debian) but needs
>> some testing
>> on MSYS2 and OSX. I believe this script is necessary because:
>>
>> 1. Different distributions are erratic in the inclusion of a FindGLM
>> script or the
>> newer glmConfig script.
>> 2. All other versions of the FindGLM script which I have seen are
>> defective -
>> they do not support version checking.
>> 3. The glmConfig script, even if it exists and is installed, is also
>> defective
>> since the version information is hard-coded into the CMakeLists.txt file
>> which generates the glmConfig script rather than taking the values from the
>> setup.hpp file.
>> 4. This script should work for all known versions of glm from the 0.9.4
>> version
>> included in the kicad tree to the 0.9.8 development version.
>>
>>
>> https://drive.google.com/folderview?id=0By_XTJN-s8aXel9BZjA2ZFlGckU=sharing
>>
>> - Cirilo
>> ___
>> 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
> 




signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [patch] default kicad_common to environment variables

[Wayne Stambaugh]

Was this the case before the patch?  I don't remember seeing this when I
was debugging the original code.

On 12/7/2015 12:15 PM, Nick Østergaard wrote:
> Yes, I noticed that too. :)
> 
> 2015-12-07 18:14 GMT+01:00 Adam Wolf :
>> To clarify, by "results", I mean "shows up in the path manager as".  I
>> wonder if we're doing something later, hmm.
>>
>> Adam Wolf
>>
>> On Mon, Dec 7, 2015 at 11:09 AM, Adam Wolf 
>> wrote:
>>>
>>> It works fine on OS X.
>>>
>>> I found a weirdess with AppendDir, however, that I don't think should hold
>>> this patch up, but I want to mention on the list.
>>>
>>> If tmpfilename is set to something like "helloworld",
>>>
>>> tmpFileName.AppendDir( wxT( "packages3d" ) );
>>>
>>> results in "packages3d/helloworld", which is not what I expected.  If you
>>> add slashes, however, and set  tmpFileName to "/helloworld/",
>>>
>>> tmpFileName.AppendDir( wxT( "packages3d" ) );
>>>
>>> results in "/helloworld/packages3d".
>>>
>>> *sigh*
>>>
>>> Adam Wolf
>>>
>>>
>>> On Mon, Dec 7, 2015 at 9:36 AM, Adam Wolf 
>>> wrote:

 The test build is going now, will be done within 30 minutes.

 Adam Wolf

 On Mon, Dec 7, 2015 at 9:31 AM, Wayne Stambaugh 
 wrote:
>
> Adam,
>
> I forgot to ask, do you want me to go ahead with this patch?
>
> Thanks,
>
> Wayne
>
> On 12/6/2015 7:13 PM, Adam Wolf wrote:
>> When are you planning on doing the 4.0.1 release? Todayish or in about
>> 7
>> days?
>>
>> Adam Wolf
>>
>>
>> On Sun, Dec 6, 2015, 5:41 PM Wayne Stambaugh > > wrote:
>>
>> On 12/6/2015 3:52 PM, Adam Wolf wrote:
>> > If it would help the installer, would it help if we ifdef OSX
>> out,
>> and I
>> > test on OS X next week and we remove the ifdef?
>> >
>> > I am also relatively comfortable applying this on OS X without
>> testing
>> > it.  I have been neck deep in that code over the last few weeks
>> because
>> > of the 3D modules work I was doing for OS X in prep for 4.0.0
>> and it
>> > looks OK to me.
>>
>> If your comfortable with it, I will commit it to the product
>> branch and
>> merge it into the 4.0 branch for the 4.0.1 release.  Let me know
>> if
>> that's what you want me to do.  This is one of the rare exceptions
>> I
>> will make as far as back porting non-critical bugs.
>>
>> >
>> > Either way, I know I can test this early this week.
>> >
>> > Adam Wolf
>> >
>> > On Sun, Dec 6, 2015 at 2:48 PM, Nick Østergaard
>> > 
>> > >> wrote:
>> >
>> > I am very tempted to just apply this to the 4.0.0 windows
>> installer,
>> > just such that the libs will actually work when people
>> install
>> them.
>> >
>> > Should I refrain from this?
>> >
>> > I have tested the patch on windows and linux. It works as
>> expected.
>> >
>> > 2015-12-04 15:21 GMT+01:00 Wayne Stambaugh
>> 
>> > > >>:
>> > > Obviously this patch is only going to be useful for the
>> first time
>> > kicad
>> > > is run.  Existing installs will change.  I'm fine with
>> applying it
>> > once
>> > > it has been tested on OSX and Linux.  I'm at my bandwidth
>> limit so I'm
>> > > going to need some help with the testing.
>> > >
>> > > On 12/4/2015 9:08 AM, Mark Roszko wrote:
>> > >> 1. Users can install anywhere
>> > >> 2. x86 vs x64
>> > >>
>> > >> 32-bit on XP => Program Files
>> > >> 32-bit on 64-bit => Program Files (x86)
>> > >> 64 on 64-bit => Program Files
>> > >> 64 on the rare 64-bit XP => Program Files (x64)
>> > >>
>> > >> ___
>> > >> Mailing list: https://launchpad.net/~kicad-developers
>> > >> Post to : kicad-developers@lists.launchpad.net
>> 
>> > > >
>> > >> Unsubscribe : https://launchpad.net/~kicad-developers
>> > >> More help   : https://help.launchpad.net/ListHelp
>> > >>
>> 

Re: [Kicad-developers] [patch] default kicad_common to environment variables

[Nick Østergaard]

That it did not work at all.

2015-12-07 18:55 GMT+01:00 Wayne Stambaugh :
> Was this the case before the patch?  I don't remember seeing this when I
> was debugging the original code.
>
> On 12/7/2015 12:15 PM, Nick Østergaard wrote:
>> Yes, I noticed that too. :)
>>
>> 2015-12-07 18:14 GMT+01:00 Adam Wolf :
>>> To clarify, by "results", I mean "shows up in the path manager as".  I
>>> wonder if we're doing something later, hmm.
>>>
>>> Adam Wolf
>>>
>>> On Mon, Dec 7, 2015 at 11:09 AM, Adam Wolf 
>>> wrote:

 It works fine on OS X.

 I found a weirdess with AppendDir, however, that I don't think should hold
 this patch up, but I want to mention on the list.

 If tmpfilename is set to something like "helloworld",

 tmpFileName.AppendDir( wxT( "packages3d" ) );

 results in "packages3d/helloworld", which is not what I expected.  If you
 add slashes, however, and set  tmpFileName to "/helloworld/",

 tmpFileName.AppendDir( wxT( "packages3d" ) );

 results in "/helloworld/packages3d".

 *sigh*

 Adam Wolf


 On Mon, Dec 7, 2015 at 9:36 AM, Adam Wolf 
 wrote:
>
> The test build is going now, will be done within 30 minutes.
>
> Adam Wolf
>
> On Mon, Dec 7, 2015 at 9:31 AM, Wayne Stambaugh 
> wrote:
>>
>> Adam,
>>
>> I forgot to ask, do you want me to go ahead with this patch?
>>
>> Thanks,
>>
>> Wayne
>>
>> On 12/6/2015 7:13 PM, Adam Wolf wrote:
>>> When are you planning on doing the 4.0.1 release? Todayish or in about
>>> 7
>>> days?
>>>
>>> Adam Wolf
>>>
>>>
>>> On Sun, Dec 6, 2015, 5:41 PM Wayne Stambaugh >> > wrote:
>>>
>>> On 12/6/2015 3:52 PM, Adam Wolf wrote:
>>> > If it would help the installer, would it help if we ifdef OSX
>>> out,
>>> and I
>>> > test on OS X next week and we remove the ifdef?
>>> >
>>> > I am also relatively comfortable applying this on OS X without
>>> testing
>>> > it.  I have been neck deep in that code over the last few weeks
>>> because
>>> > of the 3D modules work I was doing for OS X in prep for 4.0.0
>>> and it
>>> > looks OK to me.
>>>
>>> If your comfortable with it, I will commit it to the product
>>> branch and
>>> merge it into the 4.0 branch for the 4.0.1 release.  Let me know
>>> if
>>> that's what you want me to do.  This is one of the rare exceptions
>>> I
>>> will make as far as back porting non-critical bugs.
>>>
>>> >
>>> > Either way, I know I can test this early this week.
>>> >
>>> > Adam Wolf
>>> >
>>> > On Sun, Dec 6, 2015 at 2:48 PM, Nick Østergaard
>>> >> 
>>> > >> wrote:
>>> >
>>> > I am very tempted to just apply this to the 4.0.0 windows
>>> installer,
>>> > just such that the libs will actually work when people
>>> install
>>> them.
>>> >
>>> > Should I refrain from this?
>>> >
>>> > I have tested the patch on windows and linux. It works as
>>> expected.
>>> >
>>> > 2015-12-04 15:21 GMT+01:00 Wayne Stambaugh
>>> 
>>> > >> >>:
>>> > > Obviously this patch is only going to be useful for the
>>> first time
>>> > kicad
>>> > > is run.  Existing installs will change.  I'm fine with
>>> applying it
>>> > once
>>> > > it has been tested on OSX and Linux.  I'm at my bandwidth
>>> limit so I'm
>>> > > going to need some help with the testing.
>>> > >
>>> > > On 12/4/2015 9:08 AM, Mark Roszko wrote:
>>> > >> 1. Users can install anywhere
>>> > >> 2. x86 vs x64
>>> > >>
>>> > >> 32-bit on XP => Program Files
>>> > >> 32-bit on 64-bit => Program Files (x86)
>>> > >> 64 on 64-bit => Program Files
>>> > >> 64 on the rare 64-bit XP => Program Files (x64)
>>> > >>
>>> > >> ___
>>> > >> Mailing list: https://launchpad.net/~kicad-developers
>>> > >> Post to : kicad-developers@lists.launchpad.net
>>> 
>>> > 

Re: [Kicad-developers] [patch] default kicad_common to environment variables

[Mark Roszko]

wxFileName makes some "choices". i.e. its constructor/assignment takes
the string and tries to separate file from path.

in the case of wxFileName = "helloworld"; it assumes its a filename
in the case of wxFileName = "/helloworld", it assumes its a file name
in the case of wxFilename = "helloworld/"; it assumes its a folder

and of course AppendDir adds a directory the path and because filename
is separate from directory, the end behavior is what you say. (i.e.
directory gets concatted before file)


The proper solution to fix this would be to GetPathSeparator() and
append it to the environment variable string after reading but before
assigning it to the tmpFileName, thus creating
double slashes in the worst case but wxFileName should clean that out.
I'll add it to the patch later tonight if need be.

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [patch] default kicad_common to environment variables

[Nick Østergaard]

2015-12-07 19:45 GMT+01:00 Wayne Stambaugh :
> I'm not sure what you mean by it did not work at all.  It does exactly
> what I designed to do.  It gives the user the ability to override the
> env variables by doing this:
>
> export KISYSMOD=/some/path/to/footprint/libraries
> kicad

But in this case (without the patch) this will not make the
KISYSMOD=/some/path/to/footprint/libraries on a fresh installation
(config not present or deleted). And this was the sole issue, in my
view. I hope you see what I mean.

> and to gives package devs a way to define where the library and template
> files are installed in a given package by defining DEFAULT_INSTALL_PATH.
>  The only error I can see is that if you do `export KISYSMOD=""` to
> undefined the env variable, I didn't check for an empty value so it will
> be empty in the fp-lib-table.  I probably should have also made sure the
> path actually exists before I assign it.  I just retested this to make
> sure it works as I intended to and it does.
>
> Mark's patch is a different solution to the DEFAULT_INSTALL_PATH problem
> which is as easily broken as my solution.  Don't believe me, try this.
> Install the library files in some path that is not in the correct path
> relative to the kicad bin path.  The default env variables will once
> again be wrong.  There is no perfect solution for this problem.

Yes, I understand, I would just like it to at least work in the most
common scenario. And that is when the windows user installs on his own
computer and user.

> Even if
> you added a solution to the installer package, it would only work for
> the user that installed the package.  The next user on the system would
> be at the mercy of the default install path issue.  Mark's solution only
> helps windows users when they change their default install path.  If our
> package devs are not configuring DEFAULT_INSTALL_PATH, then that is an
> issue.  I'm pretty sure I made an announcement on the developers mailing
> list that you would need to set this if your CMAKE_INSTALL_PREFIX was
> set to a temporary path for packaging purposes.  If I didn't, then my bad.

You did inform us something about the DEFAULT_INSTALL_PATH at an
earlier time when it was implemented. But this do not really help us
in the situation with the windows installer, where we allow the
enduser to install to an abritrary location.

So I want to use the env vars to runtime (when the installer runs) set
the path used for the installation, such that the libs will be found
for the vast majority of the users installing KiCad on windows.

> On 12/7/2015 1:05 PM, Nick Østergaard wrote:
>> That it did not work at all.
>>
>> 2015-12-07 18:55 GMT+01:00 Wayne Stambaugh :
>>> Was this the case before the patch?  I don't remember seeing this when I
>>> was debugging the original code.
>>>
>>> On 12/7/2015 12:15 PM, Nick Østergaard wrote:
 Yes, I noticed that too. :)

 2015-12-07 18:14 GMT+01:00 Adam Wolf :
> To clarify, by "results", I mean "shows up in the path manager as".  I
> wonder if we're doing something later, hmm.
>
> Adam Wolf
>
> On Mon, Dec 7, 2015 at 11:09 AM, Adam Wolf 
> wrote:
>>
>> It works fine on OS X.
>>
>> I found a weirdess with AppendDir, however, that I don't think should 
>> hold
>> this patch up, but I want to mention on the list.
>>
>> If tmpfilename is set to something like "helloworld",
>>
>> tmpFileName.AppendDir( wxT( "packages3d" ) );
>>
>> results in "packages3d/helloworld", which is not what I expected.  If you
>> add slashes, however, and set  tmpFileName to "/helloworld/",
>>
>> tmpFileName.AppendDir( wxT( "packages3d" ) );
>>
>> results in "/helloworld/packages3d".
>>
>> *sigh*
>>
>> Adam Wolf
>>
>>
>> On Mon, Dec 7, 2015 at 9:36 AM, Adam Wolf 
>> wrote:
>>>
>>> The test build is going now, will be done within 30 minutes.
>>>
>>> Adam Wolf
>>>
>>> On Mon, Dec 7, 2015 at 9:31 AM, Wayne Stambaugh 
>>> wrote:

 Adam,

 I forgot to ask, do you want me to go ahead with this patch?

 Thanks,

 Wayne

 On 12/6/2015 7:13 PM, Adam Wolf wrote:
> When are you planning on doing the 4.0.1 release? Todayish or in about
> 7
> days?
>
> Adam Wolf
>
>
> On Sun, Dec 6, 2015, 5:41 PM Wayne Stambaugh  > wrote:
>
> On 12/6/2015 3:52 PM, Adam Wolf wrote:
> > If it would help the installer, would it help if we ifdef OSX
> out,
> and I
> > test on OS X next week and we remove the ifdef?
> 

[Kicad-developers] Rev 6350, abs vs std::abs

[Chris Pavlina]

Mostly directed at JP:

Back in June, I went through and changed a few 'weird' things we were doing, 
including using C abs instead of C++ std::abs:

http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/revision/5831

You just changed it back:

http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/revision/6350

What compiler could possibly have an issue with that? std::abs is, for very 
good reason, the preferred way to find absolute value in C++. As such, if there 
is some obscure reason we need to use abs(), would it kill you to leave some 
explanation behind so nobody else also gets confused by that? A real 
explanation in the commit message would be extremely helpful, as possibly would 
a comment in the vicinity of the intentionally nonstandard code.

--
Chris


___
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] Rev 6350, abs vs std::abs

[jp charras]

Le 07/12/2015 13:51, Chris Pavlina a écrit :
> Mostly directed at JP:
> 
> Back in June, I went through and changed a few 'weird' things we were doing, 
> including using C abs instead of C++ std::abs:
> 
> http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/revision/5831
> 
> You just changed it back:
> 
> http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/revision/6350
> 
> What compiler could possibly have an issue with that? std::abs is, for very 
> good reason, the preferred way to find absolute value in C++. As such, if 
> there is some obscure reason we need to use abs(), would it kill you to leave 
> some explanation behind so nobody else also gets confused by that? A real 
> explanation in the commit message would be extremely helpful, as possibly 
> would a comment in the vicinity of the intentionally nonstandard code.
> 
> --
> Chris


std::abs is preferable to std, and I had no issue on my computer.
It is not so easy to fix an issue (using std::abs with integers,
std::abs used with floats did not created issues) which does not appears
on your computer.

But here is my reason:

> See 
> 
> Changes:
> 
> [jean-pierre charras] Kicad manager: fix a potential bug which could crash 
> Kicad manager. math_for_graphics.cpp: remove useless includes.
> 
> --
> Started by an SCM change
> Building on master in workspace 
> $ bzr revision-info -d 
> info result: bzr revision-info -d 
>  returned 0. Command output: 
> "6348 jp.char...@wanadoo.fr-20151207092209-7rby34qymt287ho6
> " stderr: ""
> [kicad-full] $ bzr pull --overwrite lp:kicad
> You have not informed bzr of your Launchpad ID, and you must do this to
> write to Launchpad or access private data.  See "bzr help launchpad-login".
> http://bazaar.launchpad.net/~kicad-product-committers/kicad/product is 
> permanently redirected to 
> http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/changes
> You have not informed bzr of your Launchpad ID, and you must do this to
> write to Launchpad or access private data.  See "bzr help launchpad-login".
>  M  kicad/class_treeproject_item.cpp
>  M  polygon/math_for_graphics.cpp
> All changes applied successfully.
> Now on revision 6349.
> [kicad-full] $ bzr revert
> $ bzr revision-info -d 
> info result: bzr revision-info -d 
>  returned 0. Command output: 
> "6349 jp.char...@wanadoo.fr-20151207092431-90sr06sy0jhwwg2f
> " stderr: ""
> [kicad-full] $ bzr log -v -r 
> revid:jp.char...@wanadoo.fr-20151207092209-7rby34qymt287ho6..revid:jp.char...@wanadoo.fr-20151207092431-90sr06sy0jhwwg2f
>  --long --show-ids
> Getting local revision...
> $ bzr revision-info -d 
> info result: bzr revision-info -d 
>  returned 0. Command output: 
> "6349 jp.char...@wanadoo.fr-20151207092431-90sr06sy0jhwwg2f
> " stderr: ""
> RevisionState revno:6349 
> revid:jp.char...@wanadoo.fr-20151207092431-90sr06sy0jhwwg2f
> [kicad-full] $ /bin/sh -xe /tmp/hudson8903420887098700890.sh
> + OPTS=' -DCMAKE_BUILD_TYPE=Debug -DBUILD_GITHUB_PLUGIN=ON 
> -DKICAD_SCRIPTING=ON -DKICAD_SCRIPTING_MODULES=ON 
> -DKICAD_SCRIPTING_WXPYTHON=ON'
> + '[' -d build ']'
> + cd build
> + /usr/bin/cmake .. -DCMAKE_BUILD_TYPE=Debug -DBUILD_GITHUB_PLUGIN=ON 
> -DKICAD_SCRIPTING=ON -DKICAD_SCRIPTING_MODULES=ON 
> -DKICAD_SCRIPTING_WXPYTHON=ON
> -- Kicad install dir: 
> -- Check for installed OpenGL -- found
> -- Found Glew: /usr/lib64/libGLEW.so
> -- Check for installed GLEW -- found
> -- Check for installed Cairo -- found
> -- Check for installed Python Interpreter -- found
> -- Python module install path: lib/python2.6/site-packages
> -- wxPython version 3.0 found.
> -- Configuring done
> -- Generating done
> -- Build files have been written to: 
> 
> + rm -f pcbnew/scripting/pcbnewPYTHON_wrap.cxx.o
> + rm -f pcbnew/scripting/pcbnewPYTHON_wrap.cxx
> + make -j4
> [  0%] Built target page_layout_lexer_source_files
> [  1%] Built target boost
> [  1%] Generating version string header
> [  1%] Built target netlist_lexer_source_files
> -- Using Bazaar to determine build version string.
> [  1%] Built target fp_lib_table_lexer_source_files
> [  1%] Generating headers containing GLSL source code
> [  1%] Built target pcb_lexer_source_files
> Headers are up-to-date
> [  1%] Built target shader_headers
> [  1%] [  1%] Built target specctra_lexer_source_files
> Built target pcb_plot_lexer_source_files
> [  1%] Built target cmp_library_lexer_source_files
> [  1%] Built target avhttp
> [  1%] Built target dialog_bom_cfg_lexer_source_files
> [  1%] Built target field_template_lexer_source_files

Re: [Kicad-developers] [patch] default kicad_common to environment variables

[Wayne Stambaugh]

On 12/7/2015 5:07 AM, Nick Østergaard wrote:
> 2015-12-06 23:01 GMT+01:00 Wayne Stambaugh :
>> On 12/6/2015 3:48 PM, Nick Østergaard wrote:
>>> I am very tempted to just apply this to the 4.0.0 windows installer,
>>> just such that the libs will actually work when people install them.
>>>
>>> Should I refrain from this?
>>
>> Please hold off.  I would rather not have the windows 4.0.0 package use
>> different code than the Linux and OSX 4.0.0 packages.  I hope to role
>> out at 4.0.1 release with the GAL crash fix in the next couple of days.
>>  I was trying to get it done today but it just didn't happen.  I can
>> include this patch as well as long as it doesn't break anything.
>>
>>>
>>> I have tested the patch on windows and linux. It works as expected.
>>
>> Did you delete all of your old kicad config files and do a "clean" install?
> 
> I am not exactly sure what a "clean" install has anything to do with
> the default conf. The use case is just to have it set to working paths
> when a user installs KiCad. So it was tested by not having a clean
> conf to see if it kept the paths and then close kicad, remove the
> conf, and start kicad (pcbnew) to verify that the paths were changed.

By clean I meant that no existing kicad conf files exist and none of the
environment variables are set at the system or user level.  You solution
should would work as well assuming the environment variables are not all
ready defined outside of the kicad config.

> 
>>>
>>> 2015-12-04 15:21 GMT+01:00 Wayne Stambaugh :
 Obviously this patch is only going to be useful for the first time kicad
 is run.  Existing installs will change.  I'm fine with applying it once
 it has been tested on OSX and Linux.  I'm at my bandwidth limit so I'm
 going to need some help with the testing.

 On 12/4/2015 9:08 AM, Mark Roszko wrote:
> 1. Users can install anywhere
> 2. x86 vs x64
>
> 32-bit on XP => Program Files
> 32-bit on 64-bit => Program Files (x86)
> 64 on 64-bit => Program Files
> 64 on the rare 64-bit XP => Program Files (x64)
>
> ___
> 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] CMake version.

[Jean-Paul Louis]

Adam,
I updated my Port today,

Jean-Pauls-MacBook-Pro:~ jean-paullouis$ sudo port selfupdate

followed by

Jean-Pauls-MacBook-Pro:~ jean-paullouis$ sudo port upgrade outdated

and the update moved cmake to 3.4.1.

Jean-Pauls-MacBook-Pro:~ jean-paullouis$ cmake --version
cmake version 3.4.1

CMake suite maintained and supported by Kitware (kitware.com/cmake).

curl was also updated to 7.46.0

Regards,
Jean-Paul
AC9GH




> On Dec 7, 2015, at 8:51 PM, Adam Wolf  wrote:
> 
> (We're at 3.1.2 for OS X builds, btw.)
> 
> On Mon, Dec 7, 2015 at 7:20 PM, Mark Roszko  wrote:
> https://launchpad.net/ubuntu/+source/cmake
> 
> Wow, a distro that's slower than Debian, I don't know what to say.
> Sadly I don't think we should necessarily wait for the 14.04 LTS to
> expire 4 years from now.
> 
> On Mon, Dec 7, 2015 at 6:27 PM, Marco Ciampa  wrote:
> > On Mon, Dec 07, 2015 at 04:54:06PM -0500, Wayne Stambaugh wrote:
> >> We currently have the minimum CMake version set to 2.8.4 which was
> >> release in February of 2011.  Debian stable which is usually one of the
> >> last distros to get updated is currently at 3.0.2.  Is anyone using a
> >> version older than 3.0.2 to build KiCad?  If not, I'm going to bump the
> >> minumum CMake version to 3.0.2.  Let me know soon or forever hold you 
> >> peace.
> >
> > Ubuntu stable 14.04
> >
> > $cmake --version
> > cmake version 2.8.12.2
> >
> > --
> >
> >
> > Marco Ciampa
> >
> > I know a joke about UDP, but you might not get it.
> >
> > ++
> > | GNU/Linux User  #78271 |
> > | FSFE fellow   #364 |
> > ++
> >
> >
> > ___
> > 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
> 
> 
> 
> --
> Mark
> 
> ___
> 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] CMake version.

[Adam Wolf]

I do not use MacPorts.  I was talking about the machine that does the Mac
releases/nightly builds.

Thanks!  OS X folks are definitely able to get up to 3.0.2 or newer.

Adam Wolf

On Mon, Dec 7, 2015 at 8:26 PM, Jean-Paul Louis  wrote:

> Adam,
> I updated my Port today,
>
> Jean-Pauls-MacBook-Pro:~ jean-paullouis$ sudo port selfupdate
>
> followed by
>
> Jean-Pauls-MacBook-Pro:~ jean-paullouis$ sudo port upgrade outdated
>
> and the update moved cmake to 3.4.1.
>
> Jean-Pauls-MacBook-Pro:~ jean-paullouis$ cmake --version
> cmake version 3.4.1
>
> CMake suite maintained and supported by Kitware (kitware.com/cmake).
>
> curl was also updated to 7.46.0
>
> Regards,
> Jean-Paul
> AC9GH
>
>
>
>
> > On Dec 7, 2015, at 8:51 PM, Adam Wolf 
> wrote:
> >
> > (We're at 3.1.2 for OS X builds, btw.)
> >
> > On Mon, Dec 7, 2015 at 7:20 PM, Mark Roszko 
> wrote:
> > https://launchpad.net/ubuntu/+source/cmake
> >
> > Wow, a distro that's slower than Debian, I don't know what to say.
> > Sadly I don't think we should necessarily wait for the 14.04 LTS to
> > expire 4 years from now.
> >
> > On Mon, Dec 7, 2015 at 6:27 PM, Marco Ciampa  wrote:
> > > On Mon, Dec 07, 2015 at 04:54:06PM -0500, Wayne Stambaugh wrote:
> > >> We currently have the minimum CMake version set to 2.8.4 which was
> > >> release in February of 2011.  Debian stable which is usually one of
> the
> > >> last distros to get updated is currently at 3.0.2.  Is anyone using a
> > >> version older than 3.0.2 to build KiCad?  If not, I'm going to bump
> the
> > >> minumum CMake version to 3.0.2.  Let me know soon or forever hold you
> peace.
> > >
> > > Ubuntu stable 14.04
> > >
> > > $cmake --version
> > > cmake version 2.8.12.2
> > >
> > > --
> > >
> > >
> > > Marco Ciampa
> > >
> > > I know a joke about UDP, but you might not get it.
> > >
> > > ++
> > > | GNU/Linux User  #78271 |
> > > | FSFE fellow   #364 |
> > > ++
> > >
> > >
> > > ___
> > > 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
> >
> >
> >
> > --
> > Mark
> >
> > ___
> > 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

[Kicad-developers] Updated kicad-install.sh build script

[Lachlan Audas]

Just updated the kicad-install.sh   bash install script for linux-debian,

Added  disable parts libs build/install  option with option  "-L"
This should make thing's a little faster.

Also fix some file permissions, problems when building under sub directors
not owned by the user.

It's hosted at:  https://github.com/lachlanA/kicad-install

Lachlan.
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH v2] Use CMake high-level facility for visibility

[Adam Wolf]

I lost the thread, but someone was asking if this works on OS X.  It
appears to work fine.

Adam Wolf

On Sun, Sep 6, 2015 at 10:48 AM, Simon Richter 
wrote:

> 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 becomes the minimum
> supported version, so this is done, and a warning added to remind whoever
> bumps the minimum requirement to remove the compatibility code as well.
>
>Simon
>
> ---
>  CMakeLists.txt  | 32
> 
>  CMakeModules/PerformFeatureChecks.cmake |  2 --
>  2 files changed, 24 insertions(+), 10 deletions(-)
>
>
> ___
> 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] [PATCH v2] Use CMake high-level facility for visibility

[Wayne Stambaugh]

Thanks Adam!  I'll commit the patch.

On 12/7/2015 2:26 PM, Adam Wolf wrote:
> I lost the thread, but someone was asking if this works on OS X.  It
> appears to work fine.
> 
> Adam Wolf
> 
> On Sun, Sep 6, 2015 at 10:48 AM, Simon Richter  > wrote:
> 
> 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 becomes the minimum
> supported version, so this is done, and a warning added to remind
> whoever
> bumps the minimum requirement to remove the compatibility code as well.
> 
>Simon
> 
> ---
>  CMakeLists.txt  | 32
> 
>  CMakeModules/PerformFeatureChecks.cmake |  2 --
>  2 files changed, 24 insertions(+), 10 deletions(-)
> 
> 
> ___
> 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] [patch] default kicad_common to environment variables

[Cirilo Bernardo]

On Tue, Dec 8, 2015 at 4:09 AM, Adam Wolf 
wrote:

> It works fine on OS X.
>
> I found a weirdess with AppendDir, however, that I don't think should hold
> this patch up, but I want to mention on the list.
>
> If tmpfilename is set to something like "helloworld",
>
> tmpFileName.AppendDir( wxT( "packages3d" ) );
>
> results in "packages3d/helloworld", which is not what I expected.  If you
> add slashes, however, and set  tmpFileName to "/helloworld/",
>
> tmpFileName.AppendDir( wxT( "packages3d" ) );
>
> results in "/helloworld/packages3d".
>
> *sigh*
>
> Adam Wolf
>
>
Does that always happen or does it depend on how wxFileName was
instantiatied?
+ wxFileName x( wxT( "helloworld" ) , ""  );
+ wxFileName x( wxT( "helloworld" )  );

In the first form "helloworld" is a directory element; in the second form
it is a filename element.
Using the second form would explain the strange behavior with AppendDir and
slashes.
wxFileName is not very well documented and is easy to misuse. I had to
spend time reading
the source code to make any sense of it. The documentation would be so much
better if it
had warnings about mistakes people are likely to make.

- Cirilo


> On Mon, Dec 7, 2015 at 9:36 AM, Adam Wolf 
> wrote:
>
>> The test build is going now, will be done within 30 minutes.
>>
>> Adam Wolf
>>
>> On Mon, Dec 7, 2015 at 9:31 AM, Wayne Stambaugh 
>> wrote:
>>
>>> Adam,
>>>
>>> I forgot to ask, do you want me to go ahead with this patch?
>>>
>>> Thanks,
>>>
>>> Wayne
>>>
>>> On 12/6/2015 7:13 PM, Adam Wolf wrote:
>>> > When are you planning on doing the 4.0.1 release? Todayish or in about
>>> 7
>>> > days?
>>> >
>>> > Adam Wolf
>>> >
>>> >
>>> > On Sun, Dec 6, 2015, 5:41 PM Wayne Stambaugh >> > > wrote:
>>> >
>>> > On 12/6/2015 3:52 PM, Adam Wolf wrote:
>>> > > If it would help the installer, would it help if we ifdef OSX
>>> out,
>>> > and I
>>> > > test on OS X next week and we remove the ifdef?
>>> > >
>>> > > I am also relatively comfortable applying this on OS X without
>>> testing
>>> > > it.  I have been neck deep in that code over the last few weeks
>>> > because
>>> > > of the 3D modules work I was doing for OS X in prep for 4.0.0
>>> and it
>>> > > looks OK to me.
>>> >
>>> > If your comfortable with it, I will commit it to the product
>>> branch and
>>> > merge it into the 4.0 branch for the 4.0.1 release.  Let me know if
>>> > that's what you want me to do.  This is one of the rare exceptions
>>> I
>>> > will make as far as back porting non-critical bugs.
>>> >
>>> > >
>>> > > Either way, I know I can test this early this week.
>>> > >
>>> > > Adam Wolf
>>> > >
>>> > > On Sun, Dec 6, 2015 at 2:48 PM, Nick Østergaard <
>>> oe.n...@gmail.com
>>> > 
>>> > > >> wrote:
>>> > >
>>> > > I am very tempted to just apply this to the 4.0.0 windows
>>> > installer,
>>> > > just such that the libs will actually work when people
>>> install
>>> > them.
>>> > >
>>> > > Should I refrain from this?
>>> > >
>>> > > I have tested the patch on windows and linux. It works as
>>> > expected.
>>> > >
>>> > > 2015-12-04 15:21 GMT+01:00 Wayne Stambaugh
>>> > 
>>> > > >> >>>:
>>> > > > Obviously this patch is only going to be useful for the
>>> > first time
>>> > > kicad
>>> > > > is run.  Existing installs will change.  I'm fine with
>>> > applying it
>>> > > once
>>> > > > it has been tested on OSX and Linux.  I'm at my bandwidth
>>> > limit so I'm
>>> > > > going to need some help with the testing.
>>> > > >
>>> > > > On 12/4/2015 9:08 AM, Mark Roszko wrote:
>>> > > >> 1. Users can install anywhere
>>> > > >> 2. x86 vs x64
>>> > > >>
>>> > > >> 32-bit on XP => Program Files
>>> > > >> 32-bit on 64-bit => Program Files (x86)
>>> > > >> 64 on 64-bit => Program Files
>>> > > >> 64 on the rare 64-bit XP => Program Files (x64)
>>> > > >>
>>> > > >> ___
>>> > > >> Mailing list: https://launchpad.net/~kicad-developers
>>> > > >> Post to : kicad-developers@lists.launchpad.net
>>> > 
>>> > > >> > >
>>> > > >> Unsubscribe : https://launchpad.net/~kicad-developers
>>> > > >> More help   : https://help.launchpad.net/ListHelp
>>> > > >>
>>> > > 

Re: [Kicad-developers] [patch] default kicad_common to environment variables

[Mark Roszko]

Updated patch to use AssignDir instead of me stupidly assigning to wxFilename.

I added an empty var check(so it uses default instead) but it's
pointless. Windows disallows
empty env vars. On other systems if its empty you have configuration
issues and you should be fixing them, not kicad.


0001-Default-saved-paths-to-environment-variables-if-avai.patch
Description: Binary data
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] Copper layers selected by default in plot dialog

[Jon Neal]

Updated patch.

The stupid thing I missed shouldn't happen any more. When you plot it will
only plot the layers you have selected rather than all of the copper layers.

Jon

On Fri, Dec 4, 2015 at 4:06 PM, Jon Neal  wrote:

> I think I understand the issue. I will provide an updated patch shortly.
>
> Jon
>
> On Fri, Dec 4, 2015 at 3:39 PM, Jon Neal  wrote:
>
>> jp,
>>
>> Can you provide some more details? I tested it on my two computers, but
>> that is as much as I could test.
>>
>> Thanks,
>> Jon
>>
>> On Fri, Dec 4, 2015 at 1:53 PM, jp charras  wrote:
>>
>>> Le 04/12/2015 19:48, jp charras a écrit :
>>> > Le 03/12/2015 20:11, Jon Neal a écrit :
>>> >> This fixes a small "issue" that was annoying me.
>>> >>
>>> >> With this patch when you add new layers in pcbnew they will be
>>> selected
>>> >> by default for plotting.
>>> >>
>>> >> It does this in two places:
>>> >> First - it sets the default for a new board to plot select all copper
>>> >> layers. This is needed so the first time the plot dialog is opened all
>>> >> enabled copper layers will be selected.
>>> >> Second - when the plot dialog is closed all disabled copper layers are
>>> >> set to "selected". The reason for this is when the dialog is closed it
>>> >> was setting all disabled copper layers to unselected. If you added new
>>> >> layers to a board it was defaulting to unselected. This is done here
>>> >> because it would have been difficult to access the plot dialog
>>> settings
>>> >> from the layer preferences manager.
>>> >>
>>> >> Jon
>>> >>
>>> >
>>> > Committed. Thanks.
>>> >
>>> >
>>>
>>> Uncommitted: It does not work very well.
>>> Sorry.
>>>
>>>
>>> --
>>> Jean-Pierre CHARRAS
>>>
>>> ___
>>> 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
>>>
>>
>>
>
From a0f1df4a6caa83318a05950979e8c4b5f0104c21 Mon Sep 17 00:00:00 2001
From: Jon Neal 
Date: Wed, 11 Nov 2015 21:37:28 -0500
Subject: [PATCH] The plot dialog now selects all copper layers for plotting as
 the default.

---
 pcbnew/dialogs/dialog_plot.cpp | 19 ---
 pcbnew/pcb_plot_params.cpp |  6 +++---
 2 files changed, 19 insertions(+), 6 deletions(-)

diff --git a/pcbnew/dialogs/dialog_plot.cpp b/pcbnew/dialogs/dialog_plot.cpp
index 5806438..f3d13a4 100644
--- a/pcbnew/dialogs/dialog_plot.cpp
+++ b/pcbnew/dialogs/dialog_plot.cpp
@@ -677,14 +677,18 @@ void DIALOG_PLOT::applyPlotSettings()
 tempOptions.SetGerberPrecision( m_rbGerberFormat->GetSelection() == 0 ? 5 : 6 );
 
 LSET selectedLayers;
-
 for( unsigned i = 0; i < m_layerList.size(); i++ )
 {
 if( m_layerCheckListBox->IsChecked( i ) )
 selectedLayers.set( m_layerList[i] );
 }
-
+// Get a list of copper layers that aren't being used by inverting enabled layers.
+LSET disabledCopperLayers = LSET::AllCuMask() & ~m_board->GetEnabledLayers();
+// Enable all of the disabled copper layers.
+// If someone enables more copper layers they will be selected by default.
+selectedLayers = selectedLayers | disabledCopperLayers;
 tempOptions.SetLayerSelection( selectedLayers );
+
 tempOptions.SetNegative( m_plotPSNegativeOpt->GetValue() );
 tempOptions.SetA4Output( m_forcePSA4OutputOpt->GetValue() );
 
@@ -782,7 +786,16 @@ void DIALOG_PLOT::Plot( wxCommandEvent& event )
 for( LSEQ seq = m_plotOpts.GetLayerSelection().UIOrder();  seq;  ++seq )
 {
 LAYER_ID layer = *seq;
-
+
+// All copper layers that are disabled are actually selected
+// This is due to wonkyness in automatically selecting copper layers
+// for plotting when adding more than two layers to a board.
+// If plot options become accessible to the layers setup dialog
+// please move this functionality there!
+// This skips a copper layer if it is actually disabled on the board.
+if( ( LSET::AllCuMask() & ~m_board->GetEnabledLayers() )[layer] )
+continue;
+
 // Pick the basename from the board file
 wxFileName fn( boardFilename );
 
diff --git a/pcbnew/pcb_plot_params.cpp b/pcbnew/pcb_plot_params.cpp
index 9f40fbc..85aeb04 100644
--- a/pcbnew/pcb_plot_params.cpp
+++ b/pcbnew/pcb_plot_params.cpp
@@ -79,8 +79,7 @@ static bool setInt( int* aInt, int aValue, int aMin, int aMax )
 
 // PCB_PLOT_PARAMS
 
-PCB_PLOT_PARAMS::PCB_PLOT_PARAMS() :
-m_layerSelection( 4, B_Cu, F_Cu, F_SilkS, B_SilkS )
+PCB_PLOT_PARAMS::PCB_PLOT_PARAMS()
 {
 m_useGerberProtelExtensions  = false;
 m_useGerberAttributes= false;
@@ -116,6 +115,7 @@ PCB_PLOT_PARAMS::PCB_PLOT_PARAMS() :
 m_referenceColor = BLACK;
 m_valueColor = BLACK;
 

Re: [Kicad-developers] [patch] default kicad_common to environment variables

[Nick Østergaard]

This patch seem to work more sanely.

2015-12-07 21:48 GMT+01:00 Mark Roszko :
> Updated patch to use AssignDir instead of me stupidly assigning to wxFilename.
>
> I added an empty var check(so it uses default instead) but it's
> pointless. Windows disallows
> empty env vars. On other systems if its empty you have configuration
> issues and you should be fixing them, not kicad.
>
> ___
> 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] [patch] default kicad_common to environment variables

[Wayne Stambaugh]

On 12/7/2015 3:48 PM, Mark Roszko wrote:
> Updated patch to use AssignDir instead of me stupidly assigning to wxFilename.
> 
> I added an empty var check(so it uses default instead) but it's
> pointless. Windows disallows
> empty env vars. On other systems if its empty you have configuration
> issues and you should be fixing them, not kicad.

Using the msys2 environment you can assign an empty env variable so we
should definitely test the return string to see if it's empty and fall
back to the default if it is empty.

> 
> 
> 
> ___
> 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] [PATCH 1/4] Use CMake high-level facility for visibility

[Wayne Stambaugh]

Patch committed in product branch r6352.  Thanks.

On 12/1/2015 2:14 AM, Simon Richter wrote:
> 
> 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, compatibility code is added as well.
> 
> When the minimum required version is bumped to 3.3, this code becomes
> obsolete and a warning is displayed that the compatibility code should be
> removed as well.
> ---
>  CMakeLists.txt  | 32 
>  CMakeModules/PerformFeatureChecks.cmake |  2 --
>  2 files changed, 24 insertions(+), 10 deletions(-)
> 
> 
> 
> ___
> 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

[Kicad-developers] CMake version.

[Wayne Stambaugh]

We currently have the minimum CMake version set to 2.8.4 which was
release in February of 2011.  Debian stable which is usually one of the
last distros to get updated is currently at 3.0.2.  Is anyone using a
version older than 3.0.2 to build KiCad?  If not, I'm going to bump the
minumum CMake version to 3.0.2.  Let me know soon or forever hold you peace.

Thanks,

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

Re: [Kicad-developers] [patch] default kicad_common to environment variables

[Mark Roszko]

That's what the patch does now.. Someone using msys2  for anything other
than compiling is a bit strange though.
On Dec 7, 2015 4:59 PM, "Wayne Stambaugh"  wrote:

> On 12/7/2015 3:48 PM, Mark Roszko wrote:
> > Updated patch to use AssignDir instead of me stupidly assigning to
> wxFilename.
> >
> > I added an empty var check(so it uses default instead) but it's
> > pointless. Windows disallows
> > empty env vars. On other systems if its empty you have configuration
> > issues and you should be fixing them, not kicad.
>
> Using the msys2 environment you can assign an empty env variable so we
> should definitely test the return string to see if it's empty and fall
> back to the default if it is empty.
>
> >
> >
> >
> > ___
> > 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

[Kicad-developers] [PATCH] Fix broken language in duplicate zone error message

[Chris Pavlina]

The following error messages in pcbnew are poorly written:

- The duplicated zone is on the same layer as the initial zone, which 
  has no sense. Please, choose another layer for the new zone.

  + for obvious reasons, broken English

- The outline of the duplicated zone fails DRC check!

  + "DRC check" is redundant
  + This is erroneously displayed as an error - it's a warning, not an 
error. The operation actually proceeds in spite of the "error".
  + "The outline of the duplicated zone" is slightly confusing and 
ambiguous
  + The exclamation point makes it read weirdly excited

This patch rewrites them:

- "The duplicated zone cannot be on the same layer as the original 
  zone."

- "Warning: The new zone fails DRC" (also changed this from DisplayError 
  to DisplayInfoMessage)

Apologies for the patch noise, but someone pointed this out to me on IRC
and I couldn't help myself :)

--
Chris

commit 3f53a390878be61e76383713f8f1e5371789ad62
Author: Chris Pavlina 
Date:   Mon Dec 7 18:10:29 2015 -0500

Fix a couple duplicated zone messages

diff --git a/pcbnew/zones_by_polygon.cpp b/pcbnew/zones_by_polygon.cpp
index c6e1056..4d5663b 100644
--- a/pcbnew/zones_by_polygon.cpp
+++ b/pcbnew/zones_by_polygon.cpp
@@ -128,8 +128,7 @@ void PCB_EDIT_FRAME::duplicateZone( wxDC* aDC, ZONE_CONTAINER* aZone )
 if( success && ( aZone->GetLayer() == zoneSettings.m_CurrentZone_Layer ) )
 {
 DisplayError( this,
-_( "The duplicated zone is on the same layer as the initial zone, which has no sense.\n"
-   "Please, choose an other layer for the new zone") );
+_( "The duplicated zone cannot be on the same layer as the original zone." ) );
 success = false;
 }
 
@@ -158,8 +157,7 @@ void PCB_EDIT_FRAME::duplicateZone( wxDC* aDC, ZONE_CONTAINER* aZone )
 if( GetBoard()->GetAreaIndex( newZone ) >= 0
&& GetBoard()->Test_Drc_Areas_Outlines_To_Areas_Outlines( newZone, true ) )
 {
-DisplayError( this,
-_( "The outline of the duplicated zone fails DRC check!" ) );
+DisplayInfoMessage( this, _( "Warning: The new zone fails DRC" ) );
 }
 
 UpdateCopyOfZonesList( s_PickedList, s_AuxiliaryList, GetBoard() );
___
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] CMake version.

[Marco Ciampa]

On Mon, Dec 07, 2015 at 04:54:06PM -0500, Wayne Stambaugh wrote:
> We currently have the minimum CMake version set to 2.8.4 which was
> release in February of 2011.  Debian stable which is usually one of the
> last distros to get updated is currently at 3.0.2.  Is anyone using a
> version older than 3.0.2 to build KiCad?  If not, I'm going to bump the
> minumum CMake version to 3.0.2.  Let me know soon or forever hold you peace.

Ubuntu stable 14.04

$cmake --version
cmake version 2.8.12.2

--


Marco Ciampa

I know a joke about UDP, but you might not get it.

++
| GNU/Linux User  #78271 |
| FSFE fellow   #364 |
++


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [patch] default kicad_common to environment variables

[Mark Roszko]

Actually turns out theres a AssignDir function.

So tmpFileName = blah
just needs to be converted to tmpFileName.AssignDir( env_var )

assuming they didn't make assigndir barf on no trailing slash

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [patch] default kicad_common to environment variables

[Adam Wolf]

I'm working through it--if anyone can dig deeper sooner, please do so.

(I need to refactor my build system so I can do non-fresh builds, this is
taking forever :) )

Adam Wolf

On Mon, Dec 7, 2015 at 11:55 AM, Wayne Stambaugh 
wrote:

> Was this the case before the patch?  I don't remember seeing this when I
> was debugging the original code.
>
> On 12/7/2015 12:15 PM, Nick Østergaard wrote:
> > Yes, I noticed that too. :)
> >
> > 2015-12-07 18:14 GMT+01:00 Adam Wolf :
> >> To clarify, by "results", I mean "shows up in the path manager as".  I
> >> wonder if we're doing something later, hmm.
> >>
> >> Adam Wolf
> >>
> >> On Mon, Dec 7, 2015 at 11:09 AM, Adam Wolf <
> adamw...@feelslikeburning.com>
> >> wrote:
> >>>
> >>> It works fine on OS X.
> >>>
> >>> I found a weirdess with AppendDir, however, that I don't think should
> hold
> >>> this patch up, but I want to mention on the list.
> >>>
> >>> If tmpfilename is set to something like "helloworld",
> >>>
> >>> tmpFileName.AppendDir( wxT( "packages3d" ) );
> >>>
> >>> results in "packages3d/helloworld", which is not what I expected.  If
> you
> >>> add slashes, however, and set  tmpFileName to "/helloworld/",
> >>>
> >>> tmpFileName.AppendDir( wxT( "packages3d" ) );
> >>>
> >>> results in "/helloworld/packages3d".
> >>>
> >>> *sigh*
> >>>
> >>> Adam Wolf
> >>>
> >>>
> >>> On Mon, Dec 7, 2015 at 9:36 AM, Adam Wolf <
> adamw...@feelslikeburning.com>
> >>> wrote:
> 
>  The test build is going now, will be done within 30 minutes.
> 
>  Adam Wolf
> 
>  On Mon, Dec 7, 2015 at 9:31 AM, Wayne Stambaugh  >
>  wrote:
> >
> > Adam,
> >
> > I forgot to ask, do you want me to go ahead with this patch?
> >
> > Thanks,
> >
> > Wayne
> >
> > On 12/6/2015 7:13 PM, Adam Wolf wrote:
> >> When are you planning on doing the 4.0.1 release? Todayish or in
> about
> >> 7
> >> days?
> >>
> >> Adam Wolf
> >>
> >>
> >> On Sun, Dec 6, 2015, 5:41 PM Wayne Stambaugh  >> > wrote:
> >>
> >> On 12/6/2015 3:52 PM, Adam Wolf wrote:
> >> > If it would help the installer, would it help if we ifdef OSX
> >> out,
> >> and I
> >> > test on OS X next week and we remove the ifdef?
> >> >
> >> > I am also relatively comfortable applying this on OS X without
> >> testing
> >> > it.  I have been neck deep in that code over the last few
> weeks
> >> because
> >> > of the 3D modules work I was doing for OS X in prep for 4.0.0
> >> and it
> >> > looks OK to me.
> >>
> >> If your comfortable with it, I will commit it to the product
> >> branch and
> >> merge it into the 4.0 branch for the 4.0.1 release.  Let me know
> >> if
> >> that's what you want me to do.  This is one of the rare
> exceptions
> >> I
> >> will make as far as back porting non-critical bugs.
> >>
> >> >
> >> > Either way, I know I can test this early this week.
> >> >
> >> > Adam Wolf
> >> >
> >> > On Sun, Dec 6, 2015 at 2:48 PM, Nick Østergaard
> >>  >> 
> >> > >> wrote:
> >> >
> >> > I am very tempted to just apply this to the 4.0.0 windows
> >> installer,
> >> > just such that the libs will actually work when people
> >> install
> >> them.
> >> >
> >> > Should I refrain from this?
> >> >
> >> > I have tested the patch on windows and linux. It works as
> >> expected.
> >> >
> >> > 2015-12-04 15:21 GMT+01:00 Wayne Stambaugh
> >> 
> >> >  >> >>:
> >> > > Obviously this patch is only going to be useful for the
> >> first time
> >> > kicad
> >> > > is run.  Existing installs will change.  I'm fine with
> >> applying it
> >> > once
> >> > > it has been tested on OSX and Linux.  I'm at my
> bandwidth
> >> limit so I'm
> >> > > going to need some help with the testing.
> >> > >
> >> > > On 12/4/2015 9:08 AM, Mark Roszko wrote:
> >> > >> 1. Users can install anywhere
> >> > >> 2. x86 vs x64
> >> > >>
> >> > >> 32-bit on XP => Program Files
> >> > >> 32-bit on 64-bit => Program Files (x86)
> >> > >> 64 on 64-bit => Program Files
> >> > >> 64 on the rare 64-bit XP => Program Files (x64)
> >> > >>
> >> > >> 

Re: [Kicad-developers] [patch] default kicad_common to environment variables

[Adam Wolf]

I think that would be a good idea.  This is the way it seems to always go
for me too--have a patch to add something to KiCad, and expose an issue we
didn't realize we had :)

Adam Wolf

On Mon, Dec 7, 2015 at 12:10 PM, Mark Roszko  wrote:

> wxFileName makes some "choices". i.e. its constructor/assignment takes
> the string and tries to separate file from path.
>
> in the case of wxFileName = "helloworld"; it assumes its a filename
> in the case of wxFileName = "/helloworld", it assumes its a file name
> in the case of wxFilename = "helloworld/"; it assumes its a folder
>
> and of course AppendDir adds a directory the path and because filename
> is separate from directory, the end behavior is what you say. (i.e.
> directory gets concatted before file)
>
>
> The proper solution to fix this would be to GetPathSeparator() and
> append it to the environment variable string after reading but before
> assigning it to the tmpFileName, thus creating
> double slashes in the worst case but wxFileName should clean that out.
> I'll add it to the patch later tonight if need be.
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [patch] default kicad_common to environment variables

[Wayne Stambaugh]

I'm not sure what you mean by it did not work at all.  It does exactly
what I designed to do.  It gives the user the ability to override the
env variables by doing this:

export KISYSMOD=/some/path/to/footprint/libraries
kicad

and to gives package devs a way to define where the library and template
files are installed in a given package by defining DEFAULT_INSTALL_PATH.
 The only error I can see is that if you do `export KISYSMOD=""` to
undefined the env variable, I didn't check for an empty value so it will
be empty in the fp-lib-table.  I probably should have also made sure the
path actually exists before I assign it.  I just retested this to make
sure it works as I intended to and it does.

Mark's patch is a different solution to the DEFAULT_INSTALL_PATH problem
which is as easily broken as my solution.  Don't believe me, try this.
Install the library files in some path that is not in the correct path
relative to the kicad bin path.  The default env variables will once
again be wrong.  There is no perfect solution for this problem.  Even if
you added a solution to the installer package, it would only work for
the user that installed the package.  The next user on the system would
be at the mercy of the default install path issue.  Mark's solution only
helps windows users when they change their default install path.  If our
package devs are not configuring DEFAULT_INSTALL_PATH, then that is an
issue.  I'm pretty sure I made an announcement on the developers mailing
list that you would need to set this if your CMAKE_INSTALL_PREFIX was
set to a temporary path for packaging purposes.  If I didn't, then my bad.

On 12/7/2015 1:05 PM, Nick Østergaard wrote:
> That it did not work at all.
> 
> 2015-12-07 18:55 GMT+01:00 Wayne Stambaugh :
>> Was this the case before the patch?  I don't remember seeing this when I
>> was debugging the original code.
>>
>> On 12/7/2015 12:15 PM, Nick Østergaard wrote:
>>> Yes, I noticed that too. :)
>>>
>>> 2015-12-07 18:14 GMT+01:00 Adam Wolf :
 To clarify, by "results", I mean "shows up in the path manager as".  I
 wonder if we're doing something later, hmm.

 Adam Wolf

 On Mon, Dec 7, 2015 at 11:09 AM, Adam Wolf 
 wrote:
>
> It works fine on OS X.
>
> I found a weirdess with AppendDir, however, that I don't think should hold
> this patch up, but I want to mention on the list.
>
> If tmpfilename is set to something like "helloworld",
>
> tmpFileName.AppendDir( wxT( "packages3d" ) );
>
> results in "packages3d/helloworld", which is not what I expected.  If you
> add slashes, however, and set  tmpFileName to "/helloworld/",
>
> tmpFileName.AppendDir( wxT( "packages3d" ) );
>
> results in "/helloworld/packages3d".
>
> *sigh*
>
> Adam Wolf
>
>
> On Mon, Dec 7, 2015 at 9:36 AM, Adam Wolf 
> wrote:
>>
>> The test build is going now, will be done within 30 minutes.
>>
>> Adam Wolf
>>
>> On Mon, Dec 7, 2015 at 9:31 AM, Wayne Stambaugh 
>> wrote:
>>>
>>> Adam,
>>>
>>> I forgot to ask, do you want me to go ahead with this patch?
>>>
>>> Thanks,
>>>
>>> Wayne
>>>
>>> On 12/6/2015 7:13 PM, Adam Wolf wrote:
 When are you planning on doing the 4.0.1 release? Todayish or in about
 7
 days?

 Adam Wolf


 On Sun, Dec 6, 2015, 5:41 PM Wayne Stambaugh > wrote:

 On 12/6/2015 3:52 PM, Adam Wolf wrote:
 > If it would help the installer, would it help if we ifdef OSX
 out,
 and I
 > test on OS X next week and we remove the ifdef?
 >
 > I am also relatively comfortable applying this on OS X without
 testing
 > it.  I have been neck deep in that code over the last few weeks
 because
 > of the 3D modules work I was doing for OS X in prep for 4.0.0
 and it
 > looks OK to me.

 If your comfortable with it, I will commit it to the product
 branch and
 merge it into the 4.0 branch for the 4.0.1 release.  Let me know
 if
 that's what you want me to do.  This is one of the rare exceptions
 I
 will make as far as back porting non-critical bugs.

 >
 > Either way, I know I can test this early this week.
 >
 > Adam Wolf
 >
 > On Sun, Dec 6, 2015 at 2:48 PM, Nick Østergaard
 
 > >> wrote:
 >

Re: [Kicad-developers] Full integration to Github

[Mark Roszko]

>I am not sure that closed issues have no value.  In the last few months, 
>probably 10% of the bugs I've closed were old bugs that resurfaced in a new 
>way.  I don't think we want to lose that.

But they can sit in cold storage on launchpad.
People don't reopen the old bug reports do they? They should be
creating a new report.


> This is more in terms of applying security updates, doing backups
Trac has had a decent record the last few years, don't think they've
had any security patches. Backups can be automated.


One of Github's the most annoying downsides is the lack of a "Heat" or
"Like" feature on bug reports like on Launchpad.
People would have to spam the thread to say they have the problem to
bump it in comment count.

Granted Github's interface may be quicker to sort, it definitely has
less organization options.


The tags being imported themselves is insane, we can't organize the
github bugs if we have 200+ labels/tags. That's something we
definitely need to avoid importing.

___
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] CMake version.

[Mark Roszko]

https://launchpad.net/ubuntu/+source/cmake

Wow, a distro that's slower than Debian, I don't know what to say.
Sadly I don't think we should necessarily wait for the 14.04 LTS to
expire 4 years from now.

On Mon, Dec 7, 2015 at 6:27 PM, Marco Ciampa  wrote:
> On Mon, Dec 07, 2015 at 04:54:06PM -0500, Wayne Stambaugh wrote:
>> We currently have the minimum CMake version set to 2.8.4 which was
>> release in February of 2011.  Debian stable which is usually one of the
>> last distros to get updated is currently at 3.0.2.  Is anyone using a
>> version older than 3.0.2 to build KiCad?  If not, I'm going to bump the
>> minumum CMake version to 3.0.2.  Let me know soon or forever hold you peace.
>
> Ubuntu stable 14.04
>
> $cmake --version
> cmake version 2.8.12.2
>
> --
>
>
> Marco Ciampa
>
> I know a joke about UDP, but you might not get it.
>
> ++
> | GNU/Linux User  #78271 |
> | FSFE fellow   #364 |
> ++
>
>
> ___
> 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



-- 
Mark

___
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] CMake version.

[Adam Wolf]

(We're at 3.1.2 for OS X builds, btw.)

On Mon, Dec 7, 2015 at 7:20 PM, Mark Roszko  wrote:

> https://launchpad.net/ubuntu/+source/cmake
>
> Wow, a distro that's slower than Debian, I don't know what to say.
> Sadly I don't think we should necessarily wait for the 14.04 LTS to
> expire 4 years from now.
>
> On Mon, Dec 7, 2015 at 6:27 PM, Marco Ciampa  wrote:
> > On Mon, Dec 07, 2015 at 04:54:06PM -0500, Wayne Stambaugh wrote:
> >> We currently have the minimum CMake version set to 2.8.4 which was
> >> release in February of 2011.  Debian stable which is usually one of the
> >> last distros to get updated is currently at 3.0.2.  Is anyone using a
> >> version older than 3.0.2 to build KiCad?  If not, I'm going to bump the
> >> minumum CMake version to 3.0.2.  Let me know soon or forever hold you
> peace.
> >
> > Ubuntu stable 14.04
> >
> > $cmake --version
> > cmake version 2.8.12.2
> >
> > --
> >
> >
> > Marco Ciampa
> >
> > I know a joke about UDP, but you might not get it.
> >
> > ++
> > | GNU/Linux User  #78271 |
> > | FSFE fellow   #364 |
> > ++
> >
> >
> > ___
> > 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
>
>
>
> --
> Mark
>
> ___
> 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] CMake version.

[Cirilo Bernardo]

Presumably anyone building on an old Ubuntu-LTS must know what they're doing
and CMake is the least of their worries, so I wouldn't count this as a
problem. If
the LTS people want to support a newer kicad version on that system I'm sure
they can backport all the other libraries and frameworks which they will
need.
At some point system support is no longer the responsibility of the kicad
developers; there's no point holding up all users for the benefit of a user
base of 1.

- Cirilo


On Tue, Dec 8, 2015 at 12:20 PM, Mark Roszko  wrote:

> https://launchpad.net/ubuntu/+source/cmake
>
> Wow, a distro that's slower than Debian, I don't know what to say.
> Sadly I don't think we should necessarily wait for the 14.04 LTS to
> expire 4 years from now.
>
> On Mon, Dec 7, 2015 at 6:27 PM, Marco Ciampa  wrote:
> > On Mon, Dec 07, 2015 at 04:54:06PM -0500, Wayne Stambaugh wrote:
> >> We currently have the minimum CMake version set to 2.8.4 which was
> >> release in February of 2011.  Debian stable which is usually one of the
> >> last distros to get updated is currently at 3.0.2.  Is anyone using a
> >> version older than 3.0.2 to build KiCad?  If not, I'm going to bump the
> >> minumum CMake version to 3.0.2.  Let me know soon or forever hold you
> peace.
> >
> > Ubuntu stable 14.04
> >
> > $cmake --version
> > cmake version 2.8.12.2
> >
> > --
> >
> >
> > Marco Ciampa
> >
> > I know a joke about UDP, but you might not get it.
> >
> > ++
> > | GNU/Linux User  #78271 |
> > | FSFE fellow   #364 |
> > ++
> >
> >
> > ___
> > 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
>
>
>
> --
> Mark
>
> ___
> 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