On Mon, 3 Dec 2012 23:07:25 -0200 Gustavo Sverzut Barbieri <[email protected]> wrote:
> > > On 03/12/2012, at 21:50, David Seikel <[email protected]> wrote: > > > 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. > > > >>> 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. > > > > EFL giveth, EFL taketh away. > > Do you see it makes no sense to add a burden for everybody because > one single user with strange requirements? While that is true, I'm allowed to whinge about it and let my needs be known in case it's not really that much of a burden. How much of a burden it is I don't know, I'm not familiar with ecore_con and it's internal usage. Though the fact that it worked the way I wanted it to in the past suggest it's not that much of a burden. Sure my legal requirements are peculiar to my class of device, so that's not something that needs to be applied to EFL. On the other hand, not needing network and IPC, while needing things to be as small as possible, I would expect to be a common requirement in embedded work. It's also common for embedded devices to be subject to legal requirements, though I suspect not as many as mine is, governments tend to be paranoid about these things. lol I state my needs, if that's too hard, even though my needs where met in previous versions, then I have to live with that. The fact that these sorts of changes make my life much harder I will mention each time. I would not mind so much these changes making my life harder if it was not for the reasons I pointed out in that other merged ecore review thread. It basically boils down to "my project was designed around the feature of EFL that let me cut out lots of stuff". That feature is going away now that it's too late to change the design, this creates more work for me on a fixed price contract. I don't like being forced to do free work for paying clients. That this feature is going away was not apparent when I quoted for the job. It's a fact, there was a bug on the older EFL tarballs (fixed in 1.7) that was ending up to be too hard to work around, plus updating to EFL 1.7 meant I could remove two more no longer mandatory dependencies. The fact that an optional part of EFL is now mandatory is a problem in this case, so I stated my need. Overall it was a benefit to update to 1.7.2, I just wish it was a bit better. Otherwise I would have stayed with the pre 1.7 releases. I intend to stick with 1.7.2 for this project, unless there's further bugs that an update might help. There's no more recent release at the moment, so that's theoretical now anyway. I actually have a future project planned for this same client, but I have already quoted on that job. The basic deal is that this first one is written in a more generic style, and the second one will be based on it. Another good reason for going with EFL, I think the second project could be done mostly by just changing the EDC. B-) If the merged EFL tree is actually more suited to my clients requirements than 1.7.2 when the merged version is released, and that release is before I've done a lot of work on the second project, then I might consider using it for the second project, and providing an update for the old project. In this instance "more suitable" means A) it results in less things for the audit lab to worry about. B) it does not need me to do a lot of unpaid for work to update this project. C) less bugs that are important to this project. D) anything added that might make my job easier, especially if that offsets the extra work needed too update. So I'm speaking up about SVN merged EFL tree in varios places with regards to this project, just in case it ends up being useful for this project. I already mentioned, everything else I'm doing with EFL outside of this clients work, I'm quite happy with merged EFL tree and how it is progressing. > I really doubt that due the nature of your software you can be linked > to SVN head anyways, as we commit shitloads of code that would need > to be re-audited on every update. No I don't use SVN head, I use released tarballs for this one project. I use released tarballs for all external dependencies and things like the Linux kernel and libc. Telling the audit lab "It's just standard releases of Linux, uCLibc, busybox, etc as used in many other systems all over the world" will help them to do their job. Using that same argument for released EFL tarballs I might be able to fudge over by saying "Samsung and others use it.". B-) But I get to have my say in how SVN head is developed prior to it being released as a tarball. Coz it's too late to have input into things once it's released. The audit lab will look harder at my EFL usage than it will at my Linux usage, simply coz Linux is way more wide spread and understood than EFL. So yes, having less EFL for them to worry about is very important to me, and to my client. Saves him money on the audit. > If that is not s problem, just justify the new hard dependencies as > those other changes. The only justification is "upstream decided it's too hard for them to keep it optional like they used to". I have no other reason why it's there. That might be a hard sell, considering that it can be used to arbitrarily change what's on the screen from a network, and the legal requirements for what's on the screen are even tighter than the ones for what's on the disk. There is in fact legislation concerning network attached variations of these devices. The one I'm working on is not such a beast. The legislation requires that if it is such a beast, that you use the government written network API. I'm so fucking glad I don't have to do that. lol -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ 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
