Beman Dawes
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