Identify armv6 and armv7 as different architectures

[piranna]

Shouldn't armv6 (raspi1) and armv7 (raspi2) shown someway as different architectures? This would help for prebuild binary modules to download the correct one... At this moment they are both identified just only as arm. Is there a workaround? Maybe compile just for armv6? This would loose performance for real armv7 boards... What's the Node.js canonical board/platform/cpu/whatever for the --dest-arch=arm option of the ./configure script?

Possibly related to #7803.

[silverwind]

It's in the build variables: process.config.variables.arm_version

Edit: I see it's probably not what you're asking for. Are you asking for a change to process.arch?

[piranna]

I'm talking more about how to be able to identify them for downloading of prebuild binary modules. Also, according other issues here, seems process.config.variables.arm_version is not a trusty source to know the arm version since there's a bug and get the info from the host compiler instead the actual binary... :-/

[piranna]

Most specifically, but I'm asking for is something that can be set to the $npm_config_arch environment variable or a similar one, that values are the same of the valid archs on the configure script. At this moment are only available arm and arm64, making no distinction between armv6 and armv7 although there are oficial binaries for each one of them. Probably would be a good idea add them as arch identifiers, and set arm as an alias to one of them?

[silverwind]

Probably would be a good idea add them as arch identifiers, and set arm as an alias to one of them?

Sounds good. I'd alias to armv7 with a warning printed that the user should closer specify which version to build for.

Overall, I think we can also improve on naming the downloads and process.arch, thought the latter should happen in a semver-major commit.

[piranna]

I'd alias to armv7 with a warning printed that the user should closer specify which version to build for.

👍

Overall, I think we can also improve on naming the downloads and process.arch, thought the latter should happen in a semver-major commit.

Make sense.

[mhdawson]

@rvagg to see if you have input here.

[addaleax]

Seems like this was already discussed a bit in #9491, by the way.

[bnoordhuis]

Right, closing as duplicate.

[piranna]

Seems like this was already discussed a bit in #9491, by the way.

This is not a duplicate, but it's related to. This is about having an unique identifier for the arch string that can be used to download prebuild modules compatibles with the correct Node.js binary. Having just arm as arch identifier is too ambiguous for that task. Since there are official Node.js binaries for both armv6 and armv7, the arch field should make some distinction between them.

[silverwind]

While I agree on that armv6 is to armv7 like ia32 is to x64 (they are only one-way compatible), it's probably too much of a breaking change as @rvagg mentioned in the other thread:

process.arch isn't going to change from 'arm', that would break existing uses too hard

What can be fixed is the build targets in configure and the download naming.

[piranna]

I think the most important thing here, both if armv6 and armv7 are added or not, is to define explicitly and uniquely what arm means, in the same way that x86 is usually understand this days (mostly thanks to GCC) as mostly equivalent to say i686, but x86 itself doesn't exists as a real architecture but insteas as a family on CPUs the same way that arm... So, what can we consider the "canonical" CPU here for the Node.js arm arch?