Re: [boost] Re: Boost.Build on IBM, SGI & HP

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-10-11 11:02:27

----- Original Message -----
From: "Eric Ford" <eford_at_[hidden]>

> > > The boost documentation is long.
> > Are you referring to http://www.boost.org/tools/build/, or to
> > http://www.boost.org/tools/build/build_system.htm ?
>
> The combination.  First, I think anyone who bothers to write
> documentation should be praised.  Obviously something powerful often
> needs lots of documentation.  It's just that I and other end users
> would much rather just type one word and not have to read anything
> other than a short README that says "to compile type jam, to test type
> jam test, to install type jam install"

Aside from -f<allyourbase.jam> that stuff works (well, install isn't
handled, because I don't know what it should do -- that's a separate
platform-dependent problem).

> > What in particular did you find to be complicated?
>
> The only things I tried were to get it to build only one library and
> to get it to build only one version of that library.  (No need to
> explain how.)  Also, I tried to add a dependancy with a rule to run a
> program to generate a file.

Ah; what rule was that?

> > I do need some feedback about what mechanism would be acceptable for
> finding
> > the build system source. A .jamrc file has been suggested, but that
> begs the
> > same question: "where is the .jamrc file located?" In the absence of
> better
> > suggestions, I intend to use an environment variable setting.
>
> Do you mean an env variable to say where to look?

Yes.

> Can it have some
> defaults (e.g current directory, home directory, /etc/,)?

Sure, but notions such as home directory and /etc aren't portable.
If you can tell me how to choose reasonable defaults for various platforms,
it's easy to set them up.

> So most
> people wouldn't need to set an env variable ?  Env variables can cause
> problems when you make a change since they don't synchronize across
> all shells.
>
> > > or 'jam gcc'? Even 'jam
> > > -sTOOLS="gcc"' seems too complicated.
> >
> > Interesting. You're suggesting that a pseudotarget with the same
> name as the
> > toolset should build all targets that would be built with that
> toolset? I
> > like that idea, but there are a few problems with it:
>
> Actually, I was thinking of `which gcc`, `which kcc`, `which CC`,
> etc., until it found something.

It's not possible to do it in exactly that way with the current Jam unless
you cause it to be invoked recursively (and I'd rather avoid that). Jam has
one phase during which rules are executed and the dependency graph is built,
and another where build actions are executed. The latter phase is the only
one where shell commands can be run.

The way I'd handle this with the current Jam is to make the targets to be
built with gcc depend on the gcc executable and set SEARCH on gcc to
$(PATH). If gcc weren't present, Jam would say:

"skipping <target name> for lack of gcc"

Of course, I could modify Jam to be able to do what you're suggesting.

> I'd suggest the search be from
> comercial 3rd party (e.g. KAI), to vendor provided (e.g. SGI), to
> generic (eg. gcc).  I presume most people want it built with their
> "best" compiler.

I think that depends on who the person is. I'm primarily trying to serve
developers with Boost.Build, so that they have a chance of installing a pile
of compilers and testing their code on all of them without knowing too much
about the details of any one. I figure that if we can do that, it should be
easy to take the very few steps needed to make build/test/install trivial
for users.

Is "jam gcc" really too much to ask of users?

> > Aside from being condemned to years of debugging (that part seemed
> > unneccessarily ad-hominem), I appreciated hearing your thoughts. I
> would
> > like to hear more from other users.
>
> Sorry about that.  I didn't mean it to be ad-hominem.  For some reason
> I assumed that came from some Jam developer.

The ability to replace the built-in Jambase with "-f..." came from Perforce;
the name of the file was mine, on a whim.

-Dave