Control: tags -1 moreinfo

Simon McVittie:
> On Sun, 14 Jul 2019 at 08:43:25 +0200, Helmut Grohne wrote:
>> [...]
>> Other than that, my general advice would be preferring $CC -dumpmachine
>> over uname -m as it avoids a whole host of problems. Getting there seems
>> like a herculean task though.
> 
> Is -dumpmachine portable among compilers, or is it a GNU'ism? If it's
> specific to gcc, or specific to gcc and compilers like clang that mimic
> gcc, or specific to compilers designed with the GNU/Autoconf vocabulary
> of CPUs in mind, then I can see why upstreams targeting both GNU and
> non-GNU OSs would avoid it.
> 
> As far as I can tell, CMake uses uname -m for its vocabulary of Linux CPUs
> (but see https://bugs.debian.org/930995), so switching to using the CPU
> part of $CC -dumpmachine would be an incompatible change, unless CMake
> had a lookup table to map between GNU CPUs and what uname -m would have
> said on the relevant machine. I think Meson did this better by having an
> explicitly documented table of known CPU names; I would have preferred it
> if Meson had reused GNU's vocabulary of CPU names rather than inventing
> a new one, but it's too late for that.
> 
> Debian::Debhelper::Buildsystem::cmake effectively already does have
> a lookup table to map GNU CPUs to uname -m (it's a list of exceptions
> rather than a complete table, since in practice they usually match),
> but it's currently only used when told to cross-compile, and reprotest's
> builds are "officially" not cross-compiling, even if uname -m would
> indicate otherwise.
> 
>     smcv
> 

Hi,

I am not sure I am any wiser on this bug after reading the bug log other
than it looks unactionable to me at the moment (hench the moreinfo tag).

If the conclusion is that debhelper should always pass
-DCMAKE_SYSTEM_PROCESSOR (or/and -DCMAKE_SYSTEM_NAME) then I am happy to
implement that after we confirmed that this is "safe" (doesn't break
every cmake package in sid, etc.).  However, it is not clear to me
whether that is the conclusion we reached.

Thanks,
~Niels

Reply via email to