Re: [Boost-build] Jam rename?

Subject: Re: [Boost-build] Jam rename?
From: Vladimir Prus (ghost_at_[hidden])
Date: 2009-04-06 11:06:22

On Monday 06 April 2009 18:03:46 Rene Rivera wrote:
> First, sorry it took so long to reply to this thread... Been busy :-\
> 
> Vladimir Prus wrote:
> > Quite a number of folks tend to confuse Boost.Build and Boost.Jam,
> > which is not only bad for "marketing" purposes, but also leads to people
> > not understanding Boost.Build exists, has to be installed, has a version
> > number, and all other kinds of confusion.
> > 
> > While previously Boost.Jam was close to Perforce Jam, it is presently
> > a permanent and considerably diverged fork. In light of that, what would
> > be the opinion about renaming 'bjam' binary into something. I don't want
> > to propose any specific name right now, but I'm interested in the opinion
> > as to such rename will do more harm than good, or not?
> 
> Generally I don't have a problem with renaming bjam. But I do worry that 
> renaming it as a whole will not actually fix the branding problem. 
> Although it might partially fix the BB vs. bjam confusion within Boost. 
> I think that in order to make a rename effective it would also have to 
> come with ditching of the Perforce/Jam vestiges. What I have in mind, at 
> a minimum, would be to take Johan's suggestion of "bb" as the exe name. 

Yes, surely leaving the executable name the same will lead to confusion.
I was thinking that 'b2' would be a better-sounding name. 

> And removing the compiled in Perforce/Jambase making BBv2 the only option.

Yes, that would be good too.

> 
> But even with that I worry about the implications this has for doing 
> releases. Since bjam and BBv2 releases are totally independent. Hence 
> the confusion might still be there. And the only way I can see to remove 
> that confusion is to bundle both bjam and BBv2 in the same release 
> *always*. 

That will also fix the confusion between Boost.Jam and Boost.Build
version numbers.

> Which is not a convenient arrangement since it could make 
> doing releases a bit more work.

I am not sure this is significantly more work. Say, all the work of generating
Boost.Build documentation, and then packing everything is already done as
a script that runs nightly. Am I mistaken?

- Volodya