Re: [Boost-build] Jam rename?

Subject: Re: [Boost-build] Jam rename?
From: Brian Davis (bitminer_at_[hidden])
Date: 2009-04-06 13:11:40

>
>
> 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:
http://zigzag.cs.msu.su/boost.build/wiki/PythonPort/Quickstart
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

From:
(http://zigzag.cs.msu.su/boost.build/wiki/PythonPort)

   - No user knows that language, making it hard to extend Boost.Build or
   become new developer <- I can personally totally relate to this having to
   create my own generators.
   - The language is strange at times, and not very nicely documented. <- if
   what is meant by "not very nicely documented" meaning that one had to read
   the source of Jam and have all the .jam files of Boost.Build open to see
   "real world examples" of how to use it then yes it is not well documented.
   ;-)  Then there are those surreal epiphanies one must have when understating
   how Jam works.
   - There's no standard libraries, so every new functionality should be
   implemented from scratch <- For performance reasons it is not clear if this
   should occur in Boost.Build .jam files or in Jam itself.
   - The only data structure in the language is list of strings. This makes
   many tests cumbersome, and leads to excessive memory consumption and poor
   performance on some workloads. (I got no comment on this one)

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