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? > >> 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. > >> 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. 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. > > 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 ------------------------------------------------------------------------------ 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
