Ralf Wildenhues <[EMAIL PROTECTED]> writes: [definitions] Does that make more sense?
yes thanks, i find "base" and "derived" easier to understand. What exactly do you mean with these terms? (I have a vague idea but would rather like to know a precise definition.) in trying to be more precise, i abandoned the idea of distinguishing fatal vs. non-fatal or even foo vs. non-foo. now i think it is better to think along general terms: "edge attributes". whether or not a particular edge attribute has a value is another question. for example, if we allow values, the pair "closeness / zero" is another way of saying "direct", and "closeness / non-zero" another way of saying "indirect". if we do not allow values, the attribute "direct" means "direct" (wow, complicated!), and the lack of that attribute means "indirect". in any case, we can further characterize the relationship between things by adding (i.e., recognizing and handling) more attributes. i had in mind "fatal" as one particular attribute (valid only for indirect edges) that means roughly "if this base lib is not included the derived object cannot start". but that's still rather fuzzy. what/when does "start" mean, etc? please ignore that malformed idea. regardless of the merit (or lack of merit) of "fatal" as an attribute, i propose looking at edges from the attributes point of view rather than the categories point of view. (does that make sense?) Since it is in general impossible to find out which library dependencies are directly or indirectly derived by looking at the source yes, the best we can do is provide a way for people to describe the relationships fully, resorting to heuristics as little as possible. thi _______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
