David,

Your case is extreme and really an onus we shouldn't take. You can maintain a 
patch set or run 1.7.

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. 

--Gustavo

Sent from my iPhone

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

Reply via email to