From: David Abrahams (gclbb-jamboost_at_[hidden])
Date: 2003-05-10 22:49:28
Vladimir Prus <ghost_at_[hidden]> writes:
> David Abrahams wrote:
>> Modified Files:
>> Log Message:
>> Improved commenting, naming, formatting. Began refactoring.
> I've a problem with this log message. Suppose you look at it a month ago. Can
> you glean anything --- what was refactored, how, why? I think no, so this
> message is as good as no message. Also, to understand what changed I need to
> browse the entire diff, which includes not so interesting comment/naming
> Could we agree to use a bit more verbose log messages. For example, if message
> for this commit read:
> * new/generators.jam: Improved commenting, naming, formatting
> (generator.match-rank): Count also requirements when determining the rank,
> not only optional properties.
> (generator.run): Always set 'multiple' to true.
> I would immediately understand the important changes.
I'll try. I usually find log comments to be useless, so I don't give
them much attention, but I can understand that not everyone feels that
>> - return [ sequence.length [ set.intersection
>> - [ optional-properties ] : $(properties) ] ] ;
>> + # We're only used to rank matches based on the number of
>> + # optional properties that appear in the property set.
>> + # That seemed a little weak to me, so I changed it: now we
>> + # account for the number of properties and features that
>> + # were matched as well. -- dwa 5/6/2003
> I'm pretty sure the current behaviour was prompted by some real use case from
> my work usage of V2. Once I'm able to update from CVS, I'll try to find if
> your changes break that usage.
Please do let me know.
>> + multiple = true ; # The tests seem to tolerate this; will
>> + # remove the parameter altogether in the
>> + # next revision to see what I learn -- DWA
> I actually wonder if this means "multiple" is unneeded, or that simply we
> don't have tests for that. The last paragraph of 'generators.jam' comment
> still makes sense to me --- but I don't have real examples to present.
It is still clearly needed, but perhaps no variability is needed at
this point in the code. Anyway, I'll be posting a proposal for
eliminating multiple shortly...
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk