Hi all, may I once more comment on that.
> Also you say "the current implementation we use at aicas". To really > consider the strength of the target-layer we must make it our > implementation (for GNU Classpath as group). Otherwise it is only this > abstraction that we don't really use. This is a real argument, IMO. I can see some ways to solve the problem: 1. We get rid of the TARGET_* layer (because we don't use it), and the folks at AICAS could keep it on their own (much like some specialities in kaffe, gcj and sablevm are handled). Of course, this would make synchronizing their sources with the sources of GNU CP more difficult. 2. AICAS could contribute all their TARGET_* layer using code to GNU CP. This way this layer would kinde make sense to GNU CP hackers. Maybe we all can help to get rid of it nevertheless, but keep CP portable on those rare systems. 3. I dunno about the details, but we could go with a hybrid system: Most of the portable stuff goes into the generic layer and is autoconfiscated, like it was discussed to great lengths now. In really extreme cases the TARGET_* layer could be used. BUT: We should think about if we need all of the indirections in this layer and how we could make it more readable and debuggable. This means: - get rid of (multiline) macros where feasible, - shorten macro names, - group files together more intelligently and - reduce (better: completely avoid) redundant code (bugs multiplication!!). If this can be fullfilled somehow, then I could go with the TARGET layer. just my 2 cents again, /Roman _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
