Re: Standardization of build

From: David Abrahams (dave_at_[hidden])
Date: 2003-07-16 10:53:26

The following message is a courtesy copy of an article
that has been posted to gmane.comp.lib.boost.user as well.

Beman Dawes <bdawes_at_[hidden]> writes:

> At 01:03 AM 7/16/2003, Douglas Gregor wrote:
>
> >> Absolutely. I'll switch Signals over once I get around to fixing it for
> >the
> >> new iterator adaptors.
> >
> >Should be done now. I copied John's code verbatim, so I think it should
> >work
> >:) I'm rather ignorant of these Microsoftisms.
>
> Ouch! I just looked at the changes Doug made to the signals Jamfile.
>
> The changes created a maintenance nightmare. Before the changes, the 
> Jamfile was so simple and declarative that anyone can maintain it. The 
> maintainer don't really need to know anything about bjam or Boost.Build to 
> understand it.
>
> The change dramatically increased the size and complexity. Now only a 
> Boost.Build expert could even think of making a change. It has become 
> unreadable except to those with considerable training.
>
> Furthermore, the same code will be duplicated in multiple libraries. When 
> the inevitable changes are needed, they will be applied to some libraries 
> but not others. The copied code will begin to diverge. It doesn't get any 
> worse than that.
>
> All that complexity needs to be factored out so that:
>
> 1) Jamfiles needing the functionality don't have to do anything more 
> complex than the original dll and lib invocations.
>
> 2) Maintenance to the "stage" code can be performed at a single location.
>
> The terminology could use some help too. What is a "stage"? That isn't a 
> term familiar to most developers. What problem is being solved? If it is 
> some really important problem, why do "dll" and "lib" even work without 
> also solving whatever problem "stage" solves?
>
> I'm sorry to be so grouchy about this, but I think we need to step back and 
> figure out a cleaner overall approach before we start changing Jamfiles.

Agreed. And why are we having this discussion on the boost.users list?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com