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:48:47

These are some emails between me (Mike Jackson) and Denis about how to move
forward with Boost-cmake. Troy started this wonderful project but now needs
some help. Denis and I are ready to step up and help where can but we need
some support from the rest of the community.

* How do you want the Boost-CMake project to be focused? Do you want to have
a constant clone of the upstream SVN Trunk and Release branches?

* Do you want just a Boost-CMake git repo where you can get each official
release where the cmake files have been integrated and updated for each
release?

* Other comments are welcome. Specifically on what are good naming schemes
for the various boost-cmake branches and such.

All comments (good, bad, ugly) are welcomed and encouraged.

Thanks for everyone's continued support.
Mike Jackson

2010/8/26 Michael Jackson <mike.jackson_at_[hidden]>
> I think we should only have the "cmake-*" branches since the focus of the
> project is to have a cmake version of official boost.

What I mean is that, today, on Gitorious, we replicate, from Subversion,
only the trunk (named "master") and the release branch (named "release").
Whereas, in Subversion, there are many more branches and "tags" (which are,
in fact, other Subversion branches).

Of course, we could replicate all the Subversion "tags", which reflect the
exact content officially released, at least for the source code (the
documentation is delivered with another process, as I understand). But it
would mean to lose the whole corresponding history in Git... and duplicating
A LOT of content (each release has roughly a 300MB footprint; it means it
would take around 1.2GB per year!)

Whereas, if you keep in Git, as of today, only the trunk and the release
branch, we would then be able to create a branch in Git for every Boost
release (and check that the content be rigorously identical to upstream),
while keeping the full history and while much reducing the global footprint
on the server disks.

As, on Gitorious, it's easy to display a small description for each
repository, then we can show the link to the corresponding Subversion
trunk/branch/tag. But I would rather rename those on Gitorious with clearer
names, such as "pristine-xxx", where xxx is {"trunk", "release",
"1.44.0-rc", "1.44.0", "sandbox1", "locale", etc.}.

>  I just checked the main SVN boost repo and you are right, the cmake files are
> gone. That sucks. Wonder where I was on during that discussion.

A hint on how to search on the Boost ML archive:
http://groups.google.com/group/boost-developers-archive/search?group=boost-d
evelopers-archive&q=cmake&qt_g=Search+this+group :)
=> 
http://groups.google.com/group/boost-developers-archive/browse_thread/thread
/df79262dc79e369e/8ad25d5fb296957f?lnk=gst&q=cmake#8ad25d5fb296957f
(and you will get the full thread)
 
> I usually monitor the boost-users newsgroup.

I monitor the boost newsgroup (which corresponds to Boost developers,
indeed: http://groups.google.com/group/boost-developers-archive/about)
 
>  I will see if I can get Troy's svn-tracking scripts setup on my server so
> that we can constantly track the changes from upstream Boost.

It would be great. 
 
> Please continue to use your own repos until we get all of this sorted out.

OK, no problem, I will.

Kind Regards

Denis

On 8/26/10 11:44 AM, in article C89C042F.1405E%mike.jackson_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 <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