On Tue, 4 Dec 2012 15:35:10 +1000 David Seikel <[email protected]> said:
> On Tue, 4 Dec 2012 12:22:00 +0900 Carsten Haitzler (The Rasterman) > <[email protected]> wrote: > > > On Tue, 4 Dec 2012 09:50:25 +1000 David Seikel <[email protected]> > > said: > > > > > On Mon, 3 Dec 2012 20:23:48 +0900 Carsten Haitzler (The Rasterman) > > > <[email protected]> wrote: > > > > > > > On Mon, 3 Dec 2012 20:17:49 +1000 David Seikel <[email protected]> > > > > said: > > > > > > > > > On Mon, 3 Dec 2012 10:03:24 +0100 Vincent Torri > > > > > <[email protected]> wrote: > > > > > > > > > > > On Mon, Dec 3, 2012 at 9:55 AM, David Seikel > > > > > > <[email protected]> wrote: > > > > > > > On Sun, 2 Dec 2012 23:45:46 +0100 Vincent Torri > > > > > > > <[email protected]> wrote: > > > > > > > > > > > > > >> hey > > > > > > >> > > > > > > >> i've aded ecore in efl/ I'm pretty sure that there are > > > > > > >> plenty if bugs. Please report them here > > > > > > >> > > > > > > >> There are also plenty of improvements to do too, i'm aware > > > > > > >> of that. > > > > > > > > > > > > > > I noticed you made ecore_con compile mandatory. > > > > > > > > > > > > indeed. Is it a problem for you ? > > > > > > > > > > Yep, as I have mentioned before, this embedded project I've been > > > > > working on has legal requirements that must be met, and an > > > > > audit lab that it has to go through to make sure it meets those > > > > > legal requirements. One of those legal requirements is to not > > > > > have anything on the device that is not actually needed for the > > > > > device to perform it's specific legal function. On top of > > > > > that, the less there is on the device, the less time it will > > > > > take the audit lab to audit it, the cheaper the audit will be. > > > > > The device does not need networking, so leaving out ecore_con > > > > > would be good. > > > > > > > > ecore-con is not just for "networking". it's for ipc. ecore-evas > > > > requires it because ecore-evas supports remote ipc canvases from > > > > other processes (ecore-evas-extn). in the bid to simplify our > > > > ifdef hell we have and ensure people have an always usable setup - > > > > ecore-con is now on by default. > > > > > > I don't need IPC or remote canvases either. > > > > > > And yes, it's still a problem for me. Now I have to explain to the > > > audit lab that while there is now the potential to connect up to the > > > device over a network and use this fancy ecore_con thing to add new > > > functionality and change what's on the screen, thus potentially > > > bypassing the legal requirements for our own nefarious purposes, I > > > promise that we don't do that. Cross my heart and hope to die. > > > > oh don't be silly - unless some software literally ADVERTISES a > > service you can't do squat diddly to connect to it and do anything. > > you have to EXPLICITLY create a remove server service... and the > > ecore_evas_extn stuff never does remote services - it's machine-local > > only as it relies on shmmem to share pixel data. > > I'm being dat silly on behalf of da gubermit peoplez. No idea how > silly dey might be. Dey might think dis ecore_con thing is a backdoor > left by me. DAT'S what I have to deal with, audit labs paid by da > hour, gubermit laws, bureaucrazy. Dey getz into my codez and do silly > thingz. they must love the kernel and libc.. which have all of this... already. :) > Otherwise I'd just say fuck it, the actual hardware has way more flash > and RAM than we need, who the fuck cares? Well, the gubermit cares, > the audit lab cares coz they do what the gubermit tells them to, the > client cares coz he has to pay the audit labs, the client's the one > paying me, so I'm paid to care. And, I'd like to actually do this next > project he wants me to work on, so I care about what the client cares > about. At least until he runs out of work for me, or until some one > pays me good money to do virtual world stuff and his contract ends. > > > > > > Raster said that --disable-foo options will get replaced by > > > > > "just delete the libfoo.* files". I'm hoping that is stuck to, > > > > > at least for the stuff *I* don't need. B-) > > > > > > > > not in all cases. see above. :) > > > > > > EFL 1.7.2 let my remove fontconfig and it's dependencies, but made > > > me add pthreads and ecore_con. At least there was still an overall > > > decrease in the resulting flash image size. > > > > 1.7.2 made u AND pthreads and ecore-con? this was only in trunk (efl > > tree and ecore tree prior to merge) or... should only have been. ? > > Note the bug in 1.7.2's --disable-ecore-con that I mentioned before in > this thread. That is what forced me to add ecore_con to the 1.7.2 based > project. The bug crashes autofoo when you try to use the disable > option, so you can't use the disable option. Deleting the ecore_con > library that is produced crashes ecore when it tries to open it, so you > can't remove that library. Thus, my embedded project needs ecore_con > now, even though it's not actually used. In 1.7.2, ecore_con is > effectively mandatory, despite what the docs say. > > We went through the pthread dependency with the 1.7 release screw up > discussion. If I remember, 1.7 should have had --disable-pthread > removed, but it was only half removed in 1.7. > > -- > A big old stinking pile of genius that no one wants > coz there are too many silver coated monkeys in the world. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
