Re: [Kicad-developers] Boost dependencies

2013-11-14 Thread Dick Hollenbeck 
On 11/14/2013 10:27 AM, Maciej Sumiński wrote:
> Today I saw an error during the boost build:
> fatal error: bzlib.h: No such file or directory
> 
> Would not it be good to add bzip2 dependency to download_boost.cmake 
> script, so users will get a clear message before an attempt to build the 
> library?
> 
> Regards,
> Orson

Thanks, committed in 4469.


___
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] [Bug 1251351] [NEW] Code clean up for future compatibility with Visual C++

2013-11-14 Thread jp charras 
Le 14/11/2013 19:34, Lorenzo Marcantonio a écrit :
> On Thu, Nov 14, 2013 at 06:19:45PM -, Wayne Stambaugh wrote:
>> There is no doubt.  Please see FAQ:
> 
> Ouch:P I didn't remember VC++ was *so* hated:P
> 
> However (VC++ aside) if the patches contains 'cleanup' as in 'better C++
> idioms' (like removing globals or define) I think they would be at least
> considered.
> 


You are mistaken: it is not hated.

But we are not writing a dev tool like wxWidgets.
We are writing a multi platform application.
This is not the same thing.

Therefore, and because we cannot test other compilers like VC++, we are
supporting *only* gcc, because gcc is the only one multi-platform compiler.
Unless I missed something, VC++ does not exist on Linux or OSX,
therefore it is useless for us.

Do not under-estimate the risk to support compilers we are not using:
Just remember the serious bug we had only with gcc 4.7.0 to 4.7.2 about
broken zone calculations with -O2 option.
I can say wxWidgets (mainly compiled with VC++) often has issues with
others compilers:
just try to compile it with mingw32+gcc2.8.1 !

And the fact you can compile Kicad with a given compiler is not enough
to be sure these binaries have no bugs (I mean no other than binaries
created by gcc).

Subtle bugs take long time to find them.

Can you seriously say:
VC++ has no bug: no need to test binaries created by it?
And my second question: are you volunteer to test and debug  Kicad under
VC++?

For core developers, the answer is just: *no*
I want to be clear:  we have the hands full with kicad+gcc.

And my last question ( I do not expect an answer):
Why do not submit a bug report to Microsoft?

-- 
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] KiCad patch sets break build

2013-11-14 Thread Andrew Plumb 
On 2013-11-14, at 1:12 PM, Wayne Stambaugh  wrote:
[deletia]
> It's incomplete so I will not commit the changes.  Of course you are
> free to use it in your own branch.  The problem is assuming that Boost
> 1.55 solves all of our problems (a dangerous assumption without
> testing), your fix will happily use any version of Boost that it finds
> not necessarily 1.55.  This is one of the limitations of CMake.  Many of
> the find package macros do not allow you to define a version test.  Of
> course, you could always write one.  If you decide to use your changes,
> please make sure if you file any geometry (PCB zones) bug reports, that
> you specifically state that you are not using the patched version of
> Boost.  Otherwise, you'll waste developers time chasing down bugs that
> may have already been fixed.

The default boost for MacPorts is still 1.54; I haven't tried 1.55, just peeked 
at the code-base to see where patches sit in relation to it.

Good to know about the PCB zones link.  The copper fill/exclude zone polygons 
have never displayed properly for me under any version of kicad on Mac 
(pre-4452 built or current) so I edit them in vi.  At least now I can see them 
when I switch to the OpenGL or Cairo canvas modes to visualize my edits!

Andrew.

--

"The future is already here.  It's just not very evenly distributed" -- William 
Gibson

Me: http://clothbot.com/wiki/



___
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] KiCad patch sets break build

2013-11-14 Thread Wayne Stambaugh 
On 11/14/2013 10:28 AM, Andrew Plumb wrote:
> On 2013-11-14, at 8:28 AM, Wayne Stambaugh  > wrote:
>> On 11/13/2013 10:44 PM, Andrew Plumb wrote:
> [deletia]
>>> Follow-up question time.  What's the motivation for telling
>>> CMakeLists.txt to explicitly build boost from scratch:
>>>
>>> include( download_boost )
>>>
>>> ...instead of trying something like
>>>
>>> find_package(Boost REQUIRED COMPONENTS date_time filesystem iostreams
>>> locale program_options regex system thread )
>>
>> Andrew,
>>
>> The long answer: there are three reasons.
>>
>> 1) Boost has a known bug in it's geometry library which requires patching.
>> 2) The KiCad developers were spending way too much time helping Windows
>> developers with Boost build and install issues.
>> 3) Many of the Linux distros Boost versions were lagging behind what we
>> needed.  In a perfect world, your solution is preferable.  Unfortunately
>> (or fortunately depending on your point of view) we don't live in a
>> perfect world so until the Boost geometry library is fixed, building and
>> installing Boost on Windows becomes less painful, and all the major
>> Linux distros package the latest version of Boost, we will continue to
>> build it as part of the the project.
>>
>> The short answer: it's the best solution for the largest target of
>> developers at the moment.
>>
>> Maybe this should be added to the FAQ on Launchpad.  I'm sure your not
>> the only person to wonder why we build Boost as part of the project.
>>
>> Wayne
> 
> Hi Wayne,
> 
> Many thanks for the insight!  The boost_cstdint.patch appears to be
> addressed in boost 1.55.0, so that should "go away" in the not too
> distant future.  The boost_minkowski.patch seems to be more of an
> unused-variables/compiler-warning resolution patch than
> function-breaking bug fix; devil's in the details so I wouldn't be
> surprised if it turns out to be more subtle than that.

Until it is accepted into Boost, we will have to use a patched version.

> 
> In light of these reasons, here's how I've reworked my patch to
> CMakeLists.txt to be APPLE-specific:
> 
> 
> 
> 
> You're welcome to integrate it into the main code-stream if it's
> acceptable, otherwise I'll be applying it externally so I can continue
> playing with KiCad.  I'm in no hurry to return to Eagle. ;-)

It's incomplete so I will not commit the changes.  Of course you are
free to use it in your own branch.  The problem is assuming that Boost
1.55 solves all of our problems (a dangerous assumption without
testing), your fix will happily use any version of Boost that it finds
not necessarily 1.55.  This is one of the limitations of CMake.  Many of
the find package macros do not allow you to define a version test.  Of
course, you could always write one.  If you decide to use your changes,
please make sure if you file any geometry (PCB zones) bug reports, that
you specifically state that you are not using the patched version of
Boost.  Otherwise, you'll waste developers time chasing down bugs that
may have already been fixed.

> 
> Thanks!
> 
> Andrew.
> 
> --
> 
> "The future is already here.  It's just not very evenly distributed" --
> William Gibson
> 
> Me: http://clothbot.com/wiki/
> 
> 
> 
> 
> 
> ___
> 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] Boost dependencies

2013-11-14 Thread Maciej Sumiński 

Today I saw an error during the boost build:
fatal error: bzlib.h: No such file or directory

Would not it be good to add bzip2 dependency to download_boost.cmake 
script, so users will get a clear message before an attempt to build the 
library?


Regards,
Orson
=== modified file 'CMakeModules/download_boost.cmake'
--- CMakeModules/download_boost.cmake	2013-11-12 12:44:30 +
+++ CMakeModules/download_boost.cmake	2013-11-14 16:22:33 +
@@ -58,7 +58,7 @@
 
 #
 
-
+find_package( BZip2 REQUIRED )
 
 string( REGEX REPLACE "\\." "_" BOOST_VERS "${BOOST_RELEASE}" )
 set( PREFIX ${DOWNLOAD_DIR}/boost_${BOOST_VERS} )

___
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] KiCad patch sets break build

2013-11-14 Thread Andrew Plumb 
On 2013-11-14, at 8:28 AM, Wayne Stambaugh  wrote:On 11/13/2013 10:44 PM, Andrew Plumb wrote:[deletia]Follow-up question time.  What's the motivation for tellingCMakeLists.txt to explicitly build boost from scratch:include( download_boost )...instead of trying something likefind_package(Boost REQUIRED COMPONENTS date_time filesystem iostreamslocale program_options regex system thread )Andrew,The long answer: there are three reasons.1) Boost has a known bug in it's geometry library which requires patching.2) The KiCad developers were spending way too much time helping Windowsdevelopers with Boost build and install issues.3) Many of the Linux distros Boost versions were lagging behind what weneeded.  In a perfect world, your solution is preferable.  Unfortunately(or fortunately depending on your point of view) we don't live in aperfect world so until the Boost geometry library is fixed, building andinstalling Boost on Windows becomes less painful, and all the majorLinux distros package the latest version of Boost, we will continue tobuild it as part of the the project.The short answer: it's the best solution for the largest target ofdevelopers at the moment.Maybe this should be added to the FAQ on Launchpad.  I'm sure your notthe only person to wonder why we build Boost as part of the project.WayneHi Wayne,Many thanks for the insight!  The boost_cstdint.patch appears to be addressed in boost 1.55.0, so that should "go away" in the not too distant future.  The boost_minkowski.patch seems to be more of an unused-variables/compiler-warning resolution patch than function-breaking bug fix; devil's in the details so I wouldn't be surprised if it turns out to be more subtle than that.In light of these reasons, here's how I've reworked my patch to CMakeLists.txt to be APPLE-specific:

kicad_CMakeLists_boost.patch
Description: Binary data
You're welcome to integrate it into the main code-stream if it's acceptable, otherwise I'll be applying it externally so I can continue playing with KiCad.  I'm in no hurry to return to Eagle. ;-)Thanks!Andrew.
--"The future is already here.  It's just not very evenly distributed" -- William GibsonMe: http://clothbot.com/wiki/


___
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] KiCad patch sets break build

2013-11-14 Thread Wayne Stambaugh 
On 11/13/2013 10:44 PM, Andrew Plumb wrote:
> 
> On 2013-11-13, at 10:11 AM, Dick Hollenbeck  > wrote:
>>> Hi Dick,
>>>
>>> Here's a least-invasive patch to get the boost component compiling on
>>> "APPLE" platform again:
>>>
>>> http://bazaar.launchpad.net/~andrew-plumb/+junk/download_boost_apple_cmake/revision/4463?compare_revid=4459
>>>
>>> In theory, the CMakeModules/download_boost_apple.cmake file should
>>> copy over the original
>>> CMakeModules/download_boost.cmake and "just work" for all platforms,
>>> but I'm not in a
>>> position to test that theory at this time.
>>>
>>> Gotta pick my battles. :-)
>>>
>>> Andrew.
>>
>>
>> Andrew,
>>
>> I do not understand this change.  If we look at your
>>
>>   ExternaProject_Add(),
>>
>> It looks like you are only copying the headers, and that is
>> insufficient to qualify as an
>> acceptable patch.  You are just kicking the can down road, in fact not
>> even that, kicking
>> it sideways.
>>
>>
>> I will not commit this change, sorry.
>>
>>
>> Dick
> 
> Follow-up question time.  What's the motivation for telling
> CMakeLists.txt to explicitly build boost from scratch:
> 
> include( download_boost )
> 
> ...instead of trying something like
> 
> find_package(Boost REQUIRED COMPONENTS date_time filesystem iostreams
> locale program_options regex system thread )

Andrew,

The long answer: there are three reasons.

1) Boost has a known bug in it's geometry library which requires patching.
2) The KiCad developers were spending way too much time helping Windows
developers with Boost build and install issues.
3) Many of the Linux distros Boost versions were lagging behind what we
needed.  In a perfect world, your solution is preferable.  Unfortunately
(or fortunately depending on your point of view) we don't live in a
perfect world so until the Boost geometry library is fixed, building and
installing Boost on Windows becomes less painful, and all the major
Linux distros package the latest version of Boost, we will continue to
build it as part of the the project.

The short answer: it's the best solution for the largest target of
developers at the moment.

Maybe this should be added to the FAQ on Launchpad.  I'm sure your not
the only person to wonder why we build Boost as part of the project.

Wayne

> 
> ...for existing installs, as is done for other dependencies like OpenGL,
> GLEW, Cairo, etc?
> 
> 
> KiCad builds fine when I reference the existing MacPorts boost 1.54.0
> install using the attached CMakeLists.txt patch, but I'm happy to modify
> the patch to be a simpler "if( APPLE )" conditional if it's likely to
> break others' Windows and Linux builds.
> 
> 
> 
> 
> Thanks!
> 
> Andrew.
> 
> --
> 
> "The future is already here.  It's just not very evenly distributed" --
> William Gibson
> 
> Me: http://clothbot.com/wiki/
> 
> 
> 
> 
> 
> ___
> 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] footprint library help needed

2013-11-14 Thread Brian Sidebotham 
On 13 November 2013 17:51, Carl Poirier  wrote:

> Coming from Mercurial, I prefer "branch, commit, push" rather than
> "checkout, commit". :P
>
>
Pushing with Bazaar is horrible. It works while you're the only editor, but
once other people start pushing too it will likely all fall over.

You're better off checking out to a local directory with something like
(assuming kicad-lib is whatever you're working on!)

bzr co lp:kicad-lib

Then branch locally:

bzr branch ./kicad-lib ./kicad-lib-updates

Work in kicad-lib-updates committing as many times as you want and using
version control locally. Occasionally it's good to update kicad-lib with
"bzr up" and then merge any changes to your local branch to make sure there
aren't any conflicts or people working on the same stuff as you.

Then when you're ready to commit:

cd kicad-lib
bzr up
bzr merge ../kicad-lib-updates

... Resolve any outstanding conflicts ...

bzr commit -m "My Updates"

This is more like my work flow with Bazaar anyway, and it allows you to
branch multiple-times locally so that you can work on several different
features at once. Local branches are extremely cheap and throwaway.
Branching from a remote location is not cheap.

Best Regards, Brian.
___
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] Vertical justify of the multiline text

2013-11-14 Thread Константин Барановский 
> Thanks, but where is the patch? (there is no attachment).

Sorry, my fault :)
I'm started to write the message at home but finished at work and forgot to
attach the patch.

Regards,
Konstantin.


2013/11/14 jp charras 

> Le 14/11/2013 07:17, Константин Барановский a écrit :
> > Wayne,
> > RotatePoint must be called twice. I'm added the comments to explain
> > why need both calls.
> >
> > jp charras,
> > I checked the display of text in PCBnew where to use multiline text
> > inside the zone.
> >
> > In attachment the edited patch where added comments and some
> optimization.
> >
> > Regards,
> >
> > Konstantin.
> >
>
> Thanks, but where is the patch? (there is no attachment).
>
> Multiline texts in zones do not uses exactly the bounding box.
> The bounding box is always an horizontal rectangle, which is not the
> case in zones (try a 45 deg multiline text)
>
> To show the bounding box, see TEXTE_PCB::Draw in class_pcb_text.cpp,
> line 110
>
> --
> 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/common/eda_text.cpp	2013-11-12 07:10:51.276582000 +0200
+++ kicad/common/eda_text.cpp	2013-11-14 07:15:22.95778 +0200
@@ -40,7 +40,7 @@
 // because the text position is sometimes critical.
 // Currently, this change is broken for rotated or mirrored texts,
 // so keep this line commented until there are fixes
-//#define FIX_MULTILINE_VERT_JUSTIF
+#define FIX_MULTILINE_VERT_JUSTIF
 
 // Conversion to application internal units defined at build time.
 #if defined( PCBNEW )
@@ -267,9 +267,13 @@
 {
 if( m_MultilineAllowed )
 {
-wxPointpos  = m_Pos;
 wxArrayString* list = wxStringSplit( m_Text, '\n' );
-wxPointoffset;
+
+wxPointpos  = m_Pos;  // Position of first line of the
+  // multiline text according to
+  // the center of the multiline text block
+
+wxPointoffset;// Offset to next line.
 
 offset.y = GetInterline();
 
@@ -290,7 +294,12 @@
 break;
 }
 }
+
+// Rotate the position of the first line
+// around the center of the multiline text block
+RotatePoint( &pos, m_Pos, m_Orient );
 #endif
+// Rotate the offset lines to increase happened in the right direction
 RotatePoint( &offset, m_Orient );
 
 for( unsigned i = 0; iCount(); i++ )
___
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