Re: [Boost-cmake] Discussion of Boost-cmake moving forward

Subject: Re: [Boost-cmake] Discussion of Boost-cmake moving forward
From: Michael Jackson (mike.jackson_at_[hidden])
Date: 2010-08-26 11:44:47

2010/8/24 Michael Jackson <mike.jackson_at_[hidden]>
> I think we should have a branch for each boost release where people can go to
> get
> boost with cmake and only have changes to the cmake files themselves
> and not really the boost source files.

Having a structure reflecting upstream Boost seems a good thing, i.e.:
* Git pristine-release reflecting SVN branches/release
* Git pristine-master reflecting SVN trunk
* Git pristine-1.44.0 reflecting SVN tags/release/Boost_1_44_0

Then, having the same structure for CMake-ified Boost seems also not too
bad:
* Git cmake-release reflecting CMake on top of SVN branches/release
* Git cmake-master reflecting CMake on top of SVN trunk
* Git cmake-1.44.0 reflecting CMake on top of SVN tags/release/Boost_1_44_0

Now, I am not sure which is the best, between having in the cmake-xxx
branches only the CMake additional files, or the whole CMake-ified Boost. I
would choose the second option, as Git helps a lot in maintaining such a
structure: upstream Boost patches are easily applied on the CMake-ified
version (by Git, almost transparently). That option has the advantage for
the developers to be complete: they do not have to fetch on one side Boost
files, and on the other one CMake files, and then merge both file
structures.

 
>  The main gitorious.org/boost <http://gitorious.org/boost>  has an SVN
> tracking branch. Troy would like someone else to take over
> that for the time being. He runs a CRON script every so often that pulls
> changes from SVN and pushes those to the git repo. I think I have SVN write
> access to the main Boost repo. Maybe I should be the gatekeeper for changes to
> the cmake files that get posted to gitorious?

Gitorious does not allow to import SVN repositories. So, I was wondering how
Troy was doing the synchronisation. GitHub allows Subversion imports, but
I'm not sure that it allows for synchronisation, after initial import.
So, the only way is maybe to run, like Troy does, a cron somewhere on an
Internet machine (I got one, if needed).

> What type of developer are we serving? The dev who wants to work with Boost
> and Git would seem to be the case.

I think it's more open than that: all the developers wanting to build Boost
with something more standard than BJam. For instance, I was not a big fan of
Git, and I "converted myself" for Boost-CMake...
I guess that all the Linux and MacOSX distribution packagers will be
interested, as CMake becomes increasingly a standard way to build packages.
I "work for" Fedora/RedHAt, but Debianers, Ubuntuers, "Madrivaners", etc,
may as well be interested.
Plus all the occasional developers finding BJam rather difficult to
understand (and to integrate with their own software!).
 
> I think the main Boost SVN repo does retain the CMake files so anyone can get
> the boost with cmake from the main boost site.

There was a discussion on the Boost ML a few months ago, and they decided to
remove support for CMake (and to remove the corresponding CMake files),
saying that some external developers were maintaining that non-official way
of building Boost...
So, let's assume that upstream Boost will not help us that much.

Cheers

Denis

On 8/26/10 11:41 AM, in article
E6A92AED-DA5D-487B-8502-2A5910D3398A_at_[hidden], "Michael Jackson"
wrote:

> 
> 
> 2010/8/24 Michael Jackson
> <mike.jackson_at_[hidden]>
> I think we should have a branch for each boost release where people
> can go to get
> boost with cmake and only have changes to the cmake files themselves
> and not really the boost source files.
> 
> Having a structure reflecting upstream Boost seems a good thing, i.e.:
> * Git pristine-release reflecting SVN branches/release
> * Git pristine-master reflecting SVN trunk
> * Git pristine-1.44.0 reflecting SVN tags/release/Boost_1_44_0
> 
> Then, having the same structure for CMake-ified Boost seems also not
> too bad:
> * Git cmake-release reflecting CMake on top of SVN branches/release
> * Git cmake-master reflecting CMake on top of SVN trunk
> * Git cmake-1.44.0 reflecting CMake on top of SVN tags/release/
> Boost_1_44_0
> 
> Now, I am not sure which is the best, between having in the cmake-xxx
> branches only the CMake additional files, or the whole CMake-ified
> Boost. I would choose the second option, as Git helps a lot in
> maintaining such a structure: upstream Boost patches are easily
> applied on the CMake-ified version (by Git, almost transparently).
> That option has the advantage for the developers to be complete: they
> do not have to fetch on one side Boost files, and on the other one
> CMake files, and then merge both file structures.
> 
> 
> The main gitorious.org/boost has an SVN tracking branch. Troy would
> like someone else to take over
> that for the time being. He runs a CRON script every so often that
> pulls changes from SVN and pushes those to the git repo. I think I
> have SVN write access to the main Boost repo. Maybe I should be the
> gatekeeper for changes to the cmake files that get posted to gitorious?
> 
> Gitorious does not allow to import SVN repositories. So, I was
> wondering how Troy was doing the synchronisation. GitHub allows
> Subversion imports, but I'm not sure that it allows for
> synchronisation, after initial import.
> So, the only way is maybe to run, like Troy does, a cron somewhere on
> an Internet machine (I got one, if needed).
> 
> What type of developer are we serving? The dev who wants to work with
> Boost and Git would seem to be the case.
> 
> I think it's more open than that: all the developers wanting to build
> Boost with something more standard than BJam. For instance, I was not
> a big fan of Git, and I "converted myself" for Boost-CMake...
> I guess that all the Linux and MacOSX distribution packagers will be
> interested, as CMake becomes increasingly a standard way to build
> packages. I "work for" Fedora/RedHAt, but Debianers, Ubuntuers,
> "Madrivaners", etc, may as well be interested.
> Plus all the occasional developers finding BJam rather difficult to
> understand (and to integrate with their own software!).
> 
> I think the main Boost SVN repo does retain the CMake files so anyone
> can get the boost with cmake from the main boost site.
> 
> There was a discussion on the Boost ML a few months ago, and they
> decided to remove support for CMake (and to remove the corresponding
> CMake files), saying that some external developers were maintaining
> that non-official way of building Boost...
> So, let's assume that upstream Boost will not help us that much.
> 
> Cheers
> 
> Denis