On Tue, 31 Aug 2010 15:26:49 -0300 "Eduardo Lima (Etrunko)" <ebl...@gmail.com> said:
> On Mon, Aug 30, 2010 at 5:46 PM, Carsten Haitzler <ras...@rasterman.com> > wrote: > > On Mon, 30 Aug 2010 12:28:04 -0300 "Eduardo Lima (Etrunko)" > > <ebl...@gmail.com> said: > > > >> Hey there, > >> > >> I was following the advice that --enable-pthread only makes sense for > > > > what advice that says that? none in evas that's for sure. > > Well actually it was said in quite some conversations in #edevelop. > What would be your advice, taking into account an embedded, single > core environment? aaah well i'd say "use defaults". :) ie pthread and async events etc. are there. don't use async-render or pipe-render. not even if you have multiple cores. > > > >> multicore systems and since I am building for embedded, I thought it > >> was a good idea to disable it. But I didn't know that asynchronous > >> render had something to do with threads, so I let it there. > >> > >> What happens is that if you configure Evas with --disable-pthreads and > >> --enable-async-render all you get is compile errors. I tried to > >> investigate the issue a bit further but I just got more confused in > >> the middle of all those #ifdefs. > > > > async rendering REQUIRES threads. you've basically created a logical > > fallacy in your options. sure - configure could fix this up by forcing > > pthreads back on again or disabling async anyway. > > Yeah, definitely something like that, or even failing to configure > with a message about conflicting options. sure. though the problem here is a lack of understanding - async renderer is a thread thing and you are trying to get rid of threads, which means that either... you didn't read the README... or the README needs to be improved to explain things better as you are mis-using an option and not understanding what it actually does :) that's the issue. fixing configure to just force threads back on or force async off etc. doesn't improve understanding. failing may just become annoying too :) > > > >> Questions: > >> 1) Does it make sense to build with --disable-pthread and > >> --enable-async-render at all? > > > > no. > > > >> 2) In anyways, don't you think build should work regardless of the > >> configure options? > > > > not really - there are so many of them and if you are smart enough to be > > swizzling around with the options, then you should read the README. you > > asked it to do the impossible. otherwise just leave it at default options > > and done > > --enable/disable stuff. :) > > Things are well documented in the README file, but I'm actually more > into opening the configure.ac and look into the options to see what > truly happens. As I told, the --enable-async-render option was > mistakenly left there when I chose to use --disable-pthreads. aaaah mistakenly! gotcha! :) so not a lack of understanding. an "oops" that u'd like to have had a better configure-time error check. :) > I tried to track and fix the problems, but inside the code, there is a > huge mess of #ifdefs in both .c and .h files, where, for instance, you > only define a variable if you have A but then you use it inside a > block where B is defined. This is where I gave up on trying to fix > that. i hate ifdefs too :) but a necessary evil here. configure-time is where the "fix" should be due to the implicit dependencies. > > > > like pointers in c/c+=... your responsibility to get it right at this > > level. :) > > > > Yeah, but my intention is to fine tune the setup to get the best > performance on that restricted environment. In this case I think a > good approach would be to sanitize the configure options, to either > give up configure due to conflicting options or enabling everything > you need automatically. > > -- > Eduardo de Barros Lima > ebl...@gmail.com > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
