Version Identifiers for Platforms / Architectures not supported by DMD

Manu turkeyman at gmail.com
Mon Nov 7 14:54:42 PST 2011


On 8 November 2011 00:33, Iain Buclaw <ibuclaw at ubuntu.com> wrote:

> == Quote from Manu (turkeyman at gmail.com)'s article
> > --001485ec112698f20204b120c415
> > Content-Type: text/plain; charset=UTF-8
> > I've been running into this problem on consoles.
> > I'd vote for creating a standard, only creating new identifiers according
> > to that standard, and also adding standardised versions of existing
> > identifiers (leaving also the ones don't conform, possibly remove them in
> > D3)
> > The __APPLE__ one is a problem, how to identify iOS? OS8/9?
> > I've been tinkering with PSP... what about Android, PS3, XBox(/360),
> etc...
> > Some of these platforms exist on multiple architectures... how to
> > distinguish the architecture from the platform? Standardisation of arch
> > names?
>
> I don't see any real need to have identifiers for console platforms built
> into
> the compiler.  As you'd pretty much always would be using a homebrew cross-
> compiler, and can simply pass -version=PSP on the command-line in the build
> command.
>

... I guess. But I reckon it's a bit of a pain in the arse to remember to
do that everywhere (and edit scripts all over the place when cross
compiling).
I don't really see why a platform specific toolchain wouldn't know what it
is, and define its self as such.

Not to mention, if you leave it up to the user to expect some arbitrary
version identifier passed into their code, you'll never find a standard
accepted by all code for a platform... it'll just be a total mess like C is
now.
I say it should be proactively selected to encourage standardisation on
one, and it should be asserted by the compiler automatically. 10 years of
arguing with different compilers and libs for the same platforms
disagreeing on how to identify the thing has taught me that much :/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20111108/38d63bf0/attachment.html>


More information about the Digitalmars-d mailing list