On Tue, 11 May 1999, Philip Blundell wrote:
> You probably want to keep them as armv4l-linux, and no I don't think there
> should be a symlink. What actually lives in these directories, and what knows
> about their location?
Architecture-dependent bits of PERL, as far as I can see. Except
hardly dependent between armv*.
The objection I have to this current widespread use of `armv4l' is this:
before long, I have no doubt that an armv5 will emerge, just to give us
more to contend with. My question is this: what is there about the
particular revision 4 of the architecture that makes it suitable as a
label for all the released RPMs -- why not version 3, or undoubtedly
soon version 5? This specific use of a particular version of the ARM
core to label all sorts of binary and data where that specific version
is not necessarily wholly appropriate (for instance, many `armv4' binaries
discard LDRH/STRH) is not something I see as particularly forward-
compatible.
I would, I think, favour removing the current what-I-see-as-a-kludge
that inhibits LDRH/STRH on armv4 (unless specifically specified), and
have people compile binaries labelled `armv3l', or `arm', where `arm' would
be a synonym for `armv3l'. This seems to me simpler, more straightforward
and perhaps more future-proof. I'm certainly in a bit of a dilemma
about what to do over compiling many of these RPMs, but in this case
I certainly don't see any point in segregating `armv*' just for a load
of PERL which AFAICT is identical across any ARM platform.
I haven't got my point across very well, perhaps because I'm not quite
sure what it is, but I get a vague feeling of lack of structural
cleanliness whenever I dabble in target names. Comments to the floor. :)
--
Chris <[EMAIL PROTECTED]> ( http://www.fluff.org/chris )
unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
