On Sat, Dec 20, 2025 at 5:11 AM Ionen Wolkens <[email protected]> wrote: > > On Sat, Dec 20, 2025 at 10:15:35AM +0100, Fabian Groffen wrote: > > On 19-12-2025 22:06:06 -0500, Mike Gilbert wrote: > > > On Fri, Dec 19, 2025 at 9:58 PM Mike Gilbert <[email protected]> wrote: > > > > > > > > On Fri, Dec 19, 2025 at 3:23 PM Fabian Groffen <[email protected]> > > > > wrote: > > > > > > > > > > Use the proper methods on Darwin and Solaris hosts to get available > > > > > memory and available swap in kibibytes. > > > > > > > > You should probably check CBUILD instead of CHOST; if we are > > > > cross-compiling, you care about the system the software is being built > > > > on, not the system we are targeting. > > > > Ack, makes sense. > > > > > Or maybe check uname -s? This eclass really has nothing to do with > > > the toolchain, so checking toolchain variables seems weird. > > > > I thought CHOST and CBUILD are defined by profile/environment, not > > toolchain eclass or something, right? The package manager defines > > CBUILD when not set, so it's always there > > (lib/portage/package/ebuild/config.py). > > Believe meant toolchain variables in the sense of being toolchain > related rather than from the toolchain eclasses.
Right, I meant that we usually use these variables when dealing with compilers and other toolchain components. I would expect the kernel specified in CBUILD to align with uname -s, so I agree it's fine to use it in this context.
