Skip to contentSkip to conversation

llvm3.2: new recipe

PATCH Superseded Jonathan Liu 3 participants 9 messages Jun 2, 2013 – Jun 11, 2013

v1 of 5 Superseded Latest is v5 →

lore
Share & tools
lore

Jonathan Liu

author
#0 lore raw

PATCH 1/1 llvm3.2: new recipe

arm_fenv_uclibc.patch was copied from llvm2.9 recipe.

Signed-off-by Jonathan Liu <[email protected]>
---
 .../llvm/llvm3.2/arm_fenv_uclibc.patch             |  14 +++
 meta-oe/recipes-core/llvm/llvm3.2_3.2.bb           | 116 +++++++++++++++++++++
 2 files changed, 130 insertions(+)
 create mode 100644 meta-oe/recipes-core/llvm/llvm3.2/arm_fenv_uclibc.patch
 create mode 100644 meta-oe/recipes-core/llvm/llvm3.2_3.2.bb
meta-oe/recipes-core/llvm/llvm3.2/arm_fenv_uclibc.patch new file +14 -0
new file mode 100644
index 0000000..c3ae494
@@ -0,0 +1,14 @@
+Index: llvm-2.9/include/llvm/Support/FEnv.h
+===================================================================
+--- llvm-2.9.orig/include/llvm/Support/FEnv.h	2010-11-29 20:44:50.000000000 +0100
++++ llvm-2.9/include/llvm/Support/FEnv.h	2011-11-18 18:42:22.580161297 +0100
+@@ -17,6 +17,9 @@
+ 
+ #include "llvm/Config/config.h"
+ #include <cerrno>
++
++#undef HAVE_FENV_H
++
+ #ifdef HAVE_FENV_H
+ #include <fenv.h>
+ #endif
meta-oe/recipes-core/llvm/llvm3.2_3.2.bb new file +116 -0

116 lines not on this page · raw message

Signature · 1 line
1.8.3
#1 lore raw

W dniu 02.06.2013 11:33, Jonathan Liu pisze:

Quoted 9 lines
meta-oe/recipes-core/llvm/llvm3.2_3.2.bb new file +9 -0
+def get_llvm_arch(d):
+    import bb;
+
+    arch = bb.data.getVar('TARGET_ARCH', d, 1)
+
+    if arch == "x86_64" or arch == "i486" or arch == "i586" or arch == "i686":
+        arch = "x86"
+    elif arch == "x86_64":
+        arch = "x86_64"

meta-oe/recipes-core/llvm/llvm3.2_3.2.bb line 116

Quoted 10 lines
meta-oe/recipes-core/llvm/llvm3.2_3.2.bb new file +10 -0
+    elif arch == "arm":
+        arch = "arm"
+    elif arch == "mipsel" or arch == "mips":
+        arch = "mips"
+    elif arch == "powerpc" or arch == "powerpc64":
+        arch = "powerpc"
+    else:
+        bb.warn("%s does not support %s yet" % (bb.data.getVar('PN', d, 1), arch) );
+
+    return arch

Can we get rid of such blocks? They are worthless and only generate extra support questions when OE newbies use OE with 'not supported' architectures.

author
#2 lore raw
Quoted 16 lines · Marcin Juszkiewicz

W dniu 02.06.2013 11:33, Jonathan Liu pisze:

Quoted 15 lines
meta-oe/recipes-core/llvm/llvm3.2_3.2.bb new file +15 -0
+def get_llvm_arch(d):
+    import bb;
+
+    arch = bb.data.getVar('TARGET_ARCH', d, 1)
+
+    if arch == "x86_64" or arch == "i486" or arch == "i586" or arch == "i686":
+        arch = "x86"
+    elif arch == "x86_64":
+        arch = "x86_64"
+    elif arch == "arm":
+        arch = "arm"
+    elif arch == "mipsel" or arch == "mips":
+        arch = "mips"
+    elif arch == "powerpc" or arch == "powerpc64":
+        arch = "powerpc"
Quoted 8 lines

meta-oe/recipes-core/llvm/llvm3.2_3.2.bb line 116

Quoted 4 lines
meta-oe/recipes-core/llvm/llvm3.2_3.2.bb new file +4 -0
+    else:
+        bb.warn("%s does not support %s yet" % (bb.data.getVar('PN', d, 1), arch) );
+
+    return arch

Can we get rid of such blocks? They are worthless and only generate extra support questions when OE newbies use OE with 'not supported' architectures.

Done in v3 patch.

Regards,
Jonathan

#3 lore raw
In reply to Marcin Juszkiewicz
Quoted 16 lines · Marcin Juszkiewicz

W dniu 02.06.2013 11:33, Jonathan Liu pisze:

Quoted 15 lines
meta-oe/recipes-core/llvm/llvm3.2_3.2.bb new file +15 -0
+def get_llvm_arch(d):
+    import bb;
+
+    arch = bb.data.getVar('TARGET_ARCH', d, 1)
+
+    if arch == "x86_64" or arch == "i486" or arch == "i586" or arch == "i686":
+        arch = "x86"
+    elif arch == "x86_64":
+        arch = "x86_64"
+    elif arch == "arm":
+        arch = "arm"
+    elif arch == "mipsel" or arch == "mips":
+        arch = "mips"
+    elif arch == "powerpc" or arch == "powerpc64":
+        arch = "powerpc"
Quoted 8 lines

meta-oe/recipes-core/llvm/llvm3.2_3.2.bb line 116

Quoted 4 lines
meta-oe/recipes-core/llvm/llvm3.2_3.2.bb new file +4 -0
+    else:
+        bb.warn("%s does not support %s yet" % (bb.data.getVar('PN', d, 1), arch) );
+
+    return arch

Can we get rid of such blocks? They are worthless and only generate extra support questions when OE newbies use OE with 'not supported' architectures.

why do you think they are worthless ? when they give good information instead of failing to build
and then generating support question which need more work to come to same conclusion

Quoted 4 lines

_______________________________________________
Openembedded-devel mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

#4 lore raw

W dniu 11.06.2013 09:48, Khem Raj pisze:

Quoted 27 lines
Quoted 16 lines · Marcin Juszkiewicz

W dniu 02.06.2013 11:33, Jonathan Liu pisze:

Quoted 15 lines
meta-oe/recipes-core/llvm/llvm3.2_3.2.bb new file +15 -0
+def get_llvm_arch(d):
+    import bb;
+
+    arch = bb.data.getVar('TARGET_ARCH', d, 1)
+
+    if arch == "x86_64" or arch == "i486" or arch == "i586" or arch == "i686":
+        arch = "x86"
+    elif arch == "x86_64":
+        arch = "x86_64"
+    elif arch == "arm":
+        arch = "arm"
+    elif arch == "mipsel" or arch == "mips":
+        arch = "mips"
+    elif arch == "powerpc" or arch == "powerpc64":
+        arch = "powerpc"
Quoted 8 lines

meta-oe/recipes-core/llvm/llvm3.2_3.2.bb line 116

Quoted 4 lines
meta-oe/recipes-core/llvm/llvm3.2_3.2.bb new file +4 -0
+    else:
+        bb.warn("%s does not support %s yet" % (bb.data.getVar('PN', d, 1), arch) );
+
+    return arch

Can we get rid of such blocks? They are worthless and only generate extra support questions when OE newbies use OE with 'not supported' architectures.

Quoted 3 lines

why do you think they are worthless ? when they give good information instead of failing to build and then generating support question which need more work to come to same conclusion

$ MACHINE=genericarmv8 bitbake nano
"llvm is not supported"
"openjdk is not supported"
"another-thing-you-do-not-care-for-this-build is not supported"

This is how your builds look for not supported architectures.

OE has COMPATIBLE_HOST variable which can be used by recipe maintainers to mark which architectures are supported.

#5 lore raw
Quoted 28 lines · Marcin Juszkiewicz

W dniu 11.06.2013 09:48, Khem Raj pisze:

Quoted 26 lines
Quoted 24 lines · Marcin Juszkiewicz

W dniu 02.06.2013 11:33, Jonathan Liu pisze:

Quoted 9 lines
meta-oe/recipes-core/llvm/llvm3.2_3.2.bb new file +9 -0
+def get_llvm_arch(d):
+    import bb;
+
+    arch = bb.data.getVar('TARGET_ARCH', d, 1)
+
+    if arch == "x86_64" or arch == "i486" or arch == "i586" or arch == "i686":
+        arch = "x86"
+    elif arch == "x86_64":
+        arch = "x86_64"

meta-oe/recipes-core/llvm/llvm3.2_3.2.bb line 116

Quoted 10 lines
meta-oe/recipes-core/llvm/llvm3.2_3.2.bb new file +10 -0
+    elif arch == "arm":
+        arch = "arm"
+    elif arch == "mipsel" or arch == "mips":
+        arch = "mips"
+    elif arch == "powerpc" or arch == "powerpc64":
+        arch = "powerpc"
+    else:
+        bb.warn("%s does not support %s yet" % (bb.data.getVar('PN', d, 1), arch) );
+
+    return arch

Can we get rid of such blocks? They are worthless and only generate extra support questions when OE newbies use OE with 'not supported' architectures.

Quoted 9 lines
Quoted 3 lines

why do you think they are worthless ? when they give good information instead of failing to build and then generating support question which need more work to come to same conclusion

$ MACHINE=genericarmv8 bitbake nano
"llvm is not supported"
"openjdk is not supported"
"another-thing-you-do-not-care-for-this-build is not supported"

it could be said if you do not care for such recipes then BBMASK them and message
well may be it could be make bb.note instead of bb.warn to make it more of FYI kind of thing

Quoted 4 lines

This is how your builds look for not supported architectures.

OE has COMPATIBLE_HOST variable which can be used by recipe maintainers to mark which architectures are supported.

in this case arch does not map to what OE's target arch is so you have to do it twice if you want
to use COMPATIBLE_HOST
and suppose a non supported arch becomes supported you have to change both places.

Quoted 4 lines

_______________________________________________
Openembedded-devel mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-devel

#6 lore raw

W dniu 11.06.2013 10:03, Khem Raj pisze:

Quoted 12 lines

On Tue, Jun 11, 2013 at 12:55 AM, Marcin Juszkiewicz

Quoted 10 lines

W dniu 11.06.2013 09:48, Khem Raj pisze:

Quoted 3 lines

why do you think they are worthless ? when they give good information instead of failing to build and then generating support question which need more work to come to same conclusion

$ MACHINE=genericarmv8 bitbake nano
"llvm is not supported"
"openjdk is not supported"
"another-thing-you-do-not-care-for-this-build is not supported"
Quoted 4 lines

it could be said if you do not care for such recipes then BBMASK them and message
well may be it could be make bb.note instead of bb.warn to make it more of FYI kind of thing

"NOTE: llvm does not support aarch64 yet" looks better. But still is worthless.

Quoted 7 lines
Quoted 4 lines

This is how your builds look for not supported architectures.

OE has COMPATIBLE_HOST variable which can be used by recipe maintainers to mark which architectures are supported.

in this case arch does not map to what OE's target arch is so you have to do it twice if you want to use COMPATIBLE_HOST

It has 7 OE architectures: i.86, x86_64, arm, mips(el), powerpc(64) which are then mapped into 5 llvm ones. Can be gathered into one COMPATIBLE_HOST (copied from kexec-tools):

COMPATIBLE_HOST = '(x86_64.*|i.86.*|arm.*|powerpc.*|mips.*)-(linux)'

"mips.*" probably needs to be changed to "mips(el)?" to not cover mips64.

Quoted 2 lines

and suppose a non supported arch becomes supported you have to change both places.

Once it gets supported you will need to add/edit recipe anyway.

#7 lore raw
Quoted 10 lines · Marcin Juszkiewicz
Quoted 2 lines

in this case arch does not map to what OE's target arch is so you have to do it twice if you want to use COMPATIBLE_HOST

It has 7 OE architectures: i.86, x86_64, arm, mips(el), powerpc(64) which are then mapped into 5 llvm ones. Can be gathered into one COMPATIBLE_HOST (copied from kexec-tools):

COMPATIBLE_HOST = '(x86_64.*|i.86.*|arm.*|powerpc.*|mips.*)-(linux)'

"mips.*" probably needs to be changed to "mips(el)?" to not cover mips64.

and how will you fold it into -DLLVM_TARGETS_TO_BUILD=<arch>

where arch is not same as OE's target arch so you need the mapping function anyway was my point.

#8 lore raw

W dniu 11.06.2013 11:07, Khem Raj pisze:

Quoted 10 lines · Marcin Juszkiewicz
Quoted 8 lines
Quoted 3 lines

in this case arch does not map to what OE's target arch is so you have to do it twice if you want to use COMPATIBLE_HOST

It has 7 OE architectures: i.86, x86_64, arm, mips(el), powerpc(64) which are then mapped into 5 llvm ones. Can be gathered into one COMPATIBLE_HOST (copied from kexec-tools):

Quoted 8 lines
Quoted 3 lines

COMPATIBLE_HOST = '(x86_64.*|i.86.*|arm.*|powerpc.*|mips.*)-(linux)'

"mips.*" probably needs to be changed to "mips(el)?" to not cover mips64.

and how will you fold it into -DLLVM_TARGETS_TO_BUILD=<arch>

where arch is not same as OE's target arch so you need the mapping function anyway was my point.

+def get_llvm_arch(d):
+ import bb;
+
+ arch = bb.data.getVar('TARGET_ARCH', d, 1)
+
+ if arch == "x86_64" or arch == "i486" or arch == "i586" or arch ==
"i686":
+ arch = "x86"
+ elif arch == "x86_64":
+ arch = "x86_64"
+ elif arch == "arm":
+ arch = "arm"
+ elif arch == "mipsel" or arch == "mips":
+ arch = "mips"
+ elif arch == "powerpc" or arch == "powerpc64":
+ arch = "powerpc"
+
+ return arch

And done. If you try to build recipe secured by COMPATIBLE_HOST for not compatible architecture then you have to deal with effects.