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

Subject: Re: [boost] Git Modularization Review no vote heads-up
From: Bjørn Roald (bjorn_at_[hidden])
Date: 2013-05-24 18:04:51

On Thu, 2013-05-23 at 23:06 -0700, Dave Abrahams wrote:
> on Thu May 23 2013, Bjørn Roald <bjorn-AT-4roald.org> wrote:
> 

> > 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.

I understand that point of view, but if historic Jam could be used by
itself, why not have them as separate modules?

> > 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

I was not aware there is a single line of history here - in case it is
it may be worth trying to re-join the histories if that is done by the
conversion.  but it seems odd to re-introduce tools/jam in
tools/build/jam, a new place where it has never been -- and move
tools/build to tools/build/build, where it has never been. 

> > 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.

Well, are you saying I can check out any boost historic version from 
http://github.com/boostorg/boost and run the instructions of that
release to successfully build?  Those instructions will fail as
structure of those historic commits are changed beyond moving the
headers. The changes in tools/build is a prime example.

> > 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.

so are you are saying you will have some commit the build repository
history show how files are moved from tools/build/jam where they never
have been to tools/build/build/v2/engine where they never went?  Even if
you manage to make such a commit, how is that preserving file structure
in the history?

> >> > 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.

Ok,  it is just the obvious I guess I am trying to confirm, sorry for
not being clear here and having to explain these things you know much
better than me - feels very odd. But I will try to explayn what I mean.

There are jam files all over the place -- to find the files that have
jam in name. The command

@ find | grep -i jam | grep -v tools/build 

does not provide complete list of all build related scripts outside of
tools/build, but it will list a lot of build stuff that will not be part
of build repository I presume, some of these are in the top level
directory 

./project-config.jam
./Jamfile.v2
./Jamroot.jam
./boostcpp.jam

and they may end up staying there, i.e. not become part of any of the
new submodules, candidates are :

in addition bootstrap.(sh|bat) are part of the build system.  With file
structure changes in history for tools/build and tools/jam, these and
their past siblings are surly broken. 

In addition files in lib/*/build/ directories that belong to the
respective lib/* submodules does not go into build repository, right?

Nevertheless I struggle with understanding the intension of some of the
entries for the build repository in
https://github.com/ryppl/Boost2Git/blob/master/repositories.txt so there
may be intention to do more than the current converted repositories
reflect and I expect here.

--
Bjørn