On Mon, 3 Dec 2012 23:17:05 -0200 Gustavo Sverzut Barbieri <barbi...@profusion.mobi> wrote:
> Your case is extreme and really an onus we shouldn't take. You can > maintain a patch set or run 1.7. Embedded use is not an extreme case, though my legal requirements are. The main legal requirement I end up having to bitch about is "keep out stuff that's not needed", which is actually a general case for embedded work. So I might bitch about it more than others, but I bet other embedded developers also want some of their currently optional dependencies / libraries to not be made mandatory. There was talk of an embedded profile for exactly this reason. I just bitch about these things loud enough that the rest probably think I'm doing enough bitching for them. B-) > The current code will remain as is for an uncertain amount of time, > then it's just a build issue for the time being. But as we have less > corner cases to handle, we have less code to maintain. We may not > remove the ifdefs right away, but for sure we won't keep writing code > that handles every possible situation if we can trust they won't > exist. Be warned that as the situation evolve we might consider > dropping less important cases. One day xcb may be so widely spread > that its pointless to keep xlib alternative. Just provide epoll, etc. Yes, I do realise the general benefits of the combined tree and removing some corner cases, in general I love the idea. I also realise the benefits of being able to keep things small on embedded devices. I only point out the things where I think we should err on the "keep it optional" side of things. Note that I agreed to eet and png loaders being mandatory; and SSE3 code being mandatory so long as all that sort of extra CPU instructions is checked for at run time, some of my stuff runs on x486s. I did not care about simple-x11, I use fb for embedded, and the rest of my EFL work I don't care what is used as the engine, it should be portable. Thread safety being always on I'll live with since pthreads is now always on, and that had minimal impact on me in the end. Even though I bitched about it at the time. :-P Epoll I did not care about one way or another. g_main_loop, well I understand that glib support will permanently remain optional, as it's a corner case added for some one elses benefit. I try to avoid glib, preferring to use EFL when I can, and so far have avoided the need for glib in any of my projects. So long as glib remains optional, I'll not care what is done with it's code. Ipv6 being dependent on platform support is a good idea. Though I don't think networking should be mandatory. That covers ecore_con and sockets as well, more or less. DirectFB I don't care about, fb is preferable to me in the cases where I do care, and I understand directFB has not gotten any love for ages, thus is likely bit rotted. EWS I think should be optional, but if it's small enough then I guess wont care THAT much. Ecore-x modules should only be enabled if X11 is enabled? If that is the case, then I wont worry about them. B-) xim, scim. ibus, all should be optional. None of that stuff I felt any need to comment on though. So most of the plans I agree with, just some things I think should be left optional, and not just for my corner case. > On 03/12/2012, at 22:45, David Seikel <onef...@gmail.com> wrote: > > > On Mon, 3 Dec 2012 21:27:54 -0200 Gustavo Sverzut Barbieri > > <barbi...@profusion.mobi> wrote: > > > >> fontconfig and fribidi: would be always enabled, or at least > >> platform dependent. No specific options to disable/enable them. > > > > I just got done pointing out that I was happy that I could remove > > fontconfig from my embedded system with EFL 1.7.2. So long as I can > > leave it out at compile time I'll stay happy. Fribidi is also not > > needed by me, and thus not part of my embedded OS's build. > > > >> loader/saver: always enable eet, jpeg, png and generic. Remove > >> options, these are hard dependencies. (generic if platform > >> supports) > > > > Why would savers be a hard dependency? Not everything needs to > > create graphics files. In my embedded project I actually delete > > the savers directory after the build. I hope that will continue to > > work. The loaders, yes, I need them. Though I've been considering > > removing the jpeg loader from my embedded project, it does not have > > any jpeg files, and I use lossless in the EDC. > > > >> - fb: maybe have option to enable tslib? Or tslib is an option on > >> its own? > > > > For what it's worth, I use fb but not tslib. > > > >> ecore-x submodules: enable every module. > > > > As pointed out in that other thread I recently replied to, so long > > as removing the libraries works, I guess I can live with this. > > What I don't want to see is the need to add other things to my > > embedded OS's build to satisfy build time dependencies for stuff I > > don't want, only to delete it all at the end of the build again. > > That would be just plain silly. > > > > I'll point out that when I started the EFL port of this embedded > > project, to satisfy the legal requirements for a bare minimal > > amount of software on the device, I chose EFL in part coz there was > > lots of options to not include stuff we don't need. The previous > > version of the project I inherited started from a generic OS that > > had to have stuff cut out. This version I designed builds the OS > > from the ground up to only include the stuff we need. The result > > is one fifth the size, and you could argue it is five times more > > likely to pass the legally required audit lab inspection. It > > certainly boots in seconds instead of minutes, which was a > > requirement of the client. > > > > I'm a computer programmer, not a lawyer, my job is to make sure the > > resulting software complies with several books worth of laws, not to > > argue about the laws. Cutting the software down to the bare > > minimum is part of those laws, thus is part of my job. > > > > I moved from an earlier EFL release to 1.7 coz that solved a bug I > > was having a hard time working around, AND it meant I could remove > > fontconfig and it's dependencies. It made me add ptheads and > > ecore_con. The overall result is still smaller with less things in > > it, so I guess that's OK. > > > > I don't want to see too many more optional dependencies becoming > > mandatory, as that invalidates the original design decision to go > > with EFL coz I can cut out the cruft we don't need easily. It's > > too late in the project to change the design now, we are stuck with > > it. You are changing the race horse into an ox though, and this is > > a big concern to me. > > > > While it is possible that I could do stuff like write an ecore_con > > stub library, or write a local patch to remove it's need, these are > > not things I needed to do for the original design. They are things > > I need to do now coz EFL changed under me when it was too late to > > change horses. It will take me time to make those sorts of > > changes, and this is time that is only useful for this project. > > I'm not being paid by the hour, but for the entire project, so this > > is work I'll have to do for free if I have to do it at all. > > Hopefully I wont need to move on from EFL 1.7.2 to later versions > > to solve important bugs, but it's always possible that might be > > needed. > > > > I still want to make my concerns heard while you are thinking about > > taking away one of my main reasons for choosing EFL for this almost > > completed commercial project that has legal requirements I can do > > nothing about. The laws covering this class of device is the rock, > > EFL making more optional things mandatory is the hard place. I'm > > being squeezed between the rock and the hard place and I really > > don't like it. > > > > On the other hand, for all my other EFL projects, I really don't > > mind these changes, and love the single combined tree. B-) > > > > -- > > A big old stinking pile of genius that no one wants > > coz there are too many silver coated monkeys in the world. > > ------------------------------------------------------------------------------ > > 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 > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > ------------------------------------------------------------------------------ > 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 > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
