Re: $?OS change
On 2009 Mar 2, at 6:19, Timothy S. Nelson wrote: On Mon, 2 Mar 2009, Chris Dolan wrote: On Mar 2, 2009, at 12:04 AM, Timothy S. Nelson wrote: Hi. I note that we have $?OS, $?VM, and $?DISTRO (and their $* counterparts). I'd like to recommend that we eliminate $?OS, and replace it with $?KERNEL (ie. Linux) and maybe $?ARCH (ie. i386). Thoughts? User-space code cares much more deeply about the operating system than the kernel, largely thanks to libc or the equivalent. For example, BSD systems can be built on a number of different kernels. Mac OS X is in principle FreeBSD on Mach, but there are a huge number differences from "plain" FreeBSD that have nothing to do with Mach. Instead, it would be even more useful to represent $? OS.family, $?OS.version.major, $?OS.version.minor, etc. Linux distros often support switching kernel versions out from under the OS. So how about we define things as follows for Mac: - Kernel = FreeBSD - Arch = Mach - Distro = Mac OS X Actually, given the above you want: - Kernel = Mach (or Darwin) - Arch = PPC or x86-64 - Distro = Mac OS X - with compatibility = FreeBSD (as FreeBSD itself on i386 or x86-64 "does" Linux, at least if the linuxulator is configured) Not sure if we want to deal with compatibility, but in addition to the abovementioned FreeBSD-Linux compatibility role, x86-64 does i386 (arch), SuSE does Red Hat (distro; each SuSE version has compatibility with a particular Red Hat version), Ubuntu does Debian (distro), there is a "core" BSD API set which is supported by all the BSDs and a larger API set that is done by NetBSD, FreeBSD, and Dragonfly BSD, etc. There is even some compatibility at the kernel level, but as previously noted the kernel details aren't actually that useful to Perl so probably not worth it. Note also that some of these may be ranges, especially as noted above for compatibility roles. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part
Re: $?OS change
On Mon, 2 Mar 2009, Daniel Ruoso wrote: Em Seg, 2009-03-02 às 23:47 +1100, Timothy S. Nelson escreveu: On Mon, 2 Mar 2009, Daniel Ruoso wrote: So, I think the proper name to the variables would be $?ARCH and $*ARCH Where they would stringify to the arch triplet, while providing convenience methods for .cpu, .platform and .os. Hmm. But we want versions for Platform and OS as well. I don't really think this information is that all easy to get. For the platform I'm pretty sur you can't get "versions", if you have a "config.guess" script anywhere, you'll see the amount of effort it does to try to recognize what it already does recognize. Believe me, if there was a way to get more information in a generic way, it would be in that script. Hmm. Well, there's a ruby library called "facter" that seems to be able to do this for a bunch of Linux distros, but I agree that it's not very cross-platform :). http://reductivelabs.com/products/facter/ OTOH, the dependency on the libc for instance pretty much tells you which version of the OS you have (in Linux, at least). Ok. But one way or another, what do you want to achieve that wouldn't be solved by the arch triplet (and that would be solved by having the OS version)? No idea :), but I thought it would be nice to be able to get. But I guess we could fetch it where we can, and use Undefined where we can't. But thinking about it, I wonder if we shouldn't have actually two compile-time variables, which are HOST_ARCH and TARGET_ARCH so cross compiling is possible, or at least make $?ARCH to mean TARGET_ARCH while still providing $?HOST_ARCH, and since we're talking about compiling Perl code, we should probably have $?HOST_PERL and $?TARGET_PERL as well.. Are we talking about $?VM vs. $?XVM here? Well, yes... that adresses $?HOST_PERL and $?TARGET_PERL... but still leaves $?HOST_ARCH and $?TARGET_ARCH, assuming not all compiled Perl modules are platform independent. Agreed. We're thinking the same thing, but I wasn't expressing it clearly :). - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI D G+ e++> h! y- -END GEEK CODE BLOCK-
Re: $?OS change
Em Seg, 2009-03-02 às 10:39 -0300, Daniel Ruoso escreveu: > Em Seg, 2009-03-02 às 23:47 +1100, Timothy S. Nelson escreveu: > > Are we talking about $?VM vs. $?XVM here? > Well, yes... that adresses $?HOST_PERL and $?TARGET_PERL... but still > leaves $?HOST_ARCH and $?TARGET_ARCH, assuming not all compiled Perl > modules are platform independent. So, thinking about it a bit more, I'd say the variables could be called $?ARCH and $?XARCH daniel
Re: $?OS change
Em Seg, 2009-03-02 às 23:47 +1100, Timothy S. Nelson escreveu: > On Mon, 2 Mar 2009, Daniel Ruoso wrote: > > So, I think the proper name to the variables would be > > $?ARCH and $*ARCH > > Where they would stringify to the arch triplet, while providing > > convenience methods for .cpu, .platform and .os. > Hmm. But we want versions for Platform and OS as well. I don't really think this information is that all easy to get. For the platform I'm pretty sur you can't get "versions", if you have a "config.guess" script anywhere, you'll see the amount of effort it does to try to recognize what it already does recognize. Believe me, if there was a way to get more information in a generic way, it would be in that script. OTOH, the dependency on the libc for instance pretty much tells you which version of the OS you have (in Linux, at least). But one way or another, what do you want to achieve that wouldn't be solved by the arch triplet (and that would be solved by having the OS version)? > > But thinking about it, I wonder if we shouldn't have actually two > > compile-time variables, which are HOST_ARCH and TARGET_ARCH so cross > > compiling is possible, or at least make $?ARCH to mean TARGET_ARCH while > > still providing $?HOST_ARCH, and since we're talking about compiling > > Perl code, we should probably have $?HOST_PERL and $?TARGET_PERL as > > well.. > Are we talking about $?VM vs. $?XVM here? Well, yes... that adresses $?HOST_PERL and $?TARGET_PERL... but still leaves $?HOST_ARCH and $?TARGET_ARCH, assuming not all compiled Perl modules are platform independent. daniel
Re: $?OS change
On Mon, 2 Mar 2009, Daniel Ruoso wrote:
Em Seg, 2009-03-02 às 17:04 +1100, Timothy S. Nelson escreveu:
Hi. I note that we have $?OS, $?VM, and $?DISTRO (and their $*
counterparts). I'd like to recommend that we eliminate $?OS, and replace it
with $?KERNEL (ie. Linux) and maybe $?ARCH (ie. i386). Thoughts?
The usual way to handle this is by something called "arch triplet", as
you can find out if you call
gcc -dumpmachine
This triplet is formed by the "Instruction Set" (usually called CPU),
the "Platform" ("pc" for most people) and the "Operating
System" ("linux-gnu" in my case, while the "-gnu" specifies that you're
using the gnu libc). (gcc omits the "pc" part, usually).
I got i386-redhat-linux, so that works for me.
So, I think the proper name to the variables would be
$?ARCH and $*ARCH
Where they would stringify to the arch triplet, while providing
convenience methods for .cpu, .platform and .os.
Hmm. But we want versions for Platform and OS as well.
But thinking about it, I wonder if we shouldn't have actually two
compile-time variables, which are HOST_ARCH and TARGET_ARCH so cross
compiling is possible, or at least make $?ARCH to mean TARGET_ARCH while
still providing $?HOST_ARCH, and since we're talking about compiling
Perl code, we should probably have $?HOST_PERL and $?TARGET_PERL as
well..
Are we talking about $?VM vs. $?XVM here?
:)
-
| Name: Tim Nelson | Because the Creator is,|
| E-mail: wayl...@wayland.id.au| I am |
-
BEGIN GEEK CODE BLOCK
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V-
PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI D G+ e++> h! y-
-END GEEK CODE BLOCK-
Re: $?OS change
Em Seg, 2009-03-02 às 17:04 +1100, Timothy S. Nelson escreveu:
> Hi. I note that we have $?OS, $?VM, and $?DISTRO (and their $*
> counterparts). I'd like to recommend that we eliminate $?OS, and replace it
> with $?KERNEL (ie. Linux) and maybe $?ARCH (ie. i386). Thoughts?
The usual way to handle this is by something called "arch triplet", as
you can find out if you call
gcc -dumpmachine
This triplet is formed by the "Instruction Set" (usually called CPU),
the "Platform" ("pc" for most people) and the "Operating
System" ("linux-gnu" in my case, while the "-gnu" specifies that you're
using the gnu libc). (gcc omits the "pc" part, usually).
So, I think the proper name to the variables would be
$?ARCH and $*ARCH
Where they would stringify to the arch triplet, while providing
convenience methods for .cpu, .platform and .os.
But thinking about it, I wonder if we shouldn't have actually two
compile-time variables, which are HOST_ARCH and TARGET_ARCH so cross
compiling is possible, or at least make $?ARCH to mean TARGET_ARCH while
still providing $?HOST_ARCH, and since we're talking about compiling
Perl code, we should probably have $?HOST_PERL and $?TARGET_PERL as
well..
daniel
Re: $?OS change
On Mon, 2 Mar 2009, Chris Dolan wrote: On Mar 2, 2009, at 12:04 AM, Timothy S. Nelson wrote: Hi. I note that we have $?OS, $?VM, and $?DISTRO (and their $* counterparts). I'd like to recommend that we eliminate $?OS, and replace it with $?KERNEL (ie. Linux) and maybe $?ARCH (ie. i386). Thoughts? I disagree. User-space code cares much more deeply about the operating system than the kernel, largely thanks to libc or the equivalent. For example, BSD systems can be built on a number of different kernels. Mac OS X is in principle FreeBSD on Mach, but there are a huge number differences from "plain" FreeBSD that have nothing to do with Mach. Instead, it would be even more useful to represent $?OS.family, $?OS.version.major, $?OS.version.minor, etc. Linux distros often support switching kernel versions out from under the OS. So how about we define things as follows for Mac: - Kernel = FreeBSD - Arch = Mach - Distro = Mac OS X Would that work for you? I agree we need versioning. My plan would be that each of these variables contain a name and a version, at the least. I also may not have been clear on the fact that I wanted to retain Distro. Anyway, does this help some? :) - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI D G+ e++> h! y- -END GEEK CODE BLOCK-
Re: $?OS change
On Mar 2, 2009, at 12:04 AM, Timothy S. Nelson wrote: Hi. I note that we have $?OS, $?VM, and $?DISTRO (and their $* counterparts). I'd like to recommend that we eliminate $?OS, and replace it with $?KERNEL (ie. Linux) and maybe $?ARCH (ie. i386). Thoughts? I disagree. User-space code cares much more deeply about the operating system than the kernel, largely thanks to libc or the equivalent. For example, BSD systems can be built on a number of different kernels. Mac OS X is in principle FreeBSD on Mach, but there are a huge number differences from "plain" FreeBSD that have nothing to do with Mach. Instead, it would be even more useful to represent $?OS.family, $? OS.version.major, $?OS.version.minor, etc. Linux distros often support switching kernel versions out from under the OS. % uname -mprsv Darwin 9.6.0 Darwin Kernel Version 9.6.0: Mon Nov 24 17:37:00 PST 2008; root:xnu-1228.9.59~1/RELEASE_I386 i386 i386 Chris
