Re: [boost] Re: build system suggestions

From: Vladimir Prus (ghost_at_[hidden])
Date: 2001-10-08 08:30:46

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

> Okay, I understand what you want. I would tend to use a new rule, e.g.:
>
>   project-requirements <borland><*><cxxflags>-K <include>$(BOOST_ROOT) ;

I agree to this variant.

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

Neat idea. This way it's possible to specify default requirements for 
subprojects, not only for the project itself. Yet, 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?

> > 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.
Ok, practice will show.

> Perhaps. Or we could add MD5 checksumming to Jam. It would probably not be
> too hard. 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.

> > > > How do users debug
> > > > their build process, or profile its performance?
> > >
> > > Is that a feature?
> >
> > Why not? Moreover, 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. 

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

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?

> > > 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.
Maybe it's only my captiousness which makes me think a build tool can't do 
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.

Regards,
Vladimir