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
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
> > 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.