Post by Jared MaddoxPost by T. Joseph CarterCompiler flags are probably more useful a judge than a file on the
system for whether you have x86_64 or x86. After all, there is such
a thing as running 32 bit code on a 64 bit system.
Point. I included them in my example purely because I was thinking
about the implementation coming down to plain boring string
comparisons, and little else.
Plain boring comparisons are what I'm after here. As I've said, I'm
not looking for a diagnostic tool or even a full OS identification.
The thing I feel is needed is a platform identification. Think
closer to the kind of stuff you get out of config.guess than you do
from examining something found in /etc to determine a distribution.
Only, config.guess triplets aren't quite it either. At the moment, I
can obtain these:
x86_64-apple-darwin13.0.0
x86_64-unknown-linux-gnu
i686-pc-mingw32
i586-pc-haiku
Of course config.guess output is somewhat less than 100% useful for a
number of reasons.
1. You don't always have this information when building SDL, as it's
kind of a UNIXism, or more accurately a GNUism. It's a de-facto
standard only because gcc uses it, and gcc is the standard compiler
on most every platform people care about aside from Windows.
2. The triplet is not standardized in a meaningful way. Oh, the CPU
generally is because of gcc, but the vendor is typically "pc" or
"unknown" and completely irrelevant.[*mingw] The platform may or may
not indicate a version, and the version's not easily parsed in C
anyway.
3. The triplets sometimes lie[*mingw].
4. The platform may not be enough as critical things SDL needs may
not be supported depending on the platform version. Apple annoyingly
changes stuff all the time. Certain features are totally (and
silently) unavailable on old versions of Windows. A Linux kernel too
new or too old may not play well with a binary-only video driver.
Post by Jared MaddoxLinux isn't an OS, just a kernel, so getting the kernel version
doesn't tell you much. If all that you genuinely care about is the
kernel version, then it means you don't care if it's a *nix
environment, for example. The real "meat and potatoes" of the Linux
world is distro-specific (e.g. Gnome vs KDE, RPM vs DPKG), so if you
want to do any interactions with the system beyond just the kernel,
you need to get the distro info. Last time that I checked, even
Android was just a Linux distro if you squinted hard enough.
True, but Linux is usually a platform. You don't have different
versions of Steam for Debian, for Red Hat, for Ubuntu, for Mint, etc.
No need, because although there are different OSes based around the
Linux platform, the platform generally considered to be "Linux" is
based around the kernel itself.
Probably 99 out of 100 apps that someone could write using SDL (and
I'm being generous) don't care whether you have dpkg, rpm, KDE,
Gnome, Enlightenment, or twm. :) Heck, probably 95 out of the 100
don't even much care that you're running all of this on Linux unless
something goes wrong. For when it does (and for those apps that care
about the platform version), I intend to give something that will
help answer questions about what's not working and why.
That's going to wind up being more than just a platform/version query
before I'm done—but I'll be submitting that as a separate patch.
I'll make cases for other subsystems producing lower level driver
identification as I find the need (and the best implementation of a
solution to it…) Presently I've got too many things on my plate that
depend on one another, so cutting off bite-sized pieces is good.
Post by Jared MaddoxPost by T. Joseph CarterIt fits with the same notion that it's more important for me as a
developer to know I'm looking at Windows NT 5.2.2600 than Windows XP
Professional. That it happens to be WinXP Pro is irrelevant?it's NT
5.2, and that tells me a lot about what might break on your system.
I've never heard of a Windows kernel shipping without some
standardized components, so not especially relevant. Now, some sort of
add-on stuff, like MSOffice, or StarOffice, or whatever else? SDL
shouldn't be expected to look for that stuff, because hey, telling you
the info that you need in order to figure out how to look it up
yourself should be enough.
Windows FLP was an XP that shipped without a few big ones. Couldn't
easily install them either. There's apparently similarly stripped
versions for Windows Vista and 7. Dunno about 8/8.1, but the trend
would be logical. You couldn't easily re-add some of those missing
components either. Of course I don't think any of those missing
components affected SDL.
I can imagine lots of things one could detect about a system if one
wanted to. I'm aiming for the basics, though, because that's what
you'll need to know if something that should work doesn't.
---
[*mingw]
Sigh.
This is one hell of an * for mingw32! For mingw-w64, the vendor
should be w64, not pc, and it matters a whole lot to SDL! A great
many API things exist under mingw-w64 that do not for mingw32.
There are many issues related to getting a "good" MSYS/mingw-w64
build system up and running for SDL. When I figure them out, I'll be
sure to write some docs and post them. But I need to find someone
who can answer a few questions first.
There are three (four?) triplets for mingw systems:
1. i686-pc-mingw32. Classic mingw32. Not recommended for SDL.
2. i686-w64-mingw32. A mingw-w64 setup for 32 bit x86 Windows.
3. x86_64-w64-mingw32. The mingw-w64 target for x86_64 systems.
4? arm-w64-mingw32. Dunno if this exists. It should.
Issues with the above:
- config.guess always reports #1 under MSYS because MSYS doesn't even
compile with modern gcc, let alone a non-i686 gcc! MSYS2 should
support w64, but it's not quite a polished release, and it's totally
undocumented. I dunno yet if MSYS2 is considered "usable" even.
- The mingw-w64 wiki recommends TDM-GCC which comes as 32 bit and 64
bit editions. The 32 bit edition is actually mingw32, so #1 is
correct. I think mostly whoever wrote that on the wiki referenced it
as an "easy mode" way to get the 64 bit version installed. It's not
what we want for SDL, though (except we need its binutils and if your
host is a 32 bit windows, you also need its gdb!)
- TDM-GCC's 64 bit edition always reports itself as #3. But with the
exception of the gdb binary, it is actually i686 host that by default
produces x86_64. That means it should be host #2, but target #3 by
default (or #2 with the -m32 flag!) It isn't, though, and you'll
find its windres.exe only produces x86_64 code that cannot be linked
with anything built with -m32. See, this is why it SHOULD be set up
at least differently than it is.
Me, I'd provide both i686-w64-mingw32-gcc and x86_64-w64-mingw32-gcc
with binutils for each and use some equivalent of gcc_select. Of
course this is somewhat non-trivial since you don't have traditional
UNIX symlinks. (Vista and above using NTFS do with escalated privs,
but those restrictions make them irrelevant to our purpose.)
Over on OFTC #mingw-w64, they're telling me some of the documentation
is not as it should be. :) I have gotten some help and found the
people there pretty friendly. We'll see what I can do with the info
this weekend.
Joseph