From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Petazzoni Date: Tue, 18 Nov 2014 10:05:37 +0100 Subject: [Buildroot] [PATCH v2] pkg-cmake.mk: Set CMAKE_SYSTEM_PROCESSOR. In-Reply-To: <3699446.aCFlAc4tJo@vkpc9> References: <1416138927-7857-1-git-send-email-volker.krause@kdab.com> <20141116232342.2ae8cce9@free-electrons.com> <3699446.aCFlAc4tJo@vkpc9> Message-ID: <20141118100537.3ebb37ea@free-electrons.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: buildroot@busybox.net Hello, On Mon, 17 Nov 2014 21:00:16 +0100, Volker Krause wrote: > > I believe armv6l and armv7l is only valid on little-endian ARM systems, > > not big endian ones. > > you are right, and armv5 is missing the endianess suffix. Fixed in the next > version. Ok, thanks. > > Are we sure that $(BR2_ARCH) is valid for all other cases? > > It is correct for x86 (32 and 64 bit), as discussed previously. Besides that I > only have access to armv6 and armv7a devices for testing. > > I looked at the kernel code, but unfortunately it's not exactly > straightforward to determine what the machine name will be in which case. So, > no, I can't provide a complete $(BR2_ARCH) -> uname -m mapping for all > platforms. > > That's of course sub-optimal, but IMHO not necessarily a blocker. This value > is kinda unreliable from a CMake POV anyway (as it's provided by the system, > especially when also considering non-Linux), and is therefore only useful for > a very basic distinction between a fixed set of known architectures, if no > better check is available, by means of some fuzzy comparison (see e.g. the x86 > vs. i686 discussion earlier). You'd not use this for details like endianess or > pointer sizes for example, there's more robust ways to check for that (e.g. > CMAKE_SIZEOF_VOID_P). But an "is MIPS?" check would work no matter if the > exact value might be "mips", "mipsel", "mips64" or "mips64l". > > I therefore think that $(BR2_ARCH) is a sufficient approximation for all > platforms where we do not know the exact mapping to uname -m. > > Impact on existing packages is also worth looking at. There is very few > actually making use of CMAKE_SYSTEM_PROCESSOR to begin with. I think it's safe > to assume the case that a package breaks if the variable is set but worked > with an empty one before is reasonably unlikely. So the ones making use of > this are currently doing their own mapping and set CMAKE_SYSTEM_PROCESSOR via > the command line (which is where the first version of the mapping for this > patch came from). Those should not see a difference at all, they'd still be > overriding it manually. > > And anyone targeting a platform with a currently possibly wrong mapping with a > new/updated package would need to sort that out in any case, while at least > some platforms would work out of the box already with this patch. > > So, IMHO still a step into the right direction, even if we cannot complete the > $(BR2_ARCH) -> uname -m mapping entirely. Yes, I agree. I know that being sure that all $(BR2_ARCH) values are valid is difficult, and we probably should simply rely on autobuilders + user testing to find out whether it causes some problems. Thanks! Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com