Summary: | New Ebuilds for Enlightenment DR17 CVS, ICC support enabled. | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Ed Presutti <epresutti> |
Component: | New packages | Assignee: | SpanKY <vapier> |
Status: | RESOLVED WONTFIX | ||
Severity: | enhancement | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
EDB Ebuild with ICC 9.x support
EET Ebuild with ICC 9.x support Embryo Ebuild with ICC 9.x support Edje Ebuild with ICC 9.x support ImLib2 Ebuild with ICC 9.x support ImLib2_Loaders Ebuild with ICC 9.x support Ecore Ebuild with ICC 9.x support Evas Ebuild with ICC 9.x support Enlightenment DR17 Ebuild with ICC 9.x support Epeg Ebuild with ICC 9.x support Epsilon Ebuild with ICC 9.x support EWL Ebuild with ICC 9.x support Emotion Ebuild with ICC 9.x support |
Description
Ed Presutti
2005-07-05 11:04:15 UTC
Created attachment 62686 [details]
EDB Ebuild with ICC 9.x support
Created attachment 62687 [details]
EET Ebuild with ICC 9.x support
Created attachment 62688 [details]
Embryo Ebuild with ICC 9.x support
Created attachment 62689 [details]
Edje Ebuild with ICC 9.x support
Created attachment 62690 [details]
ImLib2 Ebuild with ICC 9.x support
Created attachment 62691 [details]
ImLib2_Loaders Ebuild with ICC 9.x support
Created attachment 62692 [details]
Ecore Ebuild with ICC 9.x support
Created attachment 62693 [details]
Evas Ebuild with ICC 9.x support
Created attachment 62694 [details]
Enlightenment DR17 Ebuild with ICC 9.x support
Created attachment 62695 [details]
Epeg Ebuild with ICC 9.x support
Created attachment 62696 [details]
Epsilon Ebuild with ICC 9.x support
Created attachment 62700 [details]
EWL Ebuild with ICC 9.x support
Created attachment 62703 [details]
Emotion Ebuild with ICC 9.x support
Would it be better to make an eclass for ebuilds that want to support ICC? That way, an ebuild maintainer wouldn't have to worry about the ICC stuff, just set up the IUSE section and inherit from the ICC eclass? Comments? Ed: Please change the mimetyes of the attached files to text/plain. In general a diff is preferable. So much for the "auto" mime type detection in Bugzilla. :-) Mime types corrected. If you'd like, I can re-submit everything in DIFF format. i hate to say you wasted your time, but i think you have ... first of all, you could have put that one pkg_setup() into enlightenment.eclass and it should work fine for all e packages second of all, i dont support USE=icc ... manipulating CC/CXXFLAGS/CFLAGS based upon USE is wrong imo (In reply to comment #17) > i hate to say you wasted your time, but i think you have ... > Definitely not. I need the ebuild practice. :-) > first of all, you could have put that one pkg_setup() into enlightenment.eclass > and it should work fine for all e packages > Agreed, i'd definitely like to move the common functions into an eclass. I'd like to do an ICC eclass and just add it to the inherit line in the ebuild. That way I wouldn't have to soil the enlightenment eclass with ICC stuff. > second of all, i dont support USE=icc ... manipulating CC/CXXFLAGS/CFLAGS based > upon USE is wrong imo What would you recommend for people that want to use ICC with Enlightenment DR17 then? I'm just trying to use ICC wherever possible, as i'm experiencing a 7%-15% speed increase with no noticable functionality loss. (So far) icc should be utilized on a system basis ... perhaps gcc-config would switch to exporting CC to icc and reseting your CXXFLAGS/CFLAGS for you ... either way we've been slowly weeding out the USE flags (like diet/uclibc) which control toolchain behavior (In reply to comment #19) > icc should be utilized on a system basis ... perhaps gcc-config would switch to > exporting CC to icc and reseting your CXXFLAGS/CFLAGS for you ... > That would be a good angle. I suppose that only GCC would be supported, but for those of us who want to play around, it would definitely work. Besides, ICC still isn't 100% compatible with GCC and would be almost impossible to support. > either way we've been slowly weeding out the USE flags (like diet/uclibc) which > control toolchain behavior That's understandable. Thanks for your help on this one. I'll just back off of the ICC thing for a while. If the Gentoo team ever gets interested in building support for alternate compilers, i'd be happy to help test. the other reason icc support in Gentoo isnt bigger is because we havent had good developer support for it ... every once in a while we'll get a Gentoo dev who is supposed to support icc but then they disappear |