On Thu, 05 Oct 2017 at 11:01:42 +0800, Paul Wise wrote:
> Anything that generates different code depending on the instructions
> supported by the build CPU is going to break reproducible builds. So
> whatever mechanism is used, it needs to be deterministic. [...]
> I'd like to see CMAKE_SYSTEM_PROCESSOR
> and similar be deprecated upstream because of that.
As far as I know, CMAKE_SYSTEM_PROCESSOR is the closest equivalent of the
CPU part of the GNU host architecture tuple in CMake, so is the only way
to distinguish between CPU families (i386 vs. ARM, as opposed to armv5
vs. armv7). I think it's valid to distinguish between CPU *families*,
and it's something that build systems often want.
Perhaps dh_auto_configure should specify a normalized
CMAKE_SYSTEM_PROCESSOR by default: -DCMAKE_SYSTEM_PROCESSOR=i686 on
Debian i386, and so on? Unfortunately, dpkg's cputable doesn't seem to
have a column for "what is a normal uname -m on this architecture?",
which I think is the form that CMake would want to see. It's also common
to identify architecture by uname -m in ad-hoc project-specific build
systems like the one in ioquake3. It seems that newer CPU families
mostly keep their GNU CPU and Linux uname -m identical, so maybe only
the historically weird ones (i386, arm*, p(ower)pc, mips(64)el) would
need special cases?
> Does anyone have thousands of ancient slow CPUs to reproduce all the
> builds and run autopkgtests on? :)
[insert snide comment about some of our buildds here] :-P
Regards,
smcv
