Hi, I've read and followed every page which described how to build enlightenment using MinGW + Windows, MinGW / AutoConf / Pkg-config are all up-and-ready but it still refuses to work, still finding the answer why :(
I will listen to you, start it all over just stick to evas, and make it work, second target is to port to the same toolchain where the BIOS codebase is using. Thanks. On Tue, Apr 30, 2013 at 10:37 PM, Gustavo Sverzut Barbieri < barbi...@profusion.mobi> wrote: > Hi Hyde, thanks for clarifying, comments below: > > > On Tue, Apr 30, 2013 at 9:48 AM, hYde <hyde....@gmail.com> wrote: > >> Hi, >> >> > that's why I explicitly removed Edje. Edje pulls too much, and will not >> aggregate that much value for the BIOS case (show menu and similar). Of >> course it would be nice to have a complete environment with Elementary and >> all, > but I don't think it's doable without LOTS of effort, so stick with >> Evas first -- particularly pre-Eina Evas. >> >> Maybe I misunderstood about Edje, I thought that was some kind of C like >> meta-language layer to seperate UI and code. >> > > Indeed it is, and would be awesome if you could use it. However, being > higher level, it depend on lots of other EFL, as Raster named Ecore (main > loop, timers...), Evas (canvas), Eina (data types), Eet (binary file chunk > reading lib, similar to "zip"). Of course you can port them, as was done > for PSL1GHT (PS3 native engine), but it's more work. Maybe you can try this > as a second step/milestone. > > > >> I'll try to use pre-Eina Evas though I still couldn't get my Win7 + MinGW >> right (lots of autotool error) >> > > Did you look into Vincent's wiki page: > https://trac.enlightenment.org/e/wiki/EFLWindowsXP > > He was the last one to care about such setup, and I basically removed most > of the support in the current merged tree (the EFL git repo) as we could > not get too broad interest from developers to guarantee it would work. > Before some guys were doing some work to get it running now and then, it > was not constant. > > > >If you need to strip the libraries, I'd recommend to remove the following >> chunks from Evas: >> > - Gradients: it was removed in current Evas, but the pre-Eina still >> contained it with lots of useless code; >> > - Textblock: if you don't need text markup or multi-line text, you >> can remove this and lots of code. >> >> I'l need Textblock for further usage. >> > > Ok. Just note that using Textblock from plain Evas is a PITA, I'd > recommend getting to it via Edje, but then you need the other libraries as > said before. > > > > And of course choose the minimum set of engines and options, I'm not >> sure the bootloader can use MMX/SSE, then you can compile out those with >> ./configure flags. >> Yes, we have SSE2, which is for security check, grab them libs to use >> will be okay. >> >> In UEFI environment we have events and notify, basic Bit blit function >> to access raw framebuffer, timers..etc. Not much like the OS but will do >> some good. >> > > That's basically what we need. You don't need to port everything, just > what you need to make it work. For instance timers and framebuffer access > should be enough, as well as file (fopen) if you need Edje/Eet. Edje may > use Eio that in turn uses inotify on Linux, but you can leave that as empty > stubs or just do not compile. Nowadays Evas also is starting to depend on > Threads, thus it's good to plan such feature in the future. > > > >> > NOTE: which hardware are you using this? It seems like a nice hobby >> project I'd help on weekends, but I'd need to have a way to test :-) >> I use coreboot or UDK2010 ( >> http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=UDK2010) >> , the later has some NT32 simulation, which can use as a basic test on host >> machines. >> But if you are talking about real platform, I almost have everything >> because I work in a vendor. >> > > Ah, vendor :-D > > > > >> Not familiar to all of this (toolchain, environment and I don't know how >> to find E17's writing guide) I have to apologize :( , so t is hard for me >> to catch up all the information. But my target is to port a open-sourced UI >> lib for BIOS to use, not only in setup menus, but also some UEFI shell >> applications, it will magically reduce a lot of working hour, for BIOS / >> Driver developers to work only on the function, not to take care the >> unawareness of the UI. >> > > Indeed, if you can get to Edje, Elementary is quite close... and with it > all the associated high level tools. I'd still recommend to try Evas by > itself before going further, but if your plan is to create an "SDK", it's > better to continue with upstream EFL on the long run. > > Regards, > -- > Gustavo Sverzut Barbieri > http://profusion.mobi embedded systems > -------------------------------------- > MSN: barbi...@gmail.com > Skype: gsbarbieri > Mobile: +55 (19) 9225-2202 > ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 _______________________________________________ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
