[Buildroot] [PATCH 1/1] pkg-cmake.mk: Set CMAKE_SYSTEM_PROCESSOR.

[Volker Krause <volker.krause@kdab.com>]

Hi,

On Saturday 15 November 2014 19:20:49 Samuel Martin wrote:
> On Sat, Nov 15, 2014 at 6:52 PM, Romain Naour <romain.naour@openwide.fr> 
wrote:
> > Le 15/11/2014 18:26, Samuel Martin a ?crit :
> >> On Sat, Nov 15, 2014 at 5:00 PM, Volker Krause <volker.krause@kdab.com> 
wrote:
> >>> This is rarely needed by packages, but convenient to have when it is.
> > 
> > There is only one package (openpowerlink) that set this variable in
> > buildroot and the expected value is "x86" or "x86_64".

My use-case is packaging GammaRay (https://github.com/KDAB/GammaRay), which 
relies on CMAKE_SYSTEM_PROCESSOR. Setting it via the cmake command line is of 
course possible, but that didn't look like the "clean" solution.

> Hmm... this is in the openpowerlink source?
> I think it'd better do (to be more robust):
> ---
> string(REGEX REPLACE "i*86" "x86" CMAKE_SYSTEM_PROCESSOR
> ${CMAKE_SYSTEM_PROCESSOR})
> ---
> But that's another story ;-)

Right, the usual value of CMAKE_SYSTEM_PROCESSOR for x86 32bit seems to be far 
from well defined. "i*86" is the most common one I've seen on Linux, so 
BR2_ARCH should be fine there in general.

> > Are you sure that the BR2_ARCH can be used by other packages that need
> > CMAKE_SYSTEM_PROCESSOR ?
> 
> According to CMake doc [1], CMAKE_SYSTEM_PROCESSOR is set to the
> output of the command "uname -p" (in fact it is the output of "uname
> -m").
> This is only true for native compilation.
> 
> In the case of cross-compilation, the CMake code does not set anything
> [2], it just expects the CMAKE_SYSTEM_* variables to be set in the
> toolchain file.

I'll submit an updated patch that adds qstrip, and that sets the correct arm 
variant as shown in the x265 patch that Bernd mentioned.

regards,
Volker