On Tue, Aug 21, 2012 at 10:43 PM, Gustavo Sverzut Barbieri <barbi...@profusion.mobi> wrote: > On Tue, Aug 21, 2012 at 7:02 AM, Vincent Torri <vincent.to...@gmail.com> > wrote: >> On Tue, Aug 21, 2012 at 11:58 AM, Gustavo Sverzut Barbieri >> <barbi...@profusion.mobi> wrote: >>> On Tue, Aug 21, 2012 at 6:43 AM, Vincent Torri <vincent.to...@gmail.com> >>> wrote: >>>> On Tue, Aug 21, 2012 at 11:30 AM, Gustavo Sverzut Barbieri >>>> <barbi...@profusion.mobi> wrote: >>>>> On Tue, Aug 21, 2012 at 5:07 AM, Vincent Torri <vincent.to...@gmail.com> >>>>> wrote: >>>>>> >>>>>> On Tue, Aug 21, 2012 at 9:56 AM, Gustavo Sverzut Barbieri >>>>>> <barbi...@profusion.mobi> wrote: >>>>>> > On Tue, Aug 21, 2012 at 4:32 AM, Vincent Torri >>>>>> > <vincent.to...@gmail.com>wrote: >>>>>> > >>>>>> >> Hey >>>>>> >> >>>>>> >> another mail for the status on Windows: >>>>>> >> >>>>>> >> 1) cserve2 is not even compiling as shm_open() and (worse) fork() are >>>>>> >> used in a part of the code that should be OS independent. If cserve2 >>>>>> >> is going to be e required dep for the next evas, i fear that the >>>>>> >> Windows development will stop. >>>>>> > >>>>>> > >>>>>> > You were supported to do a port of cserve2 to Windows or other >>>>>> > Non-Linux >>>>>> > platforms: >>>>>> >>>>>> and you were supposed to put code specific to linux in separate files, >>>>>> which is not the case. You even don't check that the functions you use >>>>>> are available in configure.ac. For example, shm_open does not exist on >>>>>> OpenBSD (a quick search on google and i found that : >>>>>> http://www.groupsrv.com/linux/about60282.html and note that i don't >>>>>> know anything about those functions, so the link is to help you, >>>>>> that's all) >>>>> >>>>> Actually the lazy approach of "let's see who will complain and when". >>>>> It took months, but it finally happened :-) >>>> >>>> are you kidding ??? I've already spotted those problems to you or >>>> Sachiel or another one at Profusion (i can't remember who) before !! >>>> Nothing was done to fix that. >>> >>> at that time the software was under development. It's still maturing >>> and not enabled by default not even on Linux. >>> >>> Plan was to get it enabled by default on Linux (done), then make E17 >>> enable the server by default (post e17 release, if E17 starts the >>> daemon and sets the envvar, then apps should use it automatically). >>> Then we have enough stability to port it to other platforms. >> >> that's precisely what we should not do... Because you'll write code >> specific to linux, it will be released with no possibility to change >> the API, and the port for other platforms will be just ugly hacks. As >> usual. > > what you mean? There is no API in there. It's all internal
The think is that the way Evas_Cserve2 is currently developed need at best to duplicate a lot of work already done in Ecore (main loop, exec, pipe, ...) and maintain it over time. The situation is likely to latter be the same with Mac OS X event loop that may require some trick also. I my opinion a proper solution to this problem is to move Evas_Cserve2 server outside of Evas, make evas_cs2.h a public API, then use Ecore instead of custom non portable code. Evas_Cserve2 is a runtime dependency of Evas, not a build time one, so it is perfectly doable. I know that people will not understand that, so as soon as Evas and Ecore get merged inside the new unified EFL tree in a few weeks, we should split out Evas_Cserve2 and migrate it to Ecore. This seems to me like the only way to do it right without having a huge nightmare for anyone trying to port it. As a side note, it would be good to start thinking about pushing the use of shm_open with write output to Eina_File. -- Cedric BAIL ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
