Packager 'do not reduce' rule behavior changed
The "do not reduce" rule in packager did not include the methods from the specified class in the computing of the transitive closure. As such, it could produce a non-working image with messages being sent to methods which have been "accidentally" reduced out. This often, but not always, showed up as errors when running the Examine & Fix Problems step of the packager.
So, for example, if there is a class 'A' that defines these methods:
#main (class method)
^super new method1
#method1
| a |
a := Array new: 10.
^a
#method2
| a |
a := Bag new.
^a
When packaging a normal "runtime reduced image" with startup code 'A main', then these methods would be included:
A class>>#main
A>>#method1
Also, the Array class would be included in the packaged image.
If a packaging rule like the following were added:
packagingRulesFor: aPackagedImage
"Define rules for the given packaged image."
aPackagedImage doNotReduceClassNamed: self name
and the packager rerun, then these methods would be included:
A class>>#main
A>>#method1
A>>#method2
But, the class Bag would not be included (as the user might expect) even though it is referenced by #method2. The reason is that the reduction algorithm only considered "explicitly" included methods to be starting points for reduction. Implicitly included methods were effectively added after the runtime reduction - i.e. runtime reduction is done as always and then the remainder of any methods/classes/apps which have "do not reduce" rules are added.
The implementation of the 'do not reduce' rule has been changed such that all the methods in the unreduced components are used as seeds in the reduction algorithm.
Last modified date: 07/02/2019