← Back to team overview

kicad-developers team mailing list archive

Re: Boost building as an option

 

On 06/gen/2014, at 21:27, Maciej Sumiński <maciej.suminski@xxxxxxx> wrote
> 
> 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.
Many of the issues I had on OSX are related to to wrong compilation or choices, restrict and be sure about which is the library used is a nice first step to be able to support users.


>> 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.
Maciej, package maintainers doesn’t do a good work as we have done I and Dick lately on boost, just take a look to the patches applied and the related tickets.
Our current boost patched release doesn’t exists already neither in the Development branch of boost.
The support in boost::context for OSX was almost NONE, there was a ticket laying there for 10 months, no option for building (i386/x86_64) no option at all for building PPC32/PPC64, options that now is in our repository and building.
The same is the support for GNU AS/MINGW on Windows.

Take a look to tickets url near the patches in the CMakeModules/download_boost.cmake file 

I’ll expect to see if boost 1.56 will contain those feature before moving on “normal distribution” channels.

Moreover i’m asking myself which is the best final distribution of kicad, i think that normal users will use binaries not a build from scratch, and i think that request normal users on the different platforms one version of library could be practicable with difficulties, i don’t see normal users install ports on OSX, additional libraries on Windows and moreover knowing well how works linux distributions that still have seasoned libraries on stable trees (RHAS , Debian Stable) and probably advance quickier on the more fast distributions (Fedora, Debian testing/unstable) having a large plethora of different flavour of configurations and releases to obfuscate tickets diagnose.

Same difficulties I will see deploying the software in an large organization and the interaction with systems for the configuration management.

Is this a good choice to pick ?

I build already for 2/3 platforms at once, i can understand better than all which are the problems/flags you are raising.

—
Marco


Follow ups

References