Re: [e-users] Working easy_e17.sh/configure parameters for 'coolest' and most feature rich E17
On Tue, 8 Feb 2011 15:36:25 +0100 Marc Koschewski said: > Hi all, > > due the amount of configure flags for the verious parts of E17 I just > lost my overview of these completely. > > Does anyone of you - probably people using easy_e17.sh as well - hve a working > config for a _fast_ (besides CFLAGS/LDFLAGS), cool and feature rich E17 > installation that could be provided? Currently I rendered my easy_e17.sh > parameters into something, that let's E17 compile but not work anymore. And > before I try to get back to my old config, I just wanted to ask if anyone has > some neat stuff handy... dont use ANY --enable/disable configure flags. defaults are what you want. using any such flags you do at your own risk. > Thanks anyone, > Marc > > -- > Marc Koschewski > > -- > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > ___ > enlightenment-users mailing list > enlightenment-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-users > -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Working easy_e17.sh/configure parameters for 'coolest' and most feature rich E17
* Carsten Haitzler [2011-02-09 10:10:29 +0900]: > On Tue, 8 Feb 2011 15:36:25 +0100 Marc Koschewski said: > > > Hi all, > > > > due the amount of configure flags for the verious parts of E17 I just > > lost my overview of these completely. > > > > Does anyone of you - probably people using easy_e17.sh as well - hve a > > working > > config for a _fast_ (besides CFLAGS/LDFLAGS), cool and feature rich E17 > > installation that could be provided? Currently I rendered my easy_e17.sh > > parameters into something, that let's E17 compile but not work anymore. And > > before I try to get back to my old config, I just wanted to ask if anyone > > has > > some neat stuff handy... > > dont use ANY --enable/disable configure flags. defaults are what you want. > using any such flags you do at your own risk. OK, that's what I just did besides the --enable-gl-flavor-gles and --enable-gles-variety-sgx options to evas (used because Gentoo did it as well in their ebuilds with my USE flags. The problem I have now is that I suffer a really annoying windows re-focus behavior. A window activated on desktop A is no longer active when I switch to desktop B, switch between windows there and go back to desktop A. On desktop A there's no active focus. If I just go to desktop B and back to desktop A the focus remained. I have the focusing option left as they were and it used to work prior to this change. "Refocus last window on desktop switch" is enabled. Any idea anyone? Marc > > > Thanks anyone, > > Marc > > > > -- > > Marc Koschewski > > > > -- > > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > > Pinpoint memory and threading errors before they happen. > > Find and fix more than 250 security defects in the development cycle. > > Locate bottlenecks in serial and parallel code that limit performance. > > http://p.sf.net/sfu/intel-dev2devfeb > > ___ > > enlightenment-users mailing list > > enlightenment-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-users > > > > > -- > - Codito, ergo sum - "I code, therefore I am" -- > The Rasterman (Carsten Haitzler)ras...@rasterman.com > > -- Marc Koschewski -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Working easy_e17.sh/configure parameters for 'coolest' and most feature rich E17
* Marc Koschewski [2011-02-09 09:07:45 +0100]: > * Carsten Haitzler [2011-02-09 10:10:29 +0900]: > > > On Tue, 8 Feb 2011 15:36:25 +0100 Marc Koschewski > > said: > > > > > Hi all, > > > > > > due the amount of configure flags for the verious parts of E17 I just > > > lost my overview of these completely. > > > > > > Does anyone of you - probably people using easy_e17.sh as well - hve a > > > working > > > config for a _fast_ (besides CFLAGS/LDFLAGS), cool and feature rich E17 > > > installation that could be provided? Currently I rendered my easy_e17.sh > > > parameters into something, that let's E17 compile but not work anymore. > > > And > > > before I try to get back to my old config, I just wanted to ask if anyone > > > has > > > some neat stuff handy... > > > > dont use ANY --enable/disable configure flags. defaults are what you want. > > using any such flags you do at your own risk. > > OK, that's what I just did besides the --enable-gl-flavor-gles and > --enable-gles-variety-sgx options to evas (used because Gentoo did it as well > in > their ebuilds with my USE flags. > > The problem I have now is that I suffer a really annoying windows re-focus > behavior. A window activated on desktop A is no longer active when I switch to > desktop B, switch between windows there and go back to desktop A. On desktop A > there's no active focus. If I just go to desktop B and back to desktop A the > focus remained. > > I have the focusing option left as they were and it used to work prior to this > change. "Refocus last window on desktop switch" is enabled. > > Any idea anyone? More: the focus keeps being set on the focused window on desktop A _after_ switching to desktop B. Once I switch to desktop B and hit ie. it's 'printed' in the xterm that was focused on desktop A. After some ALT-TAB window switching on desktop B I can type the into that window. I assume that the focus is then left on that window once I go back to desktop A forcing me to refocus the window again. Again in short: seems like the 'Refocus last window on desktop switch" is broken... CC'ing enlightenment-devel... Marc > > Marc > > > > > > Thanks anyone, > > > Marc > > > > > > -- > > > Marc Koschewski > > > > > > -- > > > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > > > Pinpoint memory and threading errors before they happen. > > > Find and fix more than 250 security defects in the development cycle. > > > Locate bottlenecks in serial and parallel code that limit performance. > > > http://p.sf.net/sfu/intel-dev2devfeb > > > ___ > > > enlightenment-users mailing list > > > enlightenment-users@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-users > > > > > > > > > -- > > - Codito, ergo sum - "I code, therefore I am" -- > > The Rasterman (Carsten Haitzler)ras...@rasterman.com > > > > > > -- > Marc Koschewski > > -- > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > ___ > enlightenment-users mailing list > enlightenment-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-users > -- Marc Koschewski -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Working easy_e17.sh/configure parameters for 'coolest' and most feature rich E17
On Wed, 9 Feb 2011 09:07:45 +0100 Marc Koschewski said: > * Carsten Haitzler [2011-02-09 10:10:29 +0900]: > > > On Tue, 8 Feb 2011 15:36:25 +0100 Marc Koschewski > > said: > > > > > Hi all, > > > > > > due the amount of configure flags for the verious parts of E17 I just > > > lost my overview of these completely. > > > > > > Does anyone of you - probably people using easy_e17.sh as well - hve a > > > working config for a _fast_ (besides CFLAGS/LDFLAGS), cool and feature > > > rich E17 installation that could be provided? Currently I rendered my > > > easy_e17.sh parameters into something, that let's E17 compile but not > > > work anymore. And before I try to get back to my old config, I just > > > wanted to ask if anyone has some neat stuff handy... > > > > dont use ANY --enable/disable configure flags. defaults are what you want. > > using any such flags you do at your own risk. > > OK, that's what I just did besides the --enable-gl-flavor-gles and > --enable-gles-variety-sgx options to evas (used because Gentoo did it as well > in their ebuilds with my USE flags. > > The problem I have now is that I suffer a really annoying windows re-focus > behavior. A window activated on desktop A is no longer active when I switch to > desktop B, switch between windows there and go back to desktop A. On desktop A > there's no active focus. If I just go to desktop B and back to desktop A the > focus remained. > > I have the focusing option left as they were and it used to work prior to this > change. "Refocus last window on desktop switch" is enabled. > > Any idea anyone? wouldnt be related to configure options - as such i dont see this issue : ( don't know. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Working easy_e17.sh/configure parameters for 'coolest' and most feature rich E17
Apparently, though unproven, at 03:10 on Wednesday 09 February 2011, Carsten Haitzler did opine thusly: > On Tue, 8 Feb 2011 15:36:25 +0100 Marc Koschewski said: > > Hi all, > > > > due the amount of configure flags for the verious parts of E17 I just > > lost my overview of these completely. > > > > Does anyone of you - probably people using easy_e17.sh as well - hve a > > working config for a _fast_ (besides CFLAGS/LDFLAGS), cool and feature > > rich E17 installation that could be provided? Currently I rendered my > > easy_e17.sh parameters into something, that let's E17 compile but not > > work anymore. And before I try to get back to my old config, I just > > wanted to ask if anyone has some neat stuff handy... > > dont use ANY --enable/disable configure flags. defaults are what you want. > using any such flags you do at your own risk. That breaks Gentoo in all sorts of horrible ways. -- alan dot mckinnon at gmail dot com -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Working easy_e17.sh/configure parameters for 'coolest' and most feature rich E17
On 02/09/2011 05:47 PM, Alan McKinnon wrote: > Apparently, though unproven, at 03:10 on Wednesday 09 February 2011, Carsten > Haitzler did opine thusly: > >> On Tue, 8 Feb 2011 15:36:25 +0100 Marc Koschewski > said: >>> Hi all, >>> >>> due the amount of configure flags for the verious parts of E17 I just >>> lost my overview of these completely. >>> >>> Does anyone of you - probably people using easy_e17.sh as well - hve a >>> working config for a _fast_ (besides CFLAGS/LDFLAGS), cool and feature >>> rich E17 installation that could be provided? Currently I rendered my >>> easy_e17.sh parameters into something, that let's E17 compile but not >>> work anymore. And before I try to get back to my old config, I just >>> wanted to ask if anyone has some neat stuff handy... >> >> dont use ANY --enable/disable configure flags. defaults are what you want. >> using any such flags you do at your own risk. > > That breaks Gentoo in all sorts of horrible ways. Strange. My broken e17 + gentoo is somehow chugging along for a good 4th year now ;) /me starts looking for the broken pieces ... -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Working easy_e17.sh/configure parameters for 'coolest' and most feature rich E17
* P Purkayastha [2011-02-09 20:28:40 +0800]: > On 02/09/2011 05:47 PM, Alan McKinnon wrote: > > Apparently, though unproven, at 03:10 on Wednesday 09 February 2011, Carsten > > Haitzler did opine thusly: > > > >> On Tue, 8 Feb 2011 15:36:25 +0100 Marc Koschewski > > said: > >>> Hi all, > >>> > >>> due the amount of configure flags for the verious parts of E17 I just > >>> lost my overview of these completely. > >>> > >>> Does anyone of you - probably people using easy_e17.sh as well - hve a > >>> working config for a _fast_ (besides CFLAGS/LDFLAGS), cool and feature > >>> rich E17 installation that could be provided? Currently I rendered my > >>> easy_e17.sh parameters into something, that let's E17 compile but not > >>> work anymore. And before I try to get back to my old config, I just > >>> wanted to ask if anyone has some neat stuff handy... > >> > >> dont use ANY --enable/disable configure flags. defaults are what you want. > >> using any such flags you do at your own risk. > > > > That breaks Gentoo in all sorts of horrible ways. As long as you do not remove some libs from the system it works well. And I have my /home/marc/bin within the revdep-rebuild path so it gets checked anyways - it doesn't get rebuilt, sure, but I update E17 every anyways. > > Strange. My broken e17 + gentoo is somehow chugging along for a good 4th > year now ;) > /me starts looking for the broken pieces ... Irony.. :P > > -- > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > ___ > enlightenment-users mailing list > enlightenment-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-users > > -- Marc Koschewski -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Working easy_e17.sh/configure parameters for 'coolest' and most feature rich E17
Apparently, though unproven, at 14:28 on Wednesday 09 February 2011, P Purkayastha did opine thusly: > >> dont use ANY --enable/disable configure flags. defaults are what you > >> want. using any such flags you do at your own risk. > > > > That breaks Gentoo in all sorts of horrible ways. > > Strange. My broken e17 + gentoo is somehow chugging along for a good 4th > year now ;) > /me starts looking for the broken pieces ... I don't mean it breaks Gentoo such that bits of EFL lie all over the floor right away. Gentoo, by design, lets the user control what features are installed and what is not installed via USE flags. This sets up dependencies. When a build script on Gentoo relies on automagic enabling of features, only stuff that is already present is used. This is NOT up to some distro packager, it is up to the user. There is no method to set up optional dependencies so the usual route is to DEPEND on nothing and rely on magic (or user vigilance) or DEPEND on everything which makes the average Gentoo user freak out. emerge --depclean is then useless at helping remove unneeded deps later on. But you know all this already right? Developers can by all means use automagic deps; I'm opposed to the practice myself but I can't stop devs doing it. But also provide explicit --enable/-- disable options in ./configure for source based distros. -- alan dot mckinnon at gmail dot com -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Working easy_e17.sh/configure parameters for 'coolest' and most feature rich E17
On Thu, 10 Feb 2011 00:26:11 +0200 Alan McKinnon said: > Apparently, though unproven, at 14:28 on Wednesday 09 February 2011, P > Purkayastha did opine thusly: > > > > >> dont use ANY --enable/disable configure flags. defaults are what you > > >> want. using any such flags you do at your own risk. > > > > > > That breaks Gentoo in all sorts of horrible ways. > > > > Strange. My broken e17 + gentoo is somehow chugging along for a good 4th > > year now ;) > > /me starts looking for the broken pieces ... > > > I don't mean it breaks Gentoo such that bits of EFL lie all over the floor > right away. > > Gentoo, by design, lets the user control what features are installed and what > is not installed via USE flags. This sets up dependencies. > > When a build script on Gentoo relies on automagic enabling of features, only > stuff that is already present is used. This is NOT up to some distro > packager, it is up to the user. There is no method to set up optional > dependencies so the usual route is to DEPEND on nothing and rely on magic (or > user vigilance) or DEPEND on everything which makes the average Gentoo user > freak out. > > emerge --depclean is then useless at helping remove unneeded deps later on. > > But you know all this already right? > > Developers can by all means use automagic deps; I'm opposed to the practice > myself but I can't stop devs doing it. But also provide explicit --enable/-- > disable options in ./configure for source based distros. gentoo allows users to configure the builds of their libs. this also allows them to shoot themselves in their feet and screw it up. eg disable a feature and then find that e17 needs it. and then the gentoo users come running here to us e devs complaining e is broken and how they should fix it. gentoo is broken already. it just foists work onto US developers as users do things they have not the slightest clue about. those swizzle knobs are for people who know what the hell they are enabling or disabling and what the consequences will be. this problem has gotten so bad that i'm becoming of the opinion that we should cease having any configuration you can change at compile time because it was never intended to be exposed to "users". but it is and its causing US trouble and US work because gentoo is going around doing just that. the result will be that people who want to change things for specific good reasons and know what they are doing now have to PATCH the build rather than just provide some --enable/disable flags. so to gentoo... STOP WITH THE USE FLAGS! JUST STOP! ENOUGH ALREADY! -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Working easy_e17.sh/configure parameters for 'coolest' and most feature rich E17
On Wed, 9 Feb 2011 11:47:33 +0200 Alan McKinnon said: > Apparently, though unproven, at 03:10 on Wednesday 09 February 2011, Carsten > Haitzler did opine thusly: > > > On Tue, 8 Feb 2011 15:36:25 +0100 Marc Koschewski > said: > > > Hi all, > > > > > > due the amount of configure flags for the verious parts of E17 I just > > > lost my overview of these completely. > > > > > > Does anyone of you - probably people using easy_e17.sh as well - hve a > > > working config for a _fast_ (besides CFLAGS/LDFLAGS), cool and feature > > > rich E17 installation that could be provided? Currently I rendered my > > > easy_e17.sh parameters into something, that let's E17 compile but not > > > work anymore. And before I try to get back to my old config, I just > > > wanted to ask if anyone has some neat stuff handy... > > > > dont use ANY --enable/disable configure flags. defaults are what you want. > > using any such flags you do at your own risk. > > That breaks Gentoo in all sorts of horrible ways. gentoo is broken already. :) -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Working easy_e17.sh/configure parameters for 'coolest' and most feature rich E17
Apparently, though unproven, at 01:29 on Thursday 10 February 2011, Carsten Haitzler did opine thusly: > On Thu, 10 Feb 2011 00:26:11 +0200 Alan McKinnon said: > > Apparently, though unproven, at 14:28 on Wednesday 09 February 2011, P > > > > Purkayastha did opine thusly: > > > >> dont use ANY --enable/disable configure flags. defaults are what you > > > >> want. using any such flags you do at your own risk. > > > > > > > > That breaks Gentoo in all sorts of horrible ways. > > > > > > Strange. My broken e17 + gentoo is somehow chugging along for a good > > > 4th year now ;) > > > /me starts looking for the broken pieces ... > > > > I don't mean it breaks Gentoo such that bits of EFL lie all over the > > floor right away. > > > > Gentoo, by design, lets the user control what features are installed and > > what is not installed via USE flags. This sets up dependencies. > > > > When a build script on Gentoo relies on automagic enabling of features, > > only stuff that is already present is used. This is NOT up to some > > distro packager, it is up to the user. There is no method to set up > > optional dependencies so the usual route is to DEPEND on nothing and > > rely on magic (or user vigilance) or DEPEND on everything which makes > > the average Gentoo user freak out. > > > > emerge --depclean is then useless at helping remove unneeded deps later > > on. > > > > But you know all this already right? > > > > Developers can by all means use automagic deps; I'm opposed to the > > practice myself but I can't stop devs doing it. But also provide > > explicit --enable/-- disable options in ./configure for source based > > distros. > > gentoo allows users to configure the builds of their libs. this also allows > them to shoot themselves in their feet and screw it up. eg disable a > feature and then find that e17 needs it. and then the gentoo users come > running here to us e devs complaining e is broken and how they should fix > it. gentoo is broken already. it just foists work onto US developers as > users do things they have not the slightest clue about. those swizzle > knobs are for people who know what the hell they are enabling or disabling > and what the consequences will be. > > this problem has gotten so bad that i'm becoming of the opinion that we > should cease having any configuration you can change at compile time > because it was never intended to be exposed to "users". but it is and its > causing US trouble and US work because gentoo is going around doing just > that. the result will be that people who want to change things for > specific good reasons and know what they are doing now have to PATCH the > build rather than just provide some --enable/disable flags. > > so to gentoo... STOP WITH THE USE FLAGS! JUST STOP! ENOUGH ALREADY! Raster, The fix for that is for ebuild maintainers to actually write ebuilds properly. It's not a slap-dash-chuck-it-all-together-and-whoopee! task, just like your job isn't like that. Example, the directfb stuff - that should be filtered out in the platform profile. How many x86 boxen have directfb installed? Auto- enable it in USE for an embedded system where it is appropriate. I use vapier and barbieri's ebuilds. They are sane, never had a problem with them since '07 or thereabouts. The problem isn't gentoo, or portage. It's wankers publishing ebuilds without having a clue first. Tell those wankers to shove right off by all means. Or even put a big notice on the web site saying you don't support gentoo, users need to talk to their ebuild maintainer. Just please don't rip out the useful compile config options. I like them, I rely on them, I'll be seriously pissed if you remove them because you got pissed with some wankers who don't have much clue. rant over :-) -- alan dot mckinnon at gmail dot com -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Working easy_e17.sh/configure parameters for 'coolest' and most feature rich E17
Apparently, though unproven, at 01:22 on Thursday 10 February 2011, Carsten Haitzler did opine thusly: > On Wed, 9 Feb 2011 11:47:33 +0200 Alan McKinnon said: > > Apparently, though unproven, at 03:10 on Wednesday 09 February 2011, > > Carsten > > > > Haitzler did opine thusly: > > > On Tue, 8 Feb 2011 15:36:25 +0100 Marc Koschewski > > > > > > > said: > > > > Hi all, > > > > > > > > due the amount of configure flags for the verious parts of E17 I just > > > > lost my overview of these completely. > > > > > > > > Does anyone of you - probably people using easy_e17.sh as well - hve > > > > a working config for a _fast_ (besides CFLAGS/LDFLAGS), cool and > > > > feature rich E17 installation that could be provided? Currently I > > > > rendered my easy_e17.sh parameters into something, that let's E17 > > > > compile but not work anymore. And before I try to get back to my old > > > > config, I just wanted to ask if anyone has some neat stuff handy... > > > > > > dont use ANY --enable/disable configure flags. defaults are what you > > > want. using any such flags you do at your own risk. > > > > That breaks Gentoo in all sorts of horrible ways. > > gentoo is broken already. :) Well, so is Ubuntu. For all values of "broken" where "broken" ~= "bloated" I will concede that Gentoo has it's fair share of broken devs. And their brokenness is much more visible than if they packaged for Ubuntu. -- alan dot mckinnon at gmail dot com -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Working easy_e17.sh/configure parameters for 'coolest' and most feature rich E17
* Alan McKinnon [2011-02-10 02:07:16 +0200]: > Apparently, though unproven, at 01:22 on Thursday 10 February 2011, Carsten > Haitzler did opine thusly: > > > On Wed, 9 Feb 2011 11:47:33 +0200 Alan McKinnon > said: > > > Apparently, though unproven, at 03:10 on Wednesday 09 February 2011, > > > Carsten > > > > > > Haitzler did opine thusly: > > > > On Tue, 8 Feb 2011 15:36:25 +0100 Marc Koschewski > > > > > > > > > > said: > > > > > Hi all, > > > > > > > > > > due the amount of configure flags for the verious parts of E17 I just > > > > > lost my overview of these completely. > > > > > > > > > > Does anyone of you - probably people using easy_e17.sh as well - hve > > > > > a working config for a _fast_ (besides CFLAGS/LDFLAGS), cool and > > > > > feature rich E17 installation that could be provided? Currently I > > > > > rendered my easy_e17.sh parameters into something, that let's E17 > > > > > compile but not work anymore. And before I try to get back to my old > > > > > config, I just wanted to ask if anyone has some neat stuff handy... > > > > > > > > dont use ANY --enable/disable configure flags. defaults are what you > > > > want. using any such flags you do at your own risk. > > > > > > That breaks Gentoo in all sorts of horrible ways. > > > > gentoo is broken already. :) > > Well, so is Ubuntu. For all values of "broken" where "broken" ~= "bloated" > > I will concede that Gentoo has it's fair share of broken devs. And their > brokenness is much more visible than if they packaged for Ubuntu. Gentoo is the best, smoothest and easiest to maintain distro I have _ever_ used. Never, really _never_ had less pain than with Gentoo. To me the ultimate distro. You can do anything. If cou want. In ie. Ubuntu you can do nothing. Even _if_ you want. But ... I guess this is going to get religious now. Let's rather focus on E than on the package manager, that provides us with the environmental stuff... Marc > > > > -- > alan dot mckinnon at gmail dot com > > -- > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > ___ > enlightenment-users mailing list > enlightenment-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-users > -- Marc Koschewski -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] Working easy_e17.sh/configure parameters for 'coolest' and most feature rich E17
On Thu, 10 Feb 2011 02:02:57 +0200 Alan McKinnon said: > > gentoo allows users to configure the builds of their libs. this also allows > > them to shoot themselves in their feet and screw it up. eg disable a > > feature and then find that e17 needs it. and then the gentoo users come > > running here to us e devs complaining e is broken and how they should fix > > it. gentoo is broken already. it just foists work onto US developers as > > users do things they have not the slightest clue about. those swizzle > > knobs are for people who know what the hell they are enabling or disabling > > and what the consequences will be. > > > > this problem has gotten so bad that i'm becoming of the opinion that we > > should cease having any configuration you can change at compile time > > because it was never intended to be exposed to "users". but it is and its > > causing US trouble and US work because gentoo is going around doing just > > that. the result will be that people who want to change things for > > specific good reasons and know what they are doing now have to PATCH the > > build rather than just provide some --enable/disable flags. > > > > so to gentoo... STOP WITH THE USE FLAGS! JUST STOP! ENOUGH ALREADY! > > Raster, > > The fix for that is for ebuild maintainers to actually write ebuilds > properly. It's not a slap-dash-chuck-it-all-together-and-whoopee! task, just > like your job isn't like that. Example, the directfb stuff - that should be > filtered out in the platform profile. How many x86 boxen have directfb > installed? Auto- enable it in USE for an embedded system where it is > appropriate. dfb is barely used - it's all but dead. evas's dfb engine is horribly broken and half-implemented. it shouldnt even be offered. i can tell you now - use software based enignes, or opengl (opengl-es is a bit of a tricky one sue to opengl-es2 specs meaning that runtime glsl compiling is optional - a major flaw in the opengl-es2 specs imho). as such though... opengl-es is auto-detected - if you have the headers and libs. its auto-enabled. default flavor is sgx (which is runtime GLSL shader support). anyway.. i digress. any engine other than the software ones (32bit ones - 16bit software ones are broken and 8bit unfortunately too) and the opengl engines are solid and usable. these engines get auto-enabled if u have the dependencies. the problem is that these USE flags are being swizzled by average joes not people building embedded systems. > I use vapier and barbieri's ebuilds. They are sane, never had a problem with > them since '07 or thereabouts. > > The problem isn't gentoo, or portage. It's wankers publishing ebuilds without > having a clue first. Tell those wankers to shove right off by all means. Or > even put a big notice on the web site saying you don't support > gentoo, users need to talk to their ebuild maintainer. vapier had this notice in his ebuilds for gentoo for years. you know what happened? users turned up here and asked for gentoo build help. it doesnt work. :( > Just please don't rip out the useful compile config options. I like them, I > rely on them, I'll be seriously pissed if you remove them because you got > pissed with some wankers who don't have much clue. > > rant over :-) i understand - but this IS a real problem. if it goes away - i wont care anymore. if it continues or gets a lot worse... you can bet that i will thing more and more strongly about finding a way to save us work and there may be casualties in the process :( -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
