| Message ID | 1416138927-7857-1-git-send-email-volker.krause@kdab.com |
|---|---|
| State | Superseded |
| Headers | show |
Volker, all, On Sun, Nov 16, 2014 at 12:55 PM, Volker Krause <volker.krause@kdab.com> wrote: > This is rarely needed by packages, but convenient to have when it is. > > Signed-off-by: Volker Krause <volker.krause@kdab.com> > --- > Changes v1 -> v2: > - added missing qstrip > - set the correct ARM variant as done in > http://patchwork.ozlabs.org/patch/408501/ > > package/pkg-cmake.mk | 15 +++++++++++++++ > support/misc/toolchainfile.cmake.in | 1 + > 2 files changed, 16 insertions(+) > > diff --git a/package/pkg-cmake.mk b/package/pkg-cmake.mk > index c8735ef..619da9b 100644 > --- a/package/pkg-cmake.mk > +++ b/package/pkg-cmake.mk > @@ -180,6 +180,20 @@ host-cmake-package = $(call inner-cmake-package,host-$(pkgname),$(call UPPERCASE > # Generation of the CMake toolchain file > ################################################################################ > > +# CMAKE_SYSTEM_PROCESSOR should match uname -m > +ifeq ($(BR2_ARM_CPU_ARMV5),y) > +CMAKE_SYSTEM_PROCESSOR = armv5 I'm not a big fan of the name of this variable... Let's see what others think about it. > +endif > +ifeq ($(BR2_ARM_CPU_ARMV6),y) > +CMAKE_SYSTEM_PROCESSOR = armv6l > +endif > +ifeq ($(BR2_ARM_CPU_ARMV7A),y) > +CMAKE_SYSTEM_PROCESSOR = armv7l > +endif > +ifndef CMAKE_SYSTEM_PROCESSOR > +CMAKE_SYSTEM_PROCESSOR = $(BR2_ARCH) > +endif > + > # In order to allow the toolchain to be relocated, we calculate the HOST_DIR > # based on the toolchainfile.cmake file's location: $(HOST_DIR)/usr/share/buildroot > # In all the other variables, HOST_DIR will be replaced by RELOCATED_HOST_DIR, > @@ -193,5 +207,6 @@ $(HOST_DIR)/usr/share/buildroot/toolchainfile.cmake: > -e 's:@@TARGET_LDFLAGS@@:$(call qstrip,$(TARGET_LDFLAGS)):' \ > -e 's:@@TARGET_CC_NOCCACHE@@:$(subst $(HOST_DIR)/,,$(call qstrip,$(TARGET_CC_NOCCACHE))):' \ > -e 's:@@TARGET_CXX_NOCCACHE@@:$(subst $(HOST_DIR)/,,$(call qstrip,$(TARGET_CXX_NOCCACHE))):' \ > + -e 's:@@CMAKE_SYSTEM_PROCESSOR@@:$(call qstrip,$(CMAKE_SYSTEM_PROCESSOR)):' \ > $(TOPDIR)/support/misc/toolchainfile.cmake.in \ > > $@ > diff --git a/support/misc/toolchainfile.cmake.in b/support/misc/toolchainfile.cmake.in > index 4ca3d35..816af13 100644 > --- a/support/misc/toolchainfile.cmake.in > +++ b/support/misc/toolchainfile.cmake.in > @@ -11,6 +11,7 @@ > string(REPLACE "/usr/share/buildroot" "" RELOCATED_HOST_DIR ${CMAKE_CURRENT_LIST_DIR}) > > set(CMAKE_SYSTEM_NAME Linux) > +set(CMAKE_SYSTEM_PROCESSOR @@CMAKE_SYSTEM_PROCESSOR@@) > > set(CMAKE_C_FLAGS "@@TARGET_CFLAGS@@ ${CMAKE_C_FLAGS}" CACHE STRING "Buildroot CFLAGS") > set(CMAKE_CXX_FLAGS "@@TARGET_CXXFLAGS@@ ${CMAKE_CXX_FLAGS}" CACHE STRING "Buildroot CXXFLAGS") > -- > 1.8.4.5 Anyway, this looks good, so: Reviewed-by: Samuel Martin <s.martin49@gmail.com> Regards,
Dear Volker Krause, On Sun, 16 Nov 2014 12:55:27 +0100, Volker Krause wrote: > +# CMAKE_SYSTEM_PROCESSOR should match uname -m > +ifeq ($(BR2_ARM_CPU_ARMV5),y) > +CMAKE_SYSTEM_PROCESSOR = armv5 > +endif > +ifeq ($(BR2_ARM_CPU_ARMV6),y) > +CMAKE_SYSTEM_PROCESSOR = armv6l > +endif > +ifeq ($(BR2_ARM_CPU_ARMV7A),y) > +CMAKE_SYSTEM_PROCESSOR = armv7l I believe armv6l and armv7l is only valid on little-endian ARM systems, not big endian ones. > +endif > +ifndef CMAKE_SYSTEM_PROCESSOR > +CMAKE_SYSTEM_PROCESSOR = $(BR2_ARCH) > +endif Are we sure that $(BR2_ARCH) is valid for all other cases? Also, please use the following construct instead: ifeq (....) ... else ifeq (....) ... else ifeq (....) ... else .... endif Thanks, Thomas
On Sunday 16 November 2014 23:23:42 Thomas Petazzoni wrote: > On Sun, 16 Nov 2014 12:55:27 +0100, Volker Krause wrote: > > +# CMAKE_SYSTEM_PROCESSOR should match uname -m > > +ifeq ($(BR2_ARM_CPU_ARMV5),y) > > +CMAKE_SYSTEM_PROCESSOR = armv5 > > +endif > > +ifeq ($(BR2_ARM_CPU_ARMV6),y) > > +CMAKE_SYSTEM_PROCESSOR = armv6l > > +endif > > +ifeq ($(BR2_ARM_CPU_ARMV7A),y) > > +CMAKE_SYSTEM_PROCESSOR = armv7l > > 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. > > +endif > > +ifndef CMAKE_SYSTEM_PROCESSOR > > +CMAKE_SYSTEM_PROCESSOR = $(BR2_ARCH) > > +endif > > 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. > Also, please use the following construct instead: > > ifeq (....) > ... > else ifeq (....) > ... > else ifeq (....) > ... > else > .... > endif fixed regards, Volker
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
diff --git a/package/pkg-cmake.mk b/package/pkg-cmake.mk index c8735ef..619da9b 100644 --- a/package/pkg-cmake.mk +++ b/package/pkg-cmake.mk @@ -180,6 +180,20 @@ host-cmake-package = $(call inner-cmake-package,host-$(pkgname),$(call UPPERCASE # Generation of the CMake toolchain file ################################################################################ +# CMAKE_SYSTEM_PROCESSOR should match uname -m +ifeq ($(BR2_ARM_CPU_ARMV5),y) +CMAKE_SYSTEM_PROCESSOR = armv5 +endif +ifeq ($(BR2_ARM_CPU_ARMV6),y) +CMAKE_SYSTEM_PROCESSOR = armv6l +endif +ifeq ($(BR2_ARM_CPU_ARMV7A),y) +CMAKE_SYSTEM_PROCESSOR = armv7l +endif +ifndef CMAKE_SYSTEM_PROCESSOR +CMAKE_SYSTEM_PROCESSOR = $(BR2_ARCH) +endif + # In order to allow the toolchain to be relocated, we calculate the HOST_DIR # based on the toolchainfile.cmake file's location: $(HOST_DIR)/usr/share/buildroot # In all the other variables, HOST_DIR will be replaced by RELOCATED_HOST_DIR, @@ -193,5 +207,6 @@ $(HOST_DIR)/usr/share/buildroot/toolchainfile.cmake: -e 's:@@TARGET_LDFLAGS@@:$(call qstrip,$(TARGET_LDFLAGS)):' \ -e 's:@@TARGET_CC_NOCCACHE@@:$(subst $(HOST_DIR)/,,$(call qstrip,$(TARGET_CC_NOCCACHE))):' \ -e 's:@@TARGET_CXX_NOCCACHE@@:$(subst $(HOST_DIR)/,,$(call qstrip,$(TARGET_CXX_NOCCACHE))):' \ + -e 's:@@CMAKE_SYSTEM_PROCESSOR@@:$(call qstrip,$(CMAKE_SYSTEM_PROCESSOR)):' \ $(TOPDIR)/support/misc/toolchainfile.cmake.in \ > $@ diff --git a/support/misc/toolchainfile.cmake.in b/support/misc/toolchainfile.cmake.in index 4ca3d35..816af13 100644 --- a/support/misc/toolchainfile.cmake.in +++ b/support/misc/toolchainfile.cmake.in @@ -11,6 +11,7 @@ string(REPLACE "/usr/share/buildroot" "" RELOCATED_HOST_DIR ${CMAKE_CURRENT_LIST_DIR}) set(CMAKE_SYSTEM_NAME Linux) +set(CMAKE_SYSTEM_PROCESSOR @@CMAKE_SYSTEM_PROCESSOR@@) set(CMAKE_C_FLAGS "@@TARGET_CFLAGS@@ ${CMAKE_C_FLAGS}" CACHE STRING "Buildroot CFLAGS") set(CMAKE_CXX_FLAGS "@@TARGET_CXXFLAGS@@ ${CMAKE_CXX_FLAGS}" CACHE STRING "Buildroot CXXFLAGS")
This is rarely needed by packages, but convenient to have when it is. Signed-off-by: Volker Krause <volker.krause@kdab.com> --- Changes v1 -> v2: - added missing qstrip - set the correct ARM variant as done in http://patchwork.ozlabs.org/patch/408501/ package/pkg-cmake.mk | 15 +++++++++++++++ support/misc/toolchainfile.cmake.in | 1 + 2 files changed, 16 insertions(+)