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

Reply via email to