As per the description, gettext should RDEPEND and DEPEND on gcc[openmp] when built with openmp support. This caused a build failure in Funtoo and we have forked this ebuild to work around this issue. Reproducible: Always
A build log would be handy on this one too. I think we will need to reproduce this before making any changes, unless this is an obvious mistake.
this isn't how we've been handling openmp. gcc isn't the only package that can satisfy the requirement, and gcc has multiple SLOTs. the global description specifically says: Build support for the OpenMP (support parallel computing), requires >=sys-devel/gcc-4.2 built with USE="openmp" other ebuilds utilize: pkg_setup() { if use openmp; then if [[ $(tc-getCC) == *gcc ]] && ! tc-has-openmp; then ewarn "OpenMP is not available in your current selected gcc" die "need openmp capable gcc" fi FORTRAN_NEED_OPENMP=1 fi
Here is background information: https://bugs.funtoo.org/browse/QA-38 https://bugs.funtoo.org/browse/FL-2100 Vapier, from the perspective of user flexibility, your solution of not hard-coding dependencies seems optimal. However, from the perspective of properly building stages, which use gcc, it would seem that having specific dependencies on gcc and openmp USE is optimal, so that these dependencies can be enforced when dependencies are calculated. It seems sub-optimal that ebuilds can't specify via dependencies what compiler features they require, due to the multi-slot nature of gcc. I can work around this using profiles and unfork this ebuild if there isn't going to be a way to do this through deps.
the point of the stage1/2/3 system is to make sure the base system/toolchain is in a sane state to build the rest -- if you want to build everything with openmp, then make sure the initial gcc is set up that way. i don't think that's a particularly compelling use case. the status-quo is sub-optimal, but it isn't really specific to openmp. this is why things like virtual/fortran & fortran.eclass exist: to handle the various compilers that people throw at the system. we give users so much flexibility that it can't safely be expressed in our DEPEND system. at some point the user has to take responsibility for their choices.
Looks like I already updated the profile on the funtoo side to fix this. As this is not a suitable upstream fix, I'll close the bug and unfork this ebuild.
i'm open to discussion to try and make things easier for ebuilds (which is why i didn't punt the bug in the first place). having every ebuild copy & paste openmp checking logic (and then start to fork things) is pretty miserable.
Thanks for being open to that. My first take would be a virtual, but I'm not a huge fan of new-style virtuals. There is a by-design de-coupling between compiler and the system that exists and should exist. The idea of having a DEPEND that says "you need a compiler with openmp support installed" is valid, even if you don't happen to have it set as the active compiler. I think it at least helps, and the more one can rely on the dep system for these things, the more maintainable ebuilds like gettext can be. Gettext would still need to have a check to see if the active compiler supports openmp. Probably what I'd like to see in the future is a standard local system capability database and a standard way of querying it via a standard Portage command, to reduce the need to pull in eclasses to do this type of testing, and to clean up the associated custom code that is needed in ebuilds. These standardized queries could be integrated into the dep resolver in a future version of Portage. I think this is an area that needs some work in Portage in general -- there have been some stabs at dealing with this type of thing, like pkg_pretend. You can read my rant about the problems with pkg_pretend here: http://www.funtoo.org/Ebuild_Functions#pkg_pretend I think it's becoming clear that we need some kind of comprehensive, standardize system to query for underlying system capabilities and then migrate away from the custom stuff. And let's please implement it as a stand-alone command and not just add more junk to monolithic Portage. This is something that maybe I can explore a bit in Funtoo and keep you in the loop. For now, I don't think we have an elegant solution to this problem.
You are right Robbin, as long people simply set their compiler by using system tools, querying the compiler capabilities via some API would be really convenient. But how do you want to handle CC=my-fancy-compiler emerge foo
My suggestion is a significant undertaking and I don't pretend to have all the answers at this point. What I do have is a vision for the tool and the custom eclass code it could replace, and how it could close gaps that currently exist in Portage's dep functionality. As for the details and challenging corner-cases -- best to address these in an actual prototype and see how 'tight' we can make the implementation, and then see what's left over.
