Re: [Boost-build] Boost build improvements

Subject: Re: [Boost-build] Boost build improvements
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2010-05-25 02:03:52

AMDG

Wesley Johnson wrote:
> I am on this mailing list because I had problems building Boost, and I still
> do not have a working Boost after 6 months of poking at it.
> I am working on a free-software release of my own, spending my time on that,
> so I do not have time to dive into Boost problems now.
> I have a Linux system, and I did not expect to have that much trouble with
> this.
>   

The main problem appears to be that you were using a compiler
that we no longer test with.  Since we're not actively testing it,
some bugs have apparently crept in.

> I wanted a tool to use on my project, it required Boost, Boost required Lua,
> etc...

How does Boost require Lua?  It shouldn't.

>   I now have all these libraries installed, extraneous to all my other
> work, and Boost is still not working, usable, or trustworthy.
>
> Why, has to do with what you have been discussing about the next release of
> Boost-build !!
>
> There is no sense of control over what is happening with the build.
> Boost-build does all these things, and if it is getting something wrong or
> if the library is just busted, I cannot tell.

You can run the tests.  (run bjam in the test directory of a library).

> I have no idea of how to get
> some control over Boost, especially how to correct system dependent things.
> The fact that experienced Boost users can relish the fact that they are
> among the few that know how to make Boost-build do something, is like
> watching some skateboarder jump on stairway railings.  I do not have any
> wish to join in, I have already seen enough accidents to know better.
>   

The standard way to build Boost is documented.  If it
doesn't work, then it's a bug.  (Of course, some libraries
may fail to build because of compiler defects, but that's
another issue.)

> Boost needs to put the system dependent controls somewhere where the new
> user can find them, and point a big glaring red arrow at them.
> The new user is the one who has to alter them to get this huge thing to
> boot-up !!
>   

Most users shouldn't have to mess with the scripts.
I'm not convinced that a big red arrow wouldn't
do more harm than good, as it would be a distraction
in most cases.  It would of course be counterproductive
to put big red arrows pointing to everything that
anyone needs.

> There has to be some instructions as to which files to touch, which not to
> touch, and where the likely problems exist.
> Make and Makefile have dealt with this problem.  They may have other
> problems, but at least you know where to go and start hacking at it.
>
> There needs to be some independence of the parts, especially in the Boost
> libraries.  I had to download the entire Boost, just to get the few
> libraries that the tool needed, because it was so difficult to deal with a
> detached library with no method to compile it without the entire Boost-build
> system.  I says that you can get individual libraries, but does not support
> making them work that way (not that I could find).
>   

Where does it say that you can get individual libraries?
It's fairly easy to build a single library.  (bjam --help in
the root of the boost tree describes the options)

> I would rather see separate files for each system, than one file trying to
> deal with all systems.
>   

Maintaining separate build scripts for different platforms
is simply impractical, IMHO.

> It is easier to find the one file for Linux, put the other away somewhere
> else, and try to beat on the errors and bugs with only a few files to
> consider.
> Trying to find errors among 20 files is not reasonable, and among 200 files
> is impossible.
> .
> There has to be one tool that boots the rest of the tools.
> Every compiler system invented has had to deal with this problem.   They
> usually try to get the compiler working well enough that it can compile
> itself.   There is phase1 compiler that is just good enough to compile the
> phase2 compiler.  The phase1 compiler is simple enough that is can be
> compiled on a wide variety of systems, and may be written in multiple
> languages.  The user picks the phase1 compiler that they can build most
> easily.
>
> The boot system has to have support for whatever the user may have.
> Just look at all the ways Linux can be installed.  Install using root
> floppies, install using windows, install using existing Linux, install with
> GRUB,
> install using bootable CDROM.
> Trying to make Boost-build be installed from ONLY ONE kind of installation
> will cause as much trouble as the current situation.
>   

The current system requires--a C compiler.  It's hard to
get more basic than that, since you have to have a C++
compiler to use Boost at all.

> It needs a Makefile, an installation script, a windows scripts, etc..., all
> of which can succeed on a new system without any other Boost components, and
> preferably without Lua or any of those other strange libraries.
>
> You are trying to rely upon other "system-independent" tools to make it easy
> for you.  That makes it difficult for me.  Now I have to install all these
> other "system-independent" libraries, each which has its own problems, and
> for which I have no other use.   Lua is intersting, but I have no use for
> another scripting language.  Please do not try to sell it to me, as far as
> this discussion goes, it is just another requirement that complicates the
> whole mess.
>   

I don't understand.  Boost should have no required
dependencies outside of the distribution.

> Making Boost-build dependent on having boost libraries,  -- cannot be
> good -- ...
>   

Regardless of what happens, there will have to be a
shell script and a Windows batch script to build bjam.
That's where it starts now, and I don't see this changing.

In Christ,
Steven Watanabe