Re: [boost] Re: build system suggestions

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

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

> David Abrahams wrote:
>
> > > Unless I miss something, in order to make all the exe and lib targets
> > > with particular feature, you need to mention it in requirements for
every
>  >
> > target.
> >
> > > I'm trying to avoid this.
> >
> > Well, you can set the feature up as part of BUILD if it isn't really a
> > requirement.
> In truth, I've missed that. Only worry is that something like
> <borland><*><cxxflags>-K looks more like requirement than like a build
> request -- if omitted, program simply won't build. Yet this is not
important
> untill cxxflags is here.
>
> > Do you envision that DEFAULT_REQUIREMENTS is overridden by the manual
> > specification of any requirement?
> Yes.
>
> > Do you envision that DEFAULT_REQUIREMENTS is a per-project setting, so
that
> > if I build part of Boost as a dependency of MyProject, MyProject's
> > DEFAULT_REQUIREMENTS don't affect the requirements of the Boost
component?
> Yes.

Okay, I understand what you want. I would tend to use a new rule, e.g.:

  project-requirements <borland><*><cxxflags>-K <include>$(BOOST_ROOT) ;

Another possibility I'm considering, but this is more of a redesign:

  Instead of having sources, requirements, and default-build sections, a
target specification would just have sources. There would also be a
requirements rule invoked thus:

requirements my-target : <include>$(BOOST_ROOT) <define>BUILDING_MY_TARGET ;

and a similar "default-build" rule. In order to handle cross-project
cooperation of Jamfiles, the project name will now need to be specified in
the arguments to the project-root and subproject rules. So we could make
projects and subprojects function as targets w.r.t. the "requirements" and
"default-build" rules, e.g.:

  requirements boost : <include>$(BOOST_ROOT) ;

  requirements boost/libs/python/build : <include>$(BOOST_ROOT)
<debug><define>DEBUG_PYTHON ;

What do you think?

> > #1:
> > rule depends ( sources + : targets + : action )
> > {
> >     DEPENDS $(sources) : $(targets) ;
> >     local ignored = [ $(action) $(sources) : $(targets) ] ;
> > }
> Looks nice to me. I might start using it in my jam code.

Glad I could help.

> > #2: Why? It seems to me that if you can build the functionality you want
in
> > terms of primitives, it's better to have the primitives.
>
> Because with jam the most basic operations: adding an arc and setting
> updating action are permormed in completely different and seemingly
unrelated
> ways. I was initially somewhat confused bacause of that.

Granted. Lots is initially confusing. Still, I'm not convinced there is a
design mistake here.

> Ok, I've said why I don't like Jam but
> since I'm not planning to rewrite it, let's close this topic. After all,
> there are some build tools that I simply can't use.

Yep. I have no illusions that Jam is perfect, but I think it's good enough.

> > > How does the tool handle changes in the dependency specification
itself
> > > (e.g.  the makefile)?
> > We could make targets depend on their Jamfiles.
>
> Do you suppose to make this dependency implicit, created by the build
system?
> Will any change in Jamfile will cause complete recompilation?

That's how it would work if we took a trivial approach.

> Is it a
> problem?

I don't think so. That shouldn't happen often.

> > > Can the tool use techniques other than timestamps (e.g.
> > > checksums or differencing) to make sure only the files that have
really
> > > changed spawn build actions?
> >
> > How important is this?
> Not very important currently, agree. Except that maybe Jamfile
differenencing
> can solve the recompilation problem above (a *lot* of work, perhaps).

Perhaps. Or we could add MD5 checksumming to Jam. It would probably not be
too hard. Jam is easy to enhance, I've discovered.

> > > How do users debug
> > > their build process, or profile its performance?
> >
> > Is that a feature?
> Why not? Moreover, debugging build process is quite important -- I'm often
at
> loss as to why Jam did this or that, and it's output is either too cryptic
or
> too verbose.

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.

> > > How will problem with building the same target several time be
handled?
> > > It can be worked around in Boost.Build code, but I find it to be
rather
> > > bug in jam.
>
> > I'm not sure there is a problem. If there is, I'm sure I don't
understand
> > the problem. Maybe you could explain in more detail.
>
> something like:
> exe foo : main.cpp m1.cpp m2.cpp ;
> unit-test  m1_test : m1_test.cpp m1.cpp ;
> Here m1.cpp gets compiled twice, giving the persons around the ability to
> say: "Aha! Seems like this tools does unnecessary recompilation!"

Oh, that's not a Jam bug. That's a Boost.Build feature!

If you want to do the work to figure out that m1.o is built with exactly the
same options for these two targets (foo and m1_test) and find an appropriate
subvariant directory in which to put it, by all means be my guest. IMO it's
not a coding problem worth solving. If either target has different
requirements or default-build, this redundancy could disappear, BTW.

> > And finally, do you have a proposal for how it should be handled?
> I think that by default action should not be appended to already present,
but
> compared with it. It they don't match (bound variables considered too),
it's
> an error. If appending actions is usefull, some alternative way must be
> invented (new modifier on action?).

I'm not in the least convinced that this would represent an improvement to
Jam, and it would break existing Jam code. Maybe you should try again to say
why this would be better.

> > The momentum seems to be headed toward using pure Python syntax
> > for Sconscript files, which means lots of quoting, commas, list
delimiters,
> > and calls to string.join().
>
> Yes, this idea, inherited from cons, makes the tool not very
user-friendly.

Just having Python instead of Perl goes a long way, but in principle I agree
with you.

-Dave