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?

Boost.Build and Boost.Jam IMHO are symbiotic at least until the Python Port is written you can't have one without the other.  I guess you could have some other tool such as Perforce Jam try and parse Boost.Build files, but as is stated it is a divergent fork with enhancements so this working is unlikely.  I haven't tried and don't have the toolset so I wouldn't know for sure.

Here is my understanding of Boost.Jam Boost.Build (and I am probably one of the confused - I think we should aways define what it is we are talking about before we furthur the confusiton - and by all means correct me if I have got it wrong... I probably do not fully understand)

1) Boost.Jam (bjam) is a tool which implements the Jam language (based on the performance jam language) as documented in Appendix A of the Boost.Build user manual (userman.pdf)
2) Boost.Build uses the Jam Language to generate a syntax it uses to parse through Jamfiles and to specify generators for producing output files form source files.  Now whether Boost Build is just considered Jamfiles, or Jamfiles and .jam (including generators and language defifntion) is unclear to me. 
3) Jamfiles contain a syntax for building taking source files and utilizing generators to produce output files.  Jamfiles are parsed by the Boost.Build system (Jamfile syntax) which is implemented in the Jam language.

I think it is easy for users to look at the above as a set of intersecting gray lines.  A build tool love triangle? :-)

If Boost.Build is Just the Jamfile specification then one would be hard pressed to build a Boost.Build qualified tool as one would have to reverse engineer bjam and the jam files to create it.  There is no "specification" that I am aware of such as EBNF specifying the syntax for the Jamfiles.  Is there?

Even from here:
It looks as though bjam is still used?  Or is this a 100% Python app?

I can only guess here , but if another tool (Jam like) such as the phyton port it will be rewritten in Phyton and not have a Python version of Jam tool(capable of parsing existing Boost.Build Jam files), but rather just be rewritten in Python and then there would be another fork? Yes/No? Reference below (PythonPort) says no, but what about when time goes on... would bjam syntax currently in Boost.Build die?  If so I will be the one at the funeral holding the multicolored balloons :-)

I briefly looked at the python port of Boost.Build and It looks as expected: A python port of Boost.Build in Phyton with no references to Jam style syntax, but capable of parsing existing Jamfiles

I would like to add another bullet to the above list and correct me if I am wrong:

Having to:

1) parse through the Boost.Build jam files each time bjam is called is a performance  penalty.  If Jam could create a precompiled cached version of the Boost.Build jam files then some time could be saved.

I think if I understand it correctly the ...patients... comes from the header file scanning.

As with anything, good user documentation can go along way with helping anyone to learn something.  From the user docs I have seen the following reoccur from version to version ( I believe in version 1.34.0 - 1.38.0)

Pg 69
(Need a note about UNIX)

Any idea when this note will be added? :-)

Pg 57
The information is this section is likely to be outdated and misleading.

When was it ever indated? :-)

I continue to use bjam as it is:
1) the most powerful easy to use syntax for building complex and simple projects (it scales well)
2) the bjam binary is build simply (just a compiler and a build.sh or build.bat file and your ready to go - minus the up and coming python stuff)
3) with simple commands builds using msvc, gcc, or cross compilers
4) Elegant text based build files which if done well do not contain much syntactic noise. (Jamfiles are clean)  Though I have seem some that are atrocious.  This is one of the main reasons I prefer not to use make.

What ever is decided please don't force me to use CMake ... I'll cry :-( 

Brian J. Davis