← Back to team overview

kicad-developers team mailing list archive

Re: Boost headers, again


Wayne Stambaugh wrote:
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: ==
# 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

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:


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.


In the end, folks just wishing to compile the system, will not even know that boost is being used.



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.

No objections. It was work that should never have been done, never have been committed. It was the wrong program to augment with Python, "kicad" instead of pcbnew or eeschema, and it brings nothing to the table. All the python work is contained in the project manager "kicad", and the value it brings is nil.

Swig or DBUS should be looked at when revisiting this issue. And that work should be focused on eeschema and pcbnew. The Python world needs to cross the bridge into 3.0 before I get excited about it again.