On Tue, Nov 14, 2017 at 10:37 PM, Carsten Haitzler <ras...@rasterman.com> wrote: > On Tue, 14 Nov 2017 14:51:38 -0200 Gustavo Sverzut Barbieri > <barbi...@gmail.com> said: > >> On Tue, Nov 14, 2017 at 9:35 AM, <marcel-hollerb...@t-online.de> wrote: >> > On Tue, Nov 14, 2017 at 09:22:01AM -0200, Gustavo Sverzut Barbieri wrote: >> >> while I'm okay with .eo.x, I'm not sure you should include it in >> >> "sources", rather do in "dependencies". >> > >> > Well is it a dependency? >> >> that's exactly what it is: a dependency. >> >> it's not the source file, which is the .c that devs edit :-) Rather >> the ".eo" is a source, but the complier doesn't understand it, so we >> translate so it can be used by c compiler... in an ideal world we >> could provide "efl_cpp" that wraps cpp and would generate C for you >> transparently. > > This is what I originally was proposing we do for eo. We provide basically a > smarter "cpp" that runs before the real compiler. It could, like ccache, > distcc > etc. just wrap the real compile command. It'd also allow us to be far more > elegant. We'd have created a hybrid "language" or essentially custom compiler > with extensions of course - C as the base with our own extensions that are > done > as a CPP phase and generating C as output rather than inside the core compiler > generating ASM or whatever intermediate stage comes out prior to the binary. > > But no one wanted it. :(
yeah, I proposed that... could do our "lambda" (ie: offer C++ lambda in C), but rejected :-/ -- Gustavo Sverzut Barbieri -------------------------------------- Mobile: +55 (16) 99354-9890 ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel