On Sat, 2 Oct 2010 11:41:34 -0300 Gustavo Sverzut Barbieri <[email protected]> said:
> On Sat, Oct 2, 2010 at 8:34 AM, Carsten Haitzler <[email protected]> wrote: > > On Wed, 29 Sep 2010 05:53:04 -0300 Gustavo Sverzut Barbieri > > <[email protected]> said: > > > > the attached is what i was thinking of > > Did you actually try my code? It does exactly the same as you want, > but does not rely on ugly enumerates and thus allows extensions like > themes and so on. > > Okay, the names are different, you call it "seed" and "argv0" while I > call them "populate_from" and "namespace". > > >From your idea I just lack the "seed_envs", which I said in my initial mail. > > My code even did auto-detection of posix compliant file hierarchy by > checking if one's symbol/argv0 is in one of bin/ share/ lib/ libexec/ > ... and in that case registers the root (ie: /usr/bin/app register > /usr that in turn can find out include/, share/ ...) > > So yeah, if you wish I can rename to seed and add couple of #define > ECORE_RESOURCE_LIB "lib", but i guess it's not required. > > I also clear distinction of app and system, as I guess it is better > than trying to mix them all, but I could do ecore_app_resource_* > fallback to ecore_sys_resource_* if it did not find. > > Anyway, I guess you just have something in your mind already and > instead of trying to understand what you did you just want me to > exactly what you wondered even if it is not the best solution. well your api is bigger (specific calls for app and resource pool), and the dir append thing will break "bin" finding if u use it for your data, but then u can't find your binaries on the system where u were installed - then again you intended to pass in category as "share/appname" then right?. also i wanted the ability to have env vars override auto-discover, and to be able to provide "if all else fails use these compiled in full paths for the dirs". you also do a search per resource find as opposed to a 1 time test to find the actual "prefix" install loc for the app and/or lib then re-use that with no searching after the test. i guess what i had in mind was something that did everything the current prefix stuff for e17, elm, evas, edje do in finding installed components (from binaries to utilities to libs, data files and more). yours is kind-of-there, but not quite what i had in mind. i guess we disagree with the enums - i like them as it defines very specific standard locations and keeps the set limited to that (you can always just get the app prefix and add your own custom dirs to the end of prefix). the reason i did this is i wanted to be able to return "/tmp", "/etc" as well as "PREFIX/etc", "/home/USERNAME", "PREFIX/share" and so on - and thus u have to treat the enums specifically per group/type or case by case. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
