platform(n)

πŸ“¦
version 9.0.3 Β· 3 versions
, in alpine 3.23, alpine 3.24, fedora 43, fedora 44, nixos 26.05, nixpkgs unstable

πŸ’– platform(n) πŸ’–

okay bestie, pull up a chair β€” this is the platform page from Tcl Bundled Packages, aka the little toolkit that tells you exactly what kind of machine your Tcl code is vibing on. πŸ¦‹


✨ NAME ✨

platform β€” System identification support code and utilities πŸŽ€


🌸 SYNOPSIS 🌸

package require platform ?1.0.10?

platform::generic
platform::identify
platform::patterns identifier

πŸ’… DESCRIPTION πŸ’…

The platform package hands you a couple of utility commands that are lowkey essential for figuring out the architecture of the machine your Tcl is running on. main character energy for sysadmin girlies. ✨

So here's the tea πŸ“: Tcl does give you the tcl_platform array for identifying the current architecture β€” specifically the platform and machine elements β€” but bestie, that is not always enough. Why? Because on Unix machines, tcl_platform just reflects whatever values the uname command spat back, and those are not standardized across platforms and architectures. Not even a little. 😭

And it gets worse: on at least one platform (AIX), tcl_platform(machine) contains the CPU serial number. Like... what. πŸ’€

So what happens? Individual applications end up having to massage the values in tcl_platform (plus the output of whatever system-specific utilities exist) all by themselves. That's inconvenient for developers, and it opens the door to inconsistencies in identifying architectures and in naming conventions. Messy. πŸ™ˆ

The platform package exists to stop that fragmentation, periodt. It sets up a standard naming convention for architectures running Tcl and makes it way more convenient for developers to identify the current architecture a Tcl program is running on. iconic behavior, honestly. πŸ‘‘


⭐ COMMANDS ⭐

  • platform::identify β€” This command returns an identifier describing the platform the Tcl core is running on. The returned identifier has the general format OS-CPU. The OS part of the identifier may contain details like kernel version, libc version, etc., and this information may contain dashes as well. The CPU part will not contain dashes, making the preceding dash the last dash in the result. 🧚
  • platform::generic β€” This command returns a simplified identifier describing the platform the Tcl core is running on. In contrast to platform::identify, it leaves out details like kernel version, libc version, etc. The returned identifier has the general format OS-CPU. πŸ¦‹
  • platform::patterns identifier β€” This command takes an identifier as returned by platform::identify and returns a list of identifiers describing compatible architectures. 🌈

πŸŽ€ EXAMPLE πŸŽ€

This can be used to allow an application to be shipped with multiple builds of a shared library, so that the same package works on many versions of an operating system. For example:

package require platform
# Assume that app script is .../theapp/bin/theapp.tcl
set binDir [file dirname [file normalize [info script]]]
set libDir [file join $binDir .. lib]
set platLibDir [file join $libDir [platform::identify]]
load [file join $platLibDir support[info sharedlibextension]]

one package, many OS versions, zero drama. πŸ’–


πŸ”₯ KEYWORDS πŸ”₯

operating system, cpu architecture, platform, architecture


and that's the whole page, bestie β€” no cap. 🫢 This one's platform, version 1.0.4, from the Tcl Bundled Packages manual collection. Go identify some architectures. Slay. πŸ’…βœ¨

πŸ“¦ where this page comes from