On Monday, 23 January 2006, at 23:54:16 (+0900), Carsten Haitzler wrote: > yes - it doesnt. funny that there are a few hundred thousand lines > of code that need work on - a lot of packages like edje when they > build dont check for certain support. the bug u saw was a matter of > the code basically not checking all its return values. this kind fo > stuff happesn when u have a small team and a lot of code. it gets > fixed over time. i don't think netuering support is the > answer. adding the modules to edje's.spec is a much safer and better > solution that removing the ability to have modules for evas at > all. it's throwing the baby out with the bathwater.
This is simply not true. edje_cc, as it was before you made your return code fixes, was perfectly capable of compiling .edc files with no JPEG's in them without the evas JPEG loader module installed. Likewise, PNG-free .edc's don't need the PNG loader installed. And I'm willing to bet that .edc's without either JPEG's or PNG's don't need either loader module. So clearly the correct place for the dependencies is in the .edc files themselves, not the edje_cc compiler or the edje package. So what you did is just as much the "wrong solution" as what I did. Is it reasonable to put module dependencies into .edc files? And how can packaging systems like RPM be expected to pick up on those? Or are we saying that the packagers should be entirely responsible for keeping track of what evas modules might be required by .edc files in their packages? You have to weigh the idealism of having a separate package for each module with the practical concerns of dependency and other maintenance headaches, real-world usefulness, etc. I gave it a lot of thought, and I can't come up with a single real-world example of something that would (1) use RPM as a package manager, (2) use Evas, and (3) not use the JPEG/PNG loaders or the buffer engine. Can you? > as i said - this is not the right solution. it doesnt make sense > when the DEPENDENCIEs of edje can have these moduels added and thus > explicitly state what features it requires as a base minimum. i > believe i mentioned this to you on irc when i was making a modular > .spec - if software needs certain features it can require the > particular modules. Adding dependencies to .spec files is all well and good, but it's a manual process that has to be maintained. Furthermore, as I mentioned, edje isn't the right place for those dependencies. The right place is in the .edc files. > > You can also look at it this way: I've saved them an immense amount > > of time hunting down problems they don't understand by including the > > features that ALMOST ALL PACKAGES which use evas require. > > but not ALL. Let's hear some counter-examples. And stick to stuff that uses RPM please, as these are spec files only. I didn't change anything about the evas build. > i mean - feel free to make packages as such. my recommendation will > be to not use them. Be sure you explain why when you make that recommendation. I'm betting anyone who wants to exclude support for those things I merged in will have to alter the spec file anyway to remove the other build requirements they don't need. Like X11 (XFree86-devel via eet-devel) and libjpeg! > and we will see a history as with imlib2 - imlib2 needs x11 because > itys not modular, but CAN be built withotu x support - suddenyl > everyone thinks imlib2 NEEDS x and a lot of peoepl who want to use > it for web sites think they need x instaleld for it then decide not > to. evas can be used without x - or without png support. the > packages now basically neuter that ability. That "ability" is brand spanking new and still needs to be ironed out. The simple fact is that the packages which currently exist and use evas are NOT YET READY to have evas capabilities ripped out from underneath them. Once we iron this whole thing out, we can revisit the situation. But for now it's simply not practical to rip all that stuff out. Too much breakage. BTW, I looked for you last night, but you weren't on IRC, so I had to go ahead and take action. All of the following failed to build with the new evas spec: e_modules-calendar e_modules-flame e_modules-mount e_modules-monitor e_modules-rain e_modules-screenshot e_modules-slideshow e_modules-snow e_modules-tclock e_utils eclair engage entrance evidence evoak enlightenment express ewl Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <[EMAIL PROTECTED]> n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) ----------------------------------------------------------------------- "To err is human; to really louse things up requires Microsoft products." -- Alexander Pope, slightly paraphrased ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
