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
