On Mon, 30 Jan 2006 17:09:57 -0500 Michael Jennings <[EMAIL PROTECTED]> babbled:
> On Wednesday, 25 January 2006, at 10:10:23 (+0900), > Carsten Haitzler wrote: > > > you solved a problem the WRONG way. instead of removing 50+ lines of > > spec file - you shoudl have added 5 or so lines in total to a few > > other spec files listing extra dependencies. > > I felt I was better equipped to take the approach I did than to try > and quantify module dependencies for packages when I didn't truly all > the different ways they were used by different apps. well i still think you could have done what u wanted with a stop-gap measure and made evas depend on module packages - then the packages still can be ebeuilt and its a trivial removal of their deps form evas and moving into the higher level apps spec files instead :) > > once a .edj file is compiled u only need the eet image loader > > module. nothing else is "required". the png, jpeg loader & saver > > moduels and buffer enginer are nonley needed by the > > edje_cc/edje_decc etc. tools. only edje and edje_test suck in the > > software_x11 engine module as a minimum req. thats why i mentioned > > before breaking this up into smaller fine-grained packages as edje > > really NEEDS very little runtime. :) > > Then let's start by putting together a list of the modules in CVS and > which evas modules each one needs to (1) build and (2) run: ok i'll make corrections where needed :) > Module Build Time Runtime > ------------------------------------------------------------------------ > e17/libs/ecore - - > e17/libs/edb - - > e17/libs/edje - - runtime should be split into 3 - edje and edje_tools && edje_build imho. i should clean up bnoth evas and edj test stuff as a lot of useless junk is in the src, tarballs and such from testing code (tonnes of png images etc.) ie libedje.so alone is in edje, (and headers in edje-devel) edje-tools would have edje, edje_thumb and edje_test, and edje_build would have edje_cc, edje_decc, edje_recc. edje would have: L-E runtime edje_tools would have L-E, L-P, S-*, E-S-X, E-B runtime edje_build would have L-*, S-*, E-B runtime. build-time they have no requirements for edje modules (as no .edj files are compiled) > e17/libs/eet - - > e17/libs/embryo - - > e17/libs/engrave - - > e17/libs/epeg L-J, S-J same epeg doesnt use evas at all :) so - there. not even build-time. > e17/libs/epsilon L-*, S-*, E-B same > e17/libs/esmart - - > e17/libs/ewl L-*, S-*, E-B, E-S-X same > e17/libs/exml - - > e17/apps/e L-*, S-*, E-B, E-S-X same > e17/apps/e_utils ?? > e17/apps/eclair ?? L-* E-S-X > e17/apps/elation ?? ignore this one too :) it's a bit festery. > e17/apps/elicit ?? > e17/apps/enscribe ?? ignore this for now :) > e17/apps/entice ?? L-*, S-*, E-S-X > e17/apps/entrance L-J, L-P, L-E, E-B - no E-B , but E-S-X is needed. > e17/apps/euphoria ?? > e17/apps/evfs - - > e17/apps/examine ?? > e17/apps/express ?? > e17/apps/iconbar L-*, E-B L-E, E-S-X not sure of the above. > e_modules/emu L-J, L-P, L-E, E-B L-E, E-S-X > e_modules/flame L-J, L-P, L-E, E-B L-E, E-S-X > e_modules/monitor L-J, L-P, L-E, E-B L-E, E-S-X > e_modules/mount L-J, L-P, L-E, E-B L-E, E-S-X > e_modules/rain L-J, L-P, L-E, E-B L-E, E-S-X > e_modules/screenshot L-J, L-P, L-E, E-B L-E, E-S-X > e_modules/slideshow L-J, L-P, L-E, E-B L-E, E-S-X > e_modules/snow L-J, L-P, L-E, E-B L-E, E-S-X > e_modules/tclock L-J, L-P, L-E, E-B L-E, E-S-X > e_modules/weather L-J, L-P, L-E, E-B L-E, E-S-X i think u can drop L-E as edje itself will suck this in for runtime lib deps. E-S-X will be sucked un by e istelf. build-time it should have a dep on edje-build whihc is needed to compile .edj files which woudl suck in these loaders and buffer engines, so this gets much simpler :) > These are my guesses/assumptions. Please make corrections as needed. will do :) > Obviously, L-E is loader_eet, L-J is loader_jpeg, etc.; S-* are > savers; E-B is engine_buffer, E-S-X is engine_software_x11, etc. > Presumably, build-time dependencies on evas modules would be primarily > for edje_cc, and runtime would be for actual formats used. yup. i've had my go above :) > 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) > ----------------------------------------------------------------------- > "You are waiting on a beach. This is where the East meets West. > And as another sun sets on your anger, the darkness laughs as the > wound destroys, and it turns your prayers to noise. Will you > forgive? Will you forget? Will you live what you know? He left > his rights; will you leave yours? You don't understand it. > Let it go." -- Newsboys > > > ------------------------------------------------------- > 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 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ------------------------------------------------------- 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
