Patchwork [meta-oe] llvm3.2: new recipe

login
register
mail settings
Submitter Jonathan Liu
Date June 2, 2013, 9:33 a.m.
Message ID <1370165592-15697-1-git-send-email-net147@gmail.com>
Download mbox | patch
Permalink /patch/51049/
State Superseded, archived
Headers show

Comments

Jonathan Liu - June 2, 2013, 9:33 a.m.
arm_fenv_uclibc.patch was copied from llvm2.9 recipe.

Signed-off-by: Jonathan Liu <net147@gmail.com>
---
 .../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
Marcin Juszkiewicz - June 2, 2013, 9:55 a.m.
W dniu 02.06.2013 11:33, Jonathan Liu pisze:
> +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"
> +    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.
Jonathan Liu - June 3, 2013, 4:30 a.m.
On 2 June 2013 19:55, Marcin Juszkiewicz <marcin@juszkiewicz.com.pl> wrote:
> W dniu 02.06.2013 11:33, Jonathan Liu pisze:
>> +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"
>> +    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
Khem Raj - June 11, 2013, 7:48 a.m.
On Sun, Jun 2, 2013 at 2:55 AM, Marcin Juszkiewicz
<marcin@juszkiewicz.com.pl> wrote:
> W dniu 02.06.2013 11:33, Jonathan Liu pisze:
>> +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"
>> +    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

> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Marcin Juszkiewicz - June 11, 2013, 7:55 a.m.
W dniu 11.06.2013 09:48, Khem Raj pisze:
> On Sun, Jun 2, 2013 at 2:55 AM, Marcin Juszkiewicz
> <marcin@juszkiewicz.com.pl> wrote:
>> W dniu 02.06.2013 11:33, Jonathan Liu pisze:
>>> +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"
>>> +    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

$ 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.
Khem Raj - June 11, 2013, 8:03 a.m.
On Tue, Jun 11, 2013 at 12:55 AM, Marcin Juszkiewicz
<marcin@juszkiewicz.com.pl> wrote:
> W dniu 11.06.2013 09:48, Khem Raj pisze:
>> On Sun, Jun 2, 2013 at 2:55 AM, Marcin Juszkiewicz
>> <marcin@juszkiewicz.com.pl> wrote:
>>> W dniu 02.06.2013 11:33, Jonathan Liu pisze:
>>>> +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"
>>>> +    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
>
> $ 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

> 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.

> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
Marcin Juszkiewicz - June 11, 2013, 8:54 a.m.
W dniu 11.06.2013 10:03, Khem Raj pisze:
> On Tue, Jun 11, 2013 at 12:55 AM, Marcin Juszkiewicz
>> W dniu 11.06.2013 09:48, Khem Raj pisze:

>>> 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

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

>> 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.

> 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.
Khem Raj - June 11, 2013, 9:07 a.m.
On Jun 11, 2013, at 1:54 AM, Marcin Juszkiewicz <marcin@juszkiewicz.com.pl> wrote:

>> 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.
Marcin Juszkiewicz - June 11, 2013, 9:10 a.m.
W dniu 11.06.2013 11:07, Khem Raj pisze:
> 
> On Jun 11, 2013, at 1:54 AM, Marcin Juszkiewicz <marcin@juszkiewicz.com.pl> wrote:
> 
>>> 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.

+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.

Patch

diff --git a/meta-oe/recipes-core/llvm/llvm3.2/arm_fenv_uclibc.patch b/meta-oe/recipes-core/llvm/llvm3.2/arm_fenv_uclibc.patch
new file mode 100644
index 0000000..c3ae494
--- /dev/null
+++ b/meta-oe/recipes-core/llvm/llvm3.2/arm_fenv_uclibc.patch
@@ -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
diff --git a/meta-oe/recipes-core/llvm/llvm3.2_3.2.bb b/meta-oe/recipes-core/llvm/llvm3.2_3.2.bb
new file mode 100644
index 0000000..cfdc68c
--- /dev/null
+++ b/meta-oe/recipes-core/llvm/llvm3.2_3.2.bb
@@ -0,0 +1,116 @@ 
+DESCRIPTION = "The Low Level Virtual Machine"
+HOMEPAGE = "http://llvm.org"
+# 3-clause BSD-like
+LICENSE = "NCSA"
+LIC_FILES_CHKSUM = "file://LICENSE.TXT;md5=60fdd7739841f04a2ce2171a726be8f3"
+
+DEPENDS = "libffi llvm-common"
+
+SRC_URI = "http://llvm.org/releases/${PV}/llvm-${PV}.src.tar.gz"
+SRC_URI_append_libc-uclibc = " file://arm_fenv_uclibc.patch "
+
+SRC_URI[md5sum] = "71610289bbc819e3e15fdd562809a2d7"
+SRC_URI[sha256sum] = "125090c4d26740f1d5e9838477c931ed7d9ad70d599ba265f46f3a42cb066343"
+
+S = "${WORKDIR}/llvm-${PV}.src"
+
+inherit autotools perlnative pythonnative
+
+LLVM_ARCH = "${@get_llvm_arch(d)}"
+LLVM_BUILD_DIR = "${WORKDIR}/llvm-${PV}.build"
+LLVM_INSTALL_DIR = "${WORKDIR}/llvm-install"
+LLVM_RELEASE = "3.2"
+LLVM_DIR = "llvm${LLVM_RELEASE}"
+
+EXTRA_OECONF += "--disable-assertions \
+                 --enable-debug-runtime \
+                 --disable-expensive-checks \
+                 --enable-bindings=none \
+                 --enable-keep-symbols \
+                 --enable-libffi \
+                 --enable-optimized \
+                 --enable-shared \
+                 --enable-targets=${LLVM_ARCH}"
+EXTRA_OEMAKE += "REQUIRES_RTTI=1"
+FILES_${PN} = "${libdir}/lib*.so \
+               ${libdir}/${LLVM_DIR}/*"
+FILES_${PN}-dbg = "${bindir}/${LLVM_DIR}/.debug \
+                   ${libdir}/${LLVM_DIR}/.debug \
+                   ${libdir}/.debug \
+                   /usr/src/debug"
+FILES_${PN}-dev = "${bindir}/${LLVM_DIR} \
+                   ${includedir}/${LLVM_DIR} \
+                   ${libdir}/${LLVM_DIR}/BugpointPasses.so \
+                   ${libdir}/${LLVM_DIR}/LLVMHello.so"
+FILES_${PN}-static-dev = "${libdir}/${LLVM_DIR}/*.a"
+FILES_SOLIBSDEV = ""
+
+do_configure_prepend() {
+	# Remove RPATHs
+	sed -i 's:$(RPATH) -Wl,$(\(ToolDir\|LibDir\|ExmplDir\))::g' Makefile.rules
+
+	# Drop "svn" suffix from version string
+	sed -i 's/3\.2svn/3.2/g' configure
+
+	# Fix paths in llvm-config
+	sed -i "s|sys::path::parent_path(CurrentPath))|sys::path::parent_path(sys::path::parent_path(CurrentPath)))|g" tools/llvm-config/llvm-config.cpp
+	sed -i "s|/bin|/bin/${LLVM_DIR}|g" tools/llvm-config/llvm-config.cpp
+	sed -i "s|/include|/include/${LLVM_DIR}|g" tools/llvm-config/llvm-config.cpp
+	sed -i "s|/lib|/lib/${LLVM_DIR}|g" tools/llvm-config/llvm-config.cpp
+
+	# Fails to build unless using separate directory from source
+	mkdir -p ${LLVM_BUILD_DIR}
+	cd ${LLVM_BUILD_DIR}
+}
+
+do_compile() {
+	cd ${LLVM_BUILD_DIR}
+	oe_runmake CC=${BUILD_CC} CXX=${BUILD_CXX} cross-compile-build-tools
+	oe_runmake
+}
+
+do_install() {
+	cd ${LLVM_BUILD_DIR}
+	oe_runmake DESTDIR=${LLVM_INSTALL_DIR} install
+
+	mv ${LLVM_INSTALL_DIR}${bindir}/${HOST_SYS}-llvm-config-host ${LLVM_INSTALL_DIR}/llvm-config-host
+
+	install -d ${D}${bindir}/${LLVM_DIR}
+	mv ${LLVM_INSTALL_DIR}${bindir}/* ${D}${bindir}/${LLVM_DIR}/
+
+	install -d ${D}${includedir}/${LLVM_DIR}
+	mv ${LLVM_INSTALL_DIR}${includedir}/* ${D}${includedir}/${LLVM_DIR}/
+
+	install -d ${D}${libdir}/${LLVM_DIR}
+	mv ${LLVM_INSTALL_DIR}${libdir}/* ${D}${libdir}/${LLVM_DIR}/
+
+	install -d ${D}${docdir}/${LLVM_DIR}
+	mv ${LLVM_INSTALL_DIR}${prefix}/docs/llvm/* ${D}${docdir}/${LLVM_DIR}
+}
+
+SYSROOT_PREPROCESS_FUNCS += "llvm_sysroot_preprocess"
+
+llvm_sysroot_preprocess() {
+	install -d ${SYSROOT_DESTDIR}${bindir_crossscripts}
+	mv ${LLVM_INSTALL_DIR}/llvm-config-host ${SYSROOT_DESTDIR}${bindir_crossscripts}/llvm-config${LLVM_RELEASE}
+}
+
+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"
+    else:
+        bb.warn("%s does not support %s yet" % (bb.data.getVar('PN', d, 1), arch) );
+
+    return arch