kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@...>]

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