Re: [jamboost] Re: Standardization of build

From: Rene Rivera (grafik666_at_[hidden])
Date: 2003-07-16 11:54:22

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

Yes. Instead the code to do the naming should be common and already in the
base build system, not copied in sprinkles.

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

Of the definitions I think this one is most apt:

Webster: [verb] 2 : to produce or cause to happen for public view or public
effect

The problem it solves is that of placing the usually private build outputs
into a well defined public location.

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

Also agree. (And thanks Dave, for moving the discussion here ;-)

The way to handle the maintainance aspect is to standardize what the naming
behaviour is for libraries and dlls and codify that into either the stage
rule, or preferably another rule which better describes the intent.

-- grafik - Don't Assume Anything
-- rrivera (at) acm.org - grafik (at) redshift-software.com
-- 102708583 (at) icq