Skip to contentSkip to conversation

allarch: Allow class to be included but overridden

PATCH In review Richard Purdie 2 participants 5 messages Nov 26, 2012

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 allarch: Allow class to be included but overridden

We have cases where we'd like to inherit this class by default but allow special cases to override it. This change makes the code of the class conditional on PACKAGE_ARCH remaining set to "all", allowing it to be overridden. packagegroup usage is one case this is desirable.

---

meta/classes/allarch.bbclass +19 -14
index 21157e5..8669470 100644
@@ -4,20 +4,25 @@
 
 PACKAGE_ARCH = "all"
 
-# No need for virtual/libc or a cross compiler
-INHIBIT_DEFAULT_DEPS = "1"
+python () {
+    # Allow this class to be included but overridden - only set
+    # the values if we're still "all" package arch.
+    if d.getVar("PACKAGE_ARCH") == "all":
+        # No need for virtual/libc or a cross compiler
+        d.setVar("INHIBIT_DEFAULT_DEPS","1")
 
-# Set these to a common set of values, we shouldn't be using them other that for WORKDIR directory
-# naming anyway
-TARGET_ARCH = "allarch"
-TARGET_OS = "linux"
-TARGET_CC_ARCH = "none"
-TARGET_LD_ARCH = "none"
-TARGET_AS_ARCH = "none"
-PACKAGE_EXTRA_ARCHS = ""
+        # Set these to a common set of values, we shouldn't be using them other that for WORKDIR directory
+        # naming anyway
+        d.setVar("TARGET_ARCH", "allarch")
+        d.setVar("TARGET_OS", "linux")
+        d.setVar("TARGET_CC_ARCH", "none")
+        d.setVar("TARGET_LD_ARCH", "none")
+        d.setVar("TARGET_AS_ARCH", "none")
+        d.setVar("PACKAGE_EXTRA_ARCHS", "")
 
-# No need to do shared library processing or debug symbol handling
-EXCLUDE_FROM_SHLIBS = "1"
-INHIBIT_PACKAGE_DEBUG_SPLIT = "1"
-INHIBIT_PACKAGE_STRIP = "1"
+        # No need to do shared library processing or debug symbol handling
+        d.setVar("EXCLUDE_FROM_SHLIBS", "1")
+        d.setVar("INHIBIT_PACKAGE_DEBUG_SPLIT", "1")
+        d.setVar("INHIBIT_PACKAGE_STRIP", "1")
+}
 
#1 lore raw
Quoted 7 lines · Richard Purdie

We have cases where we'd like to inherit this class by default but allow special cases to override it. This change makes the code of the class conditional on PACKAGE_ARCH remaining set to "all", allowing it to be overridden. packagegroup usage is one case this is desirable.

---

Richard, I fail to see the usecase of packagroup. Can you clarify?

Signature · 3 lines
Otavio Salvador                             O.S. Systems
E-mail: [email protected]  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br
#2 lore raw
Quoted 11 lines · Otavio Salvador
Quoted 7 lines · Richard Purdie

We have cases where we'd like to inherit this class by default but allow special cases to override it. This change makes the code of the class conditional on PACKAGE_ARCH remaining set to "all", allowing it to be overridden. packagegroup usage is one case this is desirable.

---

Richard, I fail to see the usecase of packagroup. Can you clarify?

packagegroup.bbclass previously set PACKAGE_ARCH = "all" which was confusing other code. Anything using the all package arch should really use allarch so we are consistent about how we set the various variables.

Even though packagegroup.bbclass now uses allarch, we need specific packagegroup packages to be able to override the class e.g. marking themselves machine specific. This is why we need to make this change.

Cheers,

Richard

#3 lore raw
Quoted 13 lines · Richard Purdie
Quoted 11 lines · Otavio Salvador
Quoted 7 lines · Richard Purdie

We have cases where we'd like to inherit this class by default but allow special cases to override it. This change makes the code of the class conditional on PACKAGE_ARCH remaining set to "all", allowing it to be overridden. packagegroup usage is one case this is desirable.

---

Richard, I fail to see the usecase of packagroup. Can you clarify?

Quoted 7 lines

packagegroup.bbclass previously set PACKAGE_ARCH = "all" which was confusing other code. Anything using the all package arch should really use allarch so we are consistent about how we set the various variables.

Even though packagegroup.bbclass now uses allarch, we need specific packagegroup packages to be able to override the class e.g. marking themselves machine specific. This is why we need to make this change.

My only concern is if we could make allarch to raise an exception if you inherit it and set package arch to another value?

The only bad effect about it is we won't be able to change something in a bbappend which makes the package arch specific that way.

Signature · 3 lines
Otavio Salvador                             O.S. Systems
E-mail: [email protected]  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br
#4 lore raw
Quoted 19 lines · Otavio Salvador
Quoted 17 lines · Richard Purdie
Quoted 11 lines · Otavio Salvador
Quoted 7 lines · Richard Purdie

We have cases where we'd like to inherit this class by default but allow special cases to override it. This change makes the code of the class conditional on PACKAGE_ARCH remaining set to "all", allowing it to be overridden. packagegroup usage is one case this is desirable.

---

Richard, I fail to see the usecase of packagroup. Can you clarify?

packagegroup.bbclass previously set PACKAGE_ARCH = "all" which was confusing other code. Anything using the all package arch should really use allarch so we are consistent about how we set the various variables.

Quoted 6 lines
Quoted 3 lines

Even though packagegroup.bbclass now uses allarch, we need specific packagegroup packages to be able to override the class e.g. marking themselves machine specific. This is why we need to make this change.

My only concern is if we could make allarch to raise an exception if you inherit it and set package arch to another value?

We're deciding that we're supporting that exact usecase though?

Quoted 2 lines

The only bad effect about it is we won't be able to change something in a bbappend which makes the package arch specific that way.

Why not? This should be perfectly usable from a .bbappend?

Cheers,

Richard