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 -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------------ 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
