kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@...>]

Dick Hollenbeck wrote:
> Wayne Stambaugh wrote:
>> Dick Hollenbeck wrote:
>> 
>>> There are unnecessary difficulties with the way we are asking developers 
>>> and builders to provide the Boost headers:
>>>
>>>
>>> 1) The CMake find boost script seems to want all the compiled stuff, 
>>> 
>> I'm confused because the FindBoost macro does not fail unless it cannot
>> find the Boost headers >= 1.36 the way it is being used in Kicad. I
>> added the version string "1.36" to the FindBoost macro call to prevent
>> the compile error when Boost is < 1.36. Granted FindBoost does not fail
>> gracefully when it finds the wrong Boost version. It should tell you
>> that Boost 1.36 or greater is required and you have version "foo"
>> installed rather than just complaining that Boost was not found when the
>> version is below the requested version. This would give packagers a
>> clue as to why FindBoost failed. I tested this to make sure that worked
>> properly with both windows (MINGW/MSYS) and on linux (Debian testing).
>>
>> Here is a snippet from FindBoost.cmake from CMake version 2.6.4:
>>
>> # Usage of this module as follows:
>> #
>> # == Using Header-Only libraries from within Boost: ==
>> #
>> # find_package( Boost 1.36.0 )
>> # if(Boost_FOUND)
>> # include_directories(${Boost_INCLUDE_DIRS})
>> # add_executable(foo foo.cc)
>> # endif()
>> #
>> # == Using actual libraries from within Boost: ==
>> #
>> # set(Boost_USE_STATIC_LIBS ON)
>> # set(Boost_USE_MULTITHREADED ON)
>> # find_package( Boost 1.36.0 COMPONENTS date_time filesystem system ... )
>> #
>> # if(Boost_FOUND)
>> # include_directories(${Boost_INCLUDE_DIRS})
>> # add_executable(foo foo.cc)
>> # target_link_libraries(foo ${Boost_LIBRARIES})
>> # endif()
>> #
>>
>> FindBoost only searches for the compiled libraries if you request them.
>> Are we confusing "apt-get libboost-dev" pulling in all of the
>> recommended Boost stuff and what FindBoost actually looks for. That was
>> what I was understanding from the last thread about the Boost compile
>> problem.
>>
>> 
>>> even though we only need the headers.
>>> 
>> This is true as long as we do not want to resurrect the Boost Python
>> code. Otherwise, we will need the compiled Boost Python library.
>>
>>
>> 
>>> 2) The installation is cumbersome on some platforms, and varied, making 
>>> it difficult to provide a cohesive set of instructions.
>>> My suggestion after reviewing the Boost Software License, found here:
>>>
>>>
>>> http://www.boost.org/LICENSE_1_0.txt
>>>
>>>
>>> is that we simply include the headers that we need in the Kicad tree, 
>>> and I want to put them in include/boost
>>>
>>>
>>> I volunteer to do this and clean up the entire boost mess during the 
>>> next two weeks if there are no objections.
>>> 
>> I'm not objecting. It just seems to me that your time could be better
>> spent on the project. It feels like a solution in search of a problem
>> to me.
>>
>> 
>>> I plan on putting the headers we need in include/boost along with the 
>>> Boost Software License.
>>> 
>> I would prefer that we use FindBoost to search for Boost the system
>> first, then fall back to Boost headers in the kicad source unless we are
>> going to be very diligent about keeping up with Boost. It might be nice
>> for development purposes to use something shiny and new ( read useful )
>> in Boost and then update the version that ships with the Kicad source
>> before a commit is made.
>>
>> Wayne
>>
>> 
>>> In the end, folks just wishing to compile the system, will not even know 
>>> that boost is being used.
>>>
>>>
>>> Dick
>>> 
> 
> Wayne,
> 
> You make some good points. But on balance the convenience to Windows 
> users and to those who have packages older than what we require in their 
> linux distribution weighs greater than other concerns IMO. 
> 
> The boost installation problem literally goes away with this solution. 
> Your email dwells on detection. I'm dwelling on installation.

You could make the same case for any of the Kicad dependencies. I am
just worried that this same kind of thing will happen when we bump
wxWidgets from 2.8.10 to 2.10.0. Are we going to have the same kind of
issues on the developer list when someone attempts build Kicad and
FindwxWidgets fails? Do we need to be doing a better job of
communicating the project build requirements? Including the Boost
headers is one thing. Including wxWidgets is something altogether
different. Ah, maybe I'm just getting grumpy in my old age:)

> We will probably not go back to BoostPython, so that limited probability 
> should not be the tail that wags the dog, IMO.

Agreed. We should consider removing the Boost Python code from Kicad if
we aren't going to use it.

Wayne

> 
> Dick