kicad-developers team mailing list archive

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

On 01/06/2014 10:46 PM, Marco Serantoni wrote:
> On 06/gen/2014, at 21:27, Maciej Sumiński <maciej.suminski@xxxxxxx
> <mailto: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

I really understand your view and appreciate your efforts, as thanks to 
your work KiCad is able to reach a wider group of users. In fact, one of 
the patches was proposed by me, as I had problem with a specific version 
of gcc and I am very glad that it was accepted. I also struggled to make 
our contribution work on the main platforms (Linux, Windows, Mac OS).
What I am trying to achieve is to reduce the time that is required to 
build KiCad. Maybe not everyone will appreciate that, as probably most 
of users builds KiCad every now and then (and CMakeLists.txt does not 
change so often), but I hoped it may help some developers. As I said - 
now I have 8 branches, but in total I went through many more. At CERN I 
have quite good hardware at my disposal that really speeds up 
development, but at home it is totally different.
Even if there is no appropriate boost package available for a Linux 
distribution, people may have an option to build boost once (I guess it 
should be possible to install it somewhere as well) and then other 
branches may just use that version.
With regard to the above, I am not voting for full removal of boost, as 
I still see the point of simplifying the build steps. All I ask for is 
one switch. As Wayne suggested - if boost building is enabled by default 
and there is a clear warning that disabling it is done on one's own 
responsibility, then it should be enough to keep the build procedure 
simple and discourage people who are not sure if the option should be 
applied or not.
If everyone agrees that it is just a bad idea, then I am not going to 
insist any further, but I do not think it may cause any serious harm.

Regards,
Orson