| Summary: | sys-devel/clang: re-compiles large parts of sys-devel/llvm | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Hristo Venev <hristo> |
| Component: | [OLD] Development | Assignee: | Bernard Cafarelli <voyageur> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | bug, mgorny, nikoli, ryao |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Hristo Venev
2013-06-07 14:22:37 UTC
(In reply to Hristo Venev from comment #0) > LLVM is currently being compiled twice - once in sys-devel/llvm and once in > sys-devel/clang. AFAIK upstream they are supposed to be built together. I > propose adding IUSE=clang to sys-devel/llvm, which, when enabled, adds clang > to SRC_URI and extracts it. Then clang gets built and installed if required. > sys-devel/clang will be an empty ebuild depending on sys-devel/llvm[clang]. Are they? Since when? Did you check or are you making plain assumptions without even checking? Protip: emake ... clang-only But I'll rebuild them just to make sure. > Furthermore, I propose adding LLVM_TARGETS to USE_EXPAND and adding > llvm_targets_[target] to IUSE in sys-devel/llvm. --enable-targets=host,[the > ones with enabled USE flags]. This way it can be easily controlled which > exact targets must be built. No USE_EXPAND for a single package. And I'd say open another bug if there weren't a bug for it already open. Then I should say: search first, then report. I checked again. The same as last time, while compiling =sys-devel/clang-9999, LLVM sources were compiled and libLLVM*.a were created. When 'emake install' is invoked, the current directory is set to /tools/clang, so no LLVM libraries are installed - only the clang ones. As for the proper multitarget support, maybe the llvm_targets_ prefix should be removed from the USE flags. I'll fix my ebuilds. LLVM Makefile, lines 80-84, line 166: If clang-only is the target, /tools (except for /tools/clang and /tools/lto), /docs and /unittests are disabled but the libraries are still built. I was wrong after all. Only ~90% of LLVM is recompiled with clang. (In reply to Hristo Venev from comment #2) > As for the proper multitarget support, maybe the llvm_targets_ prefix should > be removed from the USE flags. I'll fix my ebuilds. Who does need this? Does it benefit anyone really? How many benefit is given by fine-picking something else than 'minimum' and 'all' sets that are controlled by USE=multitarget. Adding flags for the sake of adding flags just messes up stuff and causes rebuilds when something changes. > LLVM Makefile, lines 80-84, line 166: If clang-only is the target, /tools > (except for /tools/clang and /tools/lto), /docs and /unittests are disabled > but the libraries are still built. I was wrong after all. Only ~90% of LLVM > is recompiled with clang. Ok, then the issue is valid. However, your solution is far from perfect. Am I missing something, or are you actually building clang twice (for multilib)? USE_EXPAND="SANE_BACKENDS" is used by guess how many packages? 1. According to a simple bash one-liner, I found the following single-package USE_EXPAND: APACHE2_MODULES APACHE2_MPMS CALLIGRA_FEATURES CAMERAS COLLECTD_PLUGINS DRACUT_MODULES DVB_CARDS ENLIGHTENMENT_MODULES FFTOOLS GPSD_PROTOCOLS GRUB_PLATFORMS LIBREOFFICE_EXTENSIONS LIRC_DEVICES MISDN_CARDS NETBEANS_MODULES NGINX_MODULES_HTTP NGINX_MODULES_MAIL OFED_DRIVERS OPENMPI_FABRICS OPENMPI_OFED_FEATURES OPENMPI_RM QEMU_SOFTMMU_TARGETS SANE_BACKENDS VOICEMAIL_STORAGE XTABLES_ADDONS There's an additional list of unused USE_EXPAND: FCDSL_CARDS FOO2ZJS_DEVICES FRITZCAPI_CARDS MONKEYD_PLUGINS OFFICE_IMPLEMENTATION These lists may have false positives or false negatives. And the glorious one-liner: for i in `emerge --info | sed -nE 's/^USE_EXPAND="(.*)"$/\1/p'` ; do small=`echo $i | tr '[A-Z]' '[a-z]'` ; cnt=`sqlite3 /var/cache/edb/dep/usr/portage.sqlite 'SELECT portage_package_key from portage_packages where IUSE LIKE "%'$small'_%";' | sed -E 's:(.*)/(.*)-[0-9]+(\.[0-9]+)*.*:\1/\2:' | sort | uniq | wc -l` ; if [ $cnt == 1 ] ; then echo -n "$i " ; fi ; done # All hail the portage sqlite backend! So, about half of USE_EXPAND's are, in fact, used by a single package. Back to the why-I-think-this-is-needed thing. As many packages have hardware support configurability, why should LLVM not? clang is required for OpenCL by mesa. So if I want multilib mesa (which I do) I need multilib clang. I do in fact think the current way of doing multilib is utterly stupid but it is what it is and until something better is proposed I will have to deal with the status quo. (In reply to Hristo Venev from comment #4) > USE_EXPAND="SANE_BACKENDS" is used by guess how many packages? 1. > According to a simple bash one-liner, I found the following single-package > USE_EXPAND: > APACHE2_MODULES APACHE2_MPMS CALLIGRA_FEATURES CAMERAS COLLECTD_PLUGINS > DRACUT_MODULES DVB_CARDS ENLIGHTENMENT_MODULES FFTOOLS GPSD_PROTOCOLS > GRUB_PLATFORMS LIBREOFFICE_EXTENSIONS LIRC_DEVICES MISDN_CARDS > NETBEANS_MODULES NGINX_MODULES_HTTP NGINX_MODULES_MAIL OFED_DRIVERS > OPENMPI_FABRICS OPENMPI_OFED_FEATURES OPENMPI_RM QEMU_SOFTMMU_TARGETS > SANE_BACKENDS VOICEMAIL_STORAGE XTABLES_ADDONS > There's an additional list of unused USE_EXPAND: > FCDSL_CARDS FOO2ZJS_DEVICES FRITZCAPI_CARDS MONKEYD_PLUGINS > OFFICE_IMPLEMENTATION Yes, there was a mail about that lately. You should not point other people screwups to justify your decision. > clang is required for OpenCL by mesa. So if I want multilib mesa (which I > do) I need multilib clang. I do in fact think the current way of doing > multilib is utterly stupid but it is what it is and until something better > is proposed I will have to deal with the status quo. Does it? And does your concept of 32-bit clang match anything supported anywhere? It looks like a semi-random copy to me. Ok, to set some points straight. Wine has USE=opencl -- which means that at some point we will likely want to have 32-bit clang. I'm not sure if we want to work on it now, though. It would be probably less problematic to do that with cmake; however, I'm not sure if upstream will fix it till 3.4. What I'm most worried at is the build time and disk space requirements. As you pointed out, building llvm twice is bad. Honestly I dislike building llvm and clang in one run but if it's inevitable, it's better than building llvm twice. But I'd rather try to hack it to reuse already-build LLVM within clang build, as cmake does. I feel like having a single ebuild build two variants of LLVM and clang at the same time is a bit too much for some of our users. Oh, it seems that I've noticed this already... *** This bug has been marked as a duplicate of bug 426808 *** |
