Boost Interest :
Subject: Re: [Boost-cmake] Boost-CMake with recent changes from upstream
From: Michael Jackson (mike.jackson_at_[hidden])
Date: 2010-08-17 17:42:59
On 8/17/10 2:32 PM, in article
AANLkTinXf25=FoHAgs_chbXGVQ=5x8JNGP6z4429dYm1_at_[hidden], "Denis Arnaud"
> 2010/8/17 Michael Jackson
>> So I saw the announcement that Boost 1.44.0 had been released. I took a
>> around www.gitorious.com/boost and noticed that the following:
>> is a clone that is keeping up with the latest releases and HEAD from
> You do have sharp eyes :)
> Indeed, now, the only difference between the newly released Boost-1.44.0
> version and that Gitorious-hosted Git branch is made of the "CMake
>> There are some small issues still with using the boost-cmake installation
>> with it's default settings and CMake's own "FindBoost.cmake" file.
> You are right. For instance, in Fedora, Boost own support for CMake is no
> longer shipped with the Boost RPM package, as it hindered some other
> software components to build correctly:
Looking at the bug my first inclination is to just not have those files
installed on linux machines. I have no idea what the deeper issues are or
how to solve them. If the issues are to just have the files not installed by
default then we can fix that pretty quick and let Fedora start using the
CMake files again.
Someone with more Linux experience should chime in here with a better
> If you give me your Gitorious username, I can add you as an administrator of
> my Git repository. Also, if you have better ideas for the Gitorious
> repository organisation, names or management, do not hesitate: I would be
> happy to derive from any other Git repository you deem relevant.
I think we should name branches closely to what they are mirroring. For
instance on another project I work with (HDF5) there is a branch that
mirrors the upstream SVN repo which we call "svn-mirror". We should do this
with the releases as well. So either tag or branch git with the 1.44.0-cmake
branch to make it obvious which branch is what.
Just my thoughts. I also think we should maybe revert back to an
installation scheme that is the same as how bjam would do it. This gives up
maximum compatibility with current projects and cmake itself. We can have
options to have alternate layouts if people still want them.