Summary: | Use built_with_use() to check that kdelibs is compiled with arts | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Peter Humphrey <peter> |
Component: | [OLD] KDE | Assignee: | Gentoo KDE team <kde> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | dafank |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
kde_eclass_arts_check.patch
kde_eclass_arts_check.patch |
Description
Peter Humphrey
2004-12-22 07:34:01 UTC
I'm guessing you didn't compile kdelibs with the arts use flag turned on... It seems you're right. I'll correct that and try again - thanks. However, is it proper behaviour for any setting of USE flags to cause a compilation error? Not really, no, but there's no "real good way" to enforce this, unfortunately. Caleb: Can't we add check for existence of e.g. "/usr/kde/3.3/lib/libartskde.la" in the eclass and provide the user with the necessary information this way!? Would be convenient for all of us, imho. :) btw. I'm just compiling koffice with the xpdf fix to be sure that it works, are you caring for kdegraphics? I think vapier added a function in an eclass to perform this type of check - will have to look into it. it's in the eutils eclass: # Hack for people to figure out if a package was built with # certain USE flags # # Usage: built_with_use <DEPEND ATOM> <List of USE flags> # ex: built_with_use xchat gtk2 built_with_use() Just also remember the mail I sent to you about this solution or the split of kdelibs in 2 parts. carlo: yeah, will be as soon as I can. I'm under about 30cm of snow right now, so getting from work to home is a bit difficult :( What about this patch. If you are OK I'll commit it. Created attachment 49953 [details, diff]
kde_eclass_arts_check.patch
Looks good from my POV. Only the error message needs to be surveyed by a native english speaker. You are trying to compile xxx with the "arts" USE flag enabled. However, $(best_version kdelibs) was compiled with this flag disabled. You must either disable this use flag, or recompile $(best_version kdelibs) with this use flag enabled. Dehehe. My english sucks... :P Ok to commit this patch? Created attachment 50073 [details, diff]
kde_eclass_arts_check.patch
Yeah, I like it. I like the error message too. (Originator) Time to commit? Yes please do. I cannot do it now. Ok, committed. Is there a way to disable this checking? Since I'm a KDE developer, I use KDE CVS/HEAD sources and this new arts check causes errors when compiling a KDE program (such as kplayer). Someone on gentoo-user suggested a serious hack to /var/db/pkg/*/*/USE which seems to work. If you are developing you shouldn't disable arts support or you should use your own arts/kdelibs compiled in a local dir. *** Bug 91225 has been marked as a duplicate of this bug. *** I just realized that (almost) all the ebuilds that have hard deps on arts (eg noatun, kdemultimedia-arts, artsplugin-*) are in fact missing those deps in $DEPEND. They only have the pkg_setup check for USE arts. Is there a particular reason for this? Shouldn't we add the dep? It would fix the case where kdelibs isn't installed and the user types 'emerge ... noatun ...'. arts is a dep, and will be merged, and that will turn on the arts use flag via use.defaults, and kdelibs will use it too. Well, that probably wouldn't happen, I don't think portage updates the use flags between sequential emerges based on use.default. Still, why are the deps missing? I must be forgetting something... >Is there a particular reason for this? Shouldn't we add the dep? The implicit kdelibs depedency ant the check via eclass suffices imho. >and that will turn on the arts use flag via use.defaults You know, use.defaults is something I hate about portage, because it you can't rely on the defaults you set. Ebuilds should never tweak portage to set use flags. I know I'm not the only dev who thinks so and one day I will start pushing to bury this broken apprach. |