CTFE ^^ (pow)

[H. S. Teoh]

On Sat, Mar 24, 2018 at 01:42:56AM -0700, Walter Bright via Digitalmars-d wrote:
[...]
> This file:
> 
>   https://github.com/dlang/dmd/blob/master/src/dmd/backend/optabgen.c
> 
> computes tables, and writes several tables out to several .c files,
> which are then #include'd into the main build. It all happens
> automagically using the makefile:
> 
>   https://github.com/dlang/dmd/blob/master/src/win32.mak#L420
> 
> I've been using this technique continually since the early 1980's :-)
> 
> Some IDEs have problems with it, because they cannot support layered
> builds like this, but good old make does it just fine.

Thus proving that IDEs suck. ;-)


> I can't recall ever seeing anyone else use this technique (other than
> Nick!), but it works and isn't that bad.

It's not all that uncommon.  I've worked with projects (and still do)
where code is generated by a tool at build time, and then #include'd by
other source code.  Any project that uses lex/yacc (or their clones
flex/bison) does this. One of my own recent projects involved a clever
(IMO) trick of using the C preprocessor on a C header file (truetype, to
be precise) to generate D code that then gets compiled by a D compiler,
by suitably (re)defining certain macros.

Being able to do all this in CTFE instead is nice, but hardly a
*necessity*.  And to be frank, the slowness of CTFE hampers serious use
cases like generating parsers (it's definitely doable, as proven by
Pegged, but it does come with an unattractive increase in compilation
time (when will we see newCTFE materialize... *hint hint* :-P)).


T

-- 
Life begins when you can spend your spare time programming instead of watching television. -- Cal Keegan