kicad-developers team mailing list archive

[Maciej Sumiński <maciej.suminski@xxxxxxx>]

On 01/06/2014 07:58 PM, Wayne Stambaugh wrote:
> On 1/6/2014 12:00 PM, Maciej Sumiński wrote:
> > I can fully understand that it is much easier for many users not to deal
> > with building boost library, but on the other hand - there are many
> > others who do not need a separate copy of boost just for KiCad.
> >
> > As far as I know, there are 3 main reasons to keep boost in KiCad
> > (https://lists.launchpad.net/kicad-developers/msg11692.html):
> > Ad 1) I guess the patch that fixes the geometry problem is
> > patches/boost_minkowski.patch. But inside there are only two lines
> > commented out and in fact they seem to be variables that are not even
> > used anywhere. How does that influence the function output? Or is not it
> > already solved by switching optimization options (already done in the
> > main CMake script)?
> > Ad 2&3) For those people included boost can make life simpler.
> >
> > So why not give a choice to build another copy or use the library
> > available in system? I came to the conclusion after having 8 different
> > branches, every of them containing compiled boost library. And it seems
> > that KiCad builds and works just as well using the boost library
> > included in my system.
> >
> > The attached patch:
> > - Adds a CMake option KICAD_BUILD_BOOST that enables building boost. If
> > you think that boost should be downloaded and built by default (I guess
> > that eg. KiCad-WinBuilder could be influenced by that), I can change it
> > to KICAD_SKIP_BOOST and satisfies me as well.
> > Besides that, boost can downloaded and built when an appropriate version
> > is not available in system.
> >
> > - Removes all context related files (common/system/*), as they are
> > anyway contained in boost and no longer necessary.
> >
> > - Removes the last traces of KICAD_STABLE_VERSION and
> > KICAD_TESTING_VERSION from bundled documentation.
> >
> > I look forward to your opinions. I tested it with boost 1.54.0-3 (that
> > is the reason why I put such version as required in CMakeLists.txt) and
> > gcc 4.8.2.
> >
> > Regards,
> > Orson
>
> Orson,
>
> I prefer building Boost myself but a little historical perspective is
> needed to understand why we opted to download and build Boost.  Long
> before the geometry library issues were the Windows build issues.  We
> (Dick, JP, and myself) spent a considerable amount of time helping
> Windows developers with Boost build issues.  There were also a lot of
> KiCad build bugs related to which version of Boost was installed on on
> Linux as well.

Thank you for the explanations. I expected that boost comes with KiCad 
to make building easier for some users, but I did not even think of bugs 
related to version of the library.

> Newer versions of Boost would break builds and the CMake
> FindBoost() macro only tests for a minimum version not a specific
> version.

It can be forced to check for specific version of the library using 
EXACT keyword. But I can imagine it helps only a little, as usually 
Linux distributions / Mac OS ports do not offer you a variety of 
versions, but the most recent one that was prepared by package maintainers.

> Finally the decision was made to use CMake to download and
> build a specific version of Boost for the sanity of the lead developers.
>   This way we had absolute control over the Boost version and then later
> the patches to fix the geometry library bug.  If memory serves, the GCC
> optimization fix was for a different bug than the geometry patch.  It
> finally became a choice of the lesser of two evils.  I'm not opposed to
> this change but it should come the a stern warning that if you choose
> build KiCad using the installed version of Boost on your system and it
> breaks *you* get to keep both pieces and not to expect a lot of help
> from the lead developers.

Sounds reasonable to me. In this case I will prepare a patch, that 
leaves building boost as the default option and displays a message if 
user decides to keep his version. After that, it will not break any of 
current build systems, but still allows to reduce build time/occupied 
disk space for every branch.

Regards,
Orson

> Wayne