Re: [E-devel] [e-users] New EFL release cycle 1.1/1.5 ALPHA

[David S. <on...@gm...>]

On Thu, 17 Nov 2011 19:17:56 +0900 Carsten Haitzler (The Rasterman)
<ra...@ra...> wrote:

> On Thu, 17 Nov 2011 05:40:40 +1000 David Seikel <on...@gm...>
> said:
> 
> > On Wed, 16 Nov 2011 18:31:40 +1000 David Seikel <on...@gm...>
> > wrote:
> > 
> > > On Wed, 16 Nov 2011 15:20:24 +0900 Carsten Haitzler (The
> > > Rasterman) <ra...@ra...> wrote:
> > > 
> > > > 
> > > > We'd like to announce a new release cycle alpha release of
> > > > several Enlightenment components 
> > > > 
> > > > http://download.enlightenment.org/releases/eina-1.1.0-alpha.tar.gz
> > > > http://download.enlightenment.org/releases/eina-1.1.0-alpha.tar.bz2
> > > > http://download.enlightenment.org/releases/eet-1.5.0-alpha.tar.gz
> > > > http://download.enlightenment.org/releases/eet-1.5.0-alpha.tar.bz2
> > > > http://download.enlightenment.org/releases/evas-1.1.0-alpha.tar.gz
> > > > http://download.enlightenment.org/releases/evas-1.1.0-alpha.tar.bz2
> > > > http://download.enlightenment.org/releases/ecore-1.1.0-alpha.tar.gz
> > > > http://download.enlightenment.org/releases/ecore-1.1.0-alpha.tar.bz2
> > > > http://download.enlightenment.org/releases/embryo-1.1.0-alpha.tar.gz
> > > > http://download.enlightenment.org/releases/embryo-1.1.0-alpha.tar.bz2
> > > > http://download.enlightenment.org/releases/edje-1.1.0-alpha.tar.gz
> > > > http://download.enlightenment.org/releases/edje-1.1.0-alpha.tar.bz2
> > > > http://download.enlightenment.org/releases/efreet-1.1.0-alpha.tar.gz
> > > > http://download.enlightenment.org/releases/efreet-1.1.0-alpha.tar.bz2
> > > > http://download.enlightenment.org/releases/e_dbus-1.1.0-alpha.tar.gz
> > > > http://download.enlightenment.org/releases/e_dbus-1.1.0-alpha.tar.bz2
> > > > http://download.enlightenment.org/releases/eeze-1.1.0-alpha.tar.gz
> > > > http://download.enlightenment.org/releases/eeze-1.1.0-alpha.tar.bz2
> > > > http://download.enlightenment.org/releases/expedite-1.1.0-alpha.tar.gz
> > > > http://download.enlightenment.org/releases/expedtie-1.1.0-alpha.tar.bz2
> > > > http://download.enlightenment.org/releases/evas_generic_loaders-1.1.0-alpha.tar.gz
> > > > http://download.enlightenment.org/releases/evas_generic_loaders-1.1.0-alpha.tar.bz2
> > > 
> > > /me updates his embedded project to use these tarballs, and sees
> > > what happens.  Though I only use the first six. 
> > 
> > Got stuck on evas.  Even with --disable-pthreads, it still tries
> > (and fails) to build with pthreads.  So I can't test any further on
> > my embedded project.
> > 
> > Half way there.
> 
>  7:10PM ~/C/evas > ./configure --disable-pthreads
> --disable-async-preload checking for a BSD-compatible
> install... /usr/bin/install -c checking whether build environment is
> sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p
> ...
>   Thread Support..........: no
> ...
>   Threaded Pipe Rendering.: no
>   Async Pipe Rendering....: no
>   Async Events............: yes
>   Async Image Preload.....: no
> ...
>  7:15PM ~/C/evas > make
> make -j9  all-recursive
> make[1]: Entering directory `/home/raster/C/svn/ssh+svn/e/trunk/evas'
> make[1]: warning: -jN forced in submake: disabling jobserver mode.
> ...
> make[2]: Entering directory `/home/raster/C/svn/ssh+svn/e/trunk/evas'
> make[2]: warning: -jN forced in submake: disabling jobserver mode.
> make[2]: Leaving directory `/home/raster/C/svn/ssh+svn/e/trunk/evas'
> make[1]: Leaving directory `/home/raster/C/svn/ssh+svn/e/trunk/evas'
>  7:16PM ~/C/evas > 
> 
> compiled fine. disabled features. sure - it may link to pthread due
> to eina and ecore still using threads.

Evas is compiled before ecore, and pthreads is not turned on in eina.

Disabling a whole other bunch of other thread stuff managed to get evas
to compile. The point is that it's a bug if you just disable pthreads,
yet it tries to do pthreads stuff anyway.


> can i ask why you dont want to use pthread?

I've pointed out before, my embedded project has to pass government
audit labs.  The less they have to audit the better.  I don't NEED
pthreads, so I'd prefer to not have to actually compile stuff with it
or have it around.  Slowly but surely I'm removing everything that is
not actually needed from this project.

That's why I was happy to finally sort out why signals where not
getting through to the lua in this project - so I could get rid of all
uses of messages.  Not that there is anything wrong with messages, it's
just one less thing for the labs have to understand for the audits.
I could not go the other way of getting rid of signals completely, edje
programs need them.

I'm quite happy using ecore style cooperative multitasking instead of
threads in my app.  Plus, threads is traditionally hard to understand,
it's good to not have the audit labs have to understand it.

Same reason why I left out X, I don't need it, framebuffer is already
provided by the kernel.  More stuff the audit labs don't need to look
at.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.