Re: [boost] Git Modularization Review no vote heads-up

Subject: Re: [boost] Git Modularization Review no vote heads-up
From: Dave Abrahams (dave_at_[hidden])
Date: 2013-05-24 02:06:16

on Thu May 23 2013, Bjørn Roald <bjorn-AT-4roald.org> wrote:

> On Thu, 2013-05-23 at 06:44 -0700, Dave Abrahams wrote:
>> on Thu May 23 2013, "Jürgen Hunold" <jhunold-AT-gmx.eu> wrote:
>
>> > I think that a one-to-one mapping like:
>> >
>> > repository build : common_branches
>> > {
>> >   submodule of "boost" : "tools/build";
>> >   content
>> >   {
>> >     "tools/build/" ;
>> >   }
>> >
>> > is the way to go now. If something goes wrong, 
>> 
>> It will, because we'd no longer be catching tools/jam throughout
>> history.  That will cause modularization to fail.
>> 
>> > please put "tools/jam/" somewhere else.
>> 
>> Yeah, that's not specific enough.  What is "somewhere else?"
>
> Why not in a separate repository called jam that are referenced only in
> relevant past commits of boost meta repository?  

We can do that.

> Boost.Build would not
> be the only submodule with dependencies to other submodules, would
> it...

Yeah, but as Boost.Build is really the *only* client of Boost.Jam, it's
hard to justify separating them.

> This build --> jam dependency is also gone in current boost, 

I don't think so:
http://ci.boost.org/svn-trac/browser/trunk/tools/build/v2/engine

> so I don't understand the need to bundle all in one repository.  It
> complicates the conversion and changes file structure in history.

I don't know what you mean by "changes file structure in history" or how
you conclude that it complicates the conversion.

> It is better to try as far as feasible to make the conversion an
> accurate reflection of history while getting a sensible set of
> repositories representing modularized libraries.  Build is no a library,
> and as a tool the modularization is good enough with two historic
> repositories and a build --> jam dependency in the past. Current build
> repository is self contained if I understand this correctly.

It's only self-contained because it contains jam in its "engine"
directory.  If Boost.Jam is going to be there in the present, its
revision history should be there in the past, so you can follow it.
>
>> > Btw. would
>> >
>> > repository build : common_branches
>> > {
>> >   submodule of "boost" : "tools/build";
>> >   content
>> >   {
>> >     "tools/build/v2" ;
>> >   }
>> >
>> > be the right way to move v2 one directory up?
>> 
>> That would move the contents of v2 to the top level of the build repo,
>> but it would also drop all the commits that historically went directly
>> into tools/build/ (Boost.Build v1 mostly).  Like I said, we need
>> decisions about where *everything* that was in Boost.Build—throughout
>> history—belongs.
>
> Agree that this is not smart or needed to be done in the conversion.
> This step could be done with git mv at a convenient time after the
> conversion.  No real need to do that as part of the conversion - it
> complicates and obfuscates. 
>
> Other build related files are in their respective repositories, this
> could (or should) also be the case for all top level scripts that is
> part of boost meta repository.  

I don't know what you mean here either.  Specifics, please.

> Is it really a pure meta repository anyway?

I'm afraid it's not pure at all.

-- 
Dave Abrahams