Re: [boost] Re: build system suggestions

From: Vladimir Prus (ghost_at_[hidden])
Date: 2001-10-05 09:13:26

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.

> > There are two matters which I don't like
> > 1. Creation of dependence graph is done in an odd way. It would be much
> > better if e.g. Depends rules was taking a third argument -- name of
>
> updating
>
> > action.
>
> #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.

> #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.

> > There was a bug with NOCARE handling recenly.
> It wouldn't be the first time a mistake slipped into a release.
Sure, but bugs in the most basic layer coupled with bugs in documentation for 
it (there was some issue with INCLUDES, I remember), make one unsure about
correct build semantics. I would like to see a very short and clear 
description of the build stage semantics, with implementation written some 
years ago, and not changed since. 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.

> > To many
> > problems for a program created a long time ago.
>
> BTW, that long list of complaints is more than one item. You seem to keep
> doing that...
:-)

> > I quote:
> > 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? Is it a 
problem?

> > 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). 

> > Does the tool allow users to specify more than
> > one way to resolve a dependency, e.g. patching a binary in place rather
> than
>
> > recompiling an entire library if certain criteria are met?
>
> How important is this?
Not very.

> > 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. 

> > Can the tool provide
> > feedback on how much work it has done, and how much remains to be done?
>
> How important is this?
Not very.

> > 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!"

> 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?).

> Scons is moving along nicely, but as we've said Boost has rejected it, at
> least for the time being. Although Python is much more powerful than Jam, I
> think that the Scons front-end will be less user-friendly than Jam's in
> many ways. 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.

Regards,
Vladimir