Re: [boost] Re: build system suggestions

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-10-08 09:56:05

----- Original Message -----
From: "Vladimir Prus" <ghost_at_[hidden]>

> I would not like to lose
> the consice notaion used for requirements and default build now. Can we
have
> both ways to specify requirements/default build?

Sure.

> Jam is easy to enhance, I've discovered.

> I remember there was a discussion on how much jam used in Boost.Build can
be
> modified relatively to the official one, but don't remember the
conlusions.
> Your previous statements imply that it's ok to make any changes that are
> reasonable and don't break existing code, without caring if the changes
will
> ever be incorporated back in perforce jam. I you really think so, then I'm
no
> longer afraid that any jam's limitations will became a brick wall in
future.

I think we've drifted a little bit away from the "conservative line" on
modifying Jam, since it seems that Perforce isn't doing much of anything
with it.

> > > debugging build process is quite important
> > > [snip]
>
> > I have some elisp code that can help, if you use emacs. It allows you to
> > "step" through the debugging output. I've been thinking of adding line
> > number references to the debugging output so emacs could track the
source,
> > but decided it wasn't worth the trouble yet.
> I have seen your elisp already -- quite usefull as it is. But probably Jam
> can make more output -- e.g. announce actions text and bound values of
> variables passed to actions.

Sure, I think these are plausible ideas.

> Actually, slightly different jamfile (not using Boost.Build) shows a
certain
> bug in jam:
> Main  a : a.cpp helper.cpp ;
> Main  b : b.cpp helper.cpp ;
> In case of Boost.Build: well, I forgot that two m1.o go to different
> directories. But why do they go to different directories? What is the
reason
> for main target name to be present in path for target in depends on?

Because:

1. the main targets may have different requirements which cause the objects
to be built differently.

2. It's not very common to want to compile the same source file into
multiple executables. Maybe it happens once or twice in a project, but it
accounts for a very small fraction of all source files.

3. static libraries provide a simple mechanism to achieve that.

> > Maybe you should try again to
> > say why this would be better.

> Maybe it's only my captiousness which makes me think a build tool can't do

What does "captiousness" mean?

> unnessesary actions :-) I don't absolutely want a change in jam, but I
want
> no unneeded compiles -- both because it's extra compile time and because
it's
> hard to promote a build tool with such a property.

I'm satisfied with anything that almost never recompiles needlessly. It's
pretty hard to detect exactly which things might need to be recompiled under
all circumstances, and IMO not worth the effort.

-Dave